Layers in a Service Network

The concept of a layered architecture has deep roots in computer science. It has been applied to protocols, networks, operating systems, containers and applications. In 1996, POSA Volume I clarified the meaning of the layered architecture. The pattern states that the lower layers are 'unaware' of the higher layers. In this manner, layers are used as an abstraction mechanism to facilitate decoupling.

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.

Will AMQ Rock Wall Street?

I believe it was this article which prematurely blew the lid on a new protocol called AMQ.

Even the SOA Group is speculating....

The answer is... wait and see. I've been told by the best of sources that this project will be unveiled shortly...

N-Service Computing

Explaining Web Services, SOA and related concepts isn't always so easy. In my attempts to make these concepts easy to understand by the masses, I've landed on the term "N-Service Computing". And I'm using the following diagram to explain what I mean:



I've found that by showing this simple diagram people usually understand a few key points:
1. Service computing is an evolution of prior efforts
2. Services are the new unit of work
3. Services are part of a network

Obviously, this single slide doesn't explain everything, but I've found it to be a good introduction.

WS-LAMP

Dozens of bloggers have discussed the use of the LAMP stack as a foundation for SOA and service oriented construction. However, the "P" in LAMP traditionally meant using one of several dynamic languages like Perl, Python or PHP. Today, IBM announced their blessing of PHP and is announcing that it will become more Web service friendly. This may be the first of several steps to redefine their core programming strategy, see:

http://news.com.com/Big+Blue+backs+PHP+for+Web+development/2100-7344_3-5589559.html?tag=nefd.top

Clearly, IBM has to be very careful about what they are doing here. The last thing they want is to introduce confusion around their core Java based WebSphere products. However, IBM has excellent disciplines around milking mature products and introducing stars without prematurely killing their cash cow. It will be interesting to watch them slowly commercialize this area. They'll want to be perceived as a leader in the space (by geeks) while simultaneously disavowing the concept to CIO's until the calculus tells them that there is more profit in slaughtering the cow and having the feast - - but this is clearly no time soon.

That said we have a conundrum. Generally speaking, the "open source types" prefer simple mechanisms over complex ones. In the Web services world this means that they like "REST" not "WS-*". Now, IBM has a different view - - they fundamentally understand the value proposition of decoupling functions from their non-functional concerns. IBM realizes that mission critical systems require policy based agreement to the ilities. More importantly, they understand that the compose-ability of services increases with the ubiquitous commoditization of the non-functional concerns... and you're average open-sourcer, well, doesn't even know what that means.

IMHO, we can expect to see IBM fund the research, technology, engineering and marketing around the WS-LAMP space. This might be look like an open source play, but long term, this is an enterprise move.

SOA, Just an Application Server?

BEA's Alfred Chuang was recently quoted:

Are your new products, like Quicksilver (messaging integration software) a way to diversify your products?
It's not to diversify. It's filling the parts. At our size, we can't just sell products anymore. We have to sell both products and vision. We don't have a choice. We can't just keep selling the application server, saying, "But this is SOA. SOA is just an application server." We've got to tool it enough so that people say, "Ah, I understand."

It is good to see that BEA sees SOA as more than just an application server. What is less clear is if they intend to leverage their application server assets as the core to their SOA strategy.

I understand why BEA may decide to position the SOA battle on AppServer-Hill. They own that hill (or at least they used to). Is it possible that the BEA army will be waiting on the wrong hill for a battle that will never occur? Perhaps - or perhaps IBM will bring the battle to that hill knowing that 1. They can 2. They'll easily beat BEA. And of course, Microsoft will state that AppServer-Hill doesn't even exist.

Competitors will take the battle to a new hill, ServiceNetwork-Hill. They'll argue that clumping a bunch of tightly coupled Java API's together under session-clustered JVM's is silly. They will also be quick to note the 'coupling levels' within the J2EE platform and the fact that it was hard coded to support three configurations: one-tier, two-tier and three-tier (not N-Service). The competitors will tell you to read the J2EE blueprints and best practice guides to reinforce their point. The J2EE stack fundamentally wasn't designed to support a distributed service network. It's very name "application server" seems to reinforce it's goal. The complete lack of progress in the JSR arena on creating 'service networking' concepts indicates the strategy, resource allocation and potential adoption timelines.

It is extremely hard to make the transition from one paradigm to the next. When I was employed by a mainframe software company, it was clear to me that the client-server guys were going to kick our butts. It was equally clear that the application service guys were going to win over the PowerBuilder types. And yes, to me, it is once again clear that the service network guys will win over the application server companies.

The door has been left wide open to the startups to create the next big thing in enterprise computing. I wish you the best of luck.