SOA Patterns: Edge Component

The business rationale behind going on the SOA road is the ability to increase the alignment of the business and IT. Consequently, we divide the business into a bunch of business services and everything is just fine. However, the minute we start diving into the SOA implementation details, we are swamped by a horde of technologies, cross-cutting concerns (auditing, security, etc.), and whatnot.

For example, in one project I was involved with, we implemented an SOA over a messaging middleware (Tibco's Rendezvous). Just when everything was fine and dandy, along came another project which could potentially use a few of the services. Well, almost. It needed a slightly different contract and it also used completely different wire protocol -- WSE 3.0 (Microsoft interim solution for the WS-* stack before Windows Communication Foundation). And that's just one simple example. Cross-cutting concerns and implementation details are everywhere. The question is then:

How can you handle cross-cutting concerns like multiple technologies, protocols, changing policies, etc., while keeping the service focuses on its core concerns -- that is, the business logic

You can get the full pattern from here.

[This is an early draft of one of the Service Structural Patterns from my SOA Patterns book.]

Posted by Arnon Rotem-Gal-Oz at 01:38 PM  Permalink