Blogger :
David Pallmanns Blog
All posts :
All posts by David Pallmanns Blog
Category :
WSCF/WCF
Blogged date : 2007 Nov 10
3-tier applications have been around for some time now, and the presentation/business/data tier arrangement seems to have held up well despite a variety of underlying technology changes. But how does the arrival of service orientation affect 3-tier applications? While there's a lot of interesting talk now about "composite applications" using shared services, the pattern I am observing right now in the field is a little different than what's commonly being conceived.
First off, if a company is starting to adopt service orientation more and more seriously, you're likely to see 3-tier applications modified so that the business tier becomes a business service tier. It's straightforward and natural to turn the former implementation of your business logic (objects, COM+ components, etc.) into services, especially with a powerful tool such as WCF. So now we have something like this, where the business logic is composed of services. This feels more modern, but the app really hasn't changed a whole lot.
The next step for the application comes when the organization wants to make good on the "maximize reuse" promise of service orientation. The app needs to expose some of its services for public consumption by other applications in the company; and/or, the app is expected to consume services that belong to another application. Now the app has private and public services.
The business services tier is now servicing both its "home app" as well as other apps. This additional traffic to the service layer needs to be carefully analyzed; it's quite possible that the 'extra traffic' from other apps could outweigh the load from the original application. You might find yourself scaling out the business service tier to accommodate the extra demand.
For an application to take this shape, a bit of refactoring is often necessary. In an isolated app, you may find developers have been sloppy and put some business logic in the presentation tier. In an app with shared services, however, the app logic really needs to reside in the business tier. It can't be in the presentation tier for the simple reason that an external client never accesses the presentation tier. Typically, there will be some work to make the presentation tier as thin as possible and devoted just to UI. In the same vein, the business services need to perform strong validation--even if a lot of that validation is also duplicated in the presentation tier. Again, an external caller to the business service layer won't be going through the presentation tier.
A good characteristic of this approach is that ownership doesn't change; that is, the people responsible for "App A" are the people who service-enable and maintain "App A". This pattern for service-enabling applications seems to work equally regardless of the topology you happen to use to interconnect your service-enabled applications (direct, hub-and-spoke, ESB).
Contents
ReBlogger Contents
Email TopXML