Although there are variations of this pattern, the most 'pure' version is where a layer is ONLY called by the layer above it. Lower layers will attempt to respond to calls from the next higher layer. However if the layer requires assistance, it can only make calles to the layer directly below it.
IBM has recently made a stab at a "partial layered architecture":
In reviewing this diagram, the obvious question is, "what the heck are those two vertical layers?" The equally obvious answer is - "those are the areas where the (horizontal) layered architecture are violated!" I feel quite comfortable saying that IBM's layers 6 and 7 gotta go (as layers). On occasion, an architecture can be modified whereby it is classified as a hybrid, but even then, the author must be VERY CAREFUL to make sure that they didn't just kill the intent of the original architecture.
Let's get to the root of any layered architecture. They all look like this:
- The very top layer is the 'Ask Only'.
- The very bottom layer 'Respond Only'.
- All layers in between are both (they ask and respond).
That said, it is pretty safe to put the human interface as the very top layer :-) To my dismay, humans still don't implement WSDL's. Until then, I'm comfortable keeping IBM layer 5 (the ultimate client).
The bottom layer is quite tricky. One might think that it would be safe to drop things like ERP, CRM and legacy apps there. However, the truth is that those applications will be the MOST LIKELY to be clients of business and technical services! Hence, I am equally comfortable killing Layer 1.
Layer 2, had me stumped. It is hard to dispute that services could sit on top of components. But on that note you could argue that components sit on top of objects, and objects sit on top of virtual machines, etc. At the end of the day, I believe that components shouldn't be depicted in the enterprise view of a layered service network. A more appropriate view of this relationship should be in the 'service view'. If a service is designed with a layered approach, it may be appropriate to show the component-to-service layering. Hence, I am equally comfortable killing layer 2 (from the enterprise view).
Layers 3 & 4 are tricky. Here is the big question: "Is there ever a time when a composite service needs to call a process orchestration?" (Will layer 3 need to know about layer 4?). I'd like to say that there will be a clean separation between process logic and business logic, but I'm just not sure. It seems as though IBM is having a tough time separating functional concerns from mechanism. The aggregation of one or more services using a loosely coupled technique (like BPEL, itinerary based routing, content based routing, etc.) will find it's way into both composite services as well as into process orchestration. And tagging flow of control logic as either 'process', 'workflow' or 'business' is extremely hard and IMHO, impractical from a layered architectural perspective.
The fact is, process services, business services and technical services WILL all leverage intermediaries. This means that they all require direct access to that layer. As much as we (Momentum) would like to break them into separate layers, we can't do it without significantly violating the rules of the layered architecture. The solution that we landed on was 'embedded layers'. Here, we create a service network view which has a pure layered approach. Then the types of services are once again layered. And lastly, the pieces of a single service are layered.
The following diagram is part of the Momentum Web Service & SOA Reference Architecture:
I believe that this diagram depicts the intent of the IBM architecture without violating the constraints of the architectural patterns.
No comments:
Post a Comment