WS-Fabric

To my mind, the debate between ESB and WS-Fabric is settled already. But I'm out on a limb here. Dave Chappell has mounted a spirited defence of ESB in an exchange of views with Microsoft program manager Rich Turner, who touts native WS-* infrastructure as the way to go. Meanwhile, ZapThink's Ron Schmelzer has written an opinion piece here at Loosely Coupled that frames the debate within an important wider context, rising "above ... the relatively simplistic discussion of how services communicate."

All these points of view will have a premier forum to parade themselves in Wednesday's ZapForum webcast, The Great Debate: ESBs, Fabrics, or Something Else?. Although I personally have already made up my mind, I think most people still want to weigh up the different viewpoints, understand what the various positions are, and then decide where they stand.

Dave Chappell's extensive post is called ESB and the Road to Indigo. In it, he seems to be arguing that ESB, although most implementations today (including his own employer's) are founded on Java Messaging System, is in fact a multi-protocol entity. If you're going to argue that, I think you end up boxed into a corner where ESB is a kind of EAI-lite, a transitional stepping stone to SOA rather than a foundation for it — less of a burden in costs or resources than earlier EAI options, but still EAI in nature rather than completely platform-neutral.

Dave goes on to define ESB in these terms: "An ESB provides an abstraction layer which separates the business process definition from the underlying physical messaging layer, protocol transports, and service endpoint bindings." This is a fine definition, but my problem with it is this: if that's what ESB does, what role is left for SOA? In other words, ESB is trying to be a surrogate SOA, using JMS as a neutral interoperability transport rather than the pure WS-* stack. Ultimately, writes Dave, the two converge: "An ESB provides a scalable set of cooperating message servers which can be deployed across multiple platforms and managed through a single common management layer ... As WS-RM becomes the prevailing standard for messaging, these message servers will become a scalable set of WS-RM SOAP message routers." So why mess about with JMS in the first place instead of starting out with WS-RM?

That's basically the line that Rich Turner takes in his response, ESB revisited:

"Within the next 18-24 months," he writes, "many major (and smaller) vendors will be supporting WS-* natively within their product sets ... Yes, there will be a need to integrate existing/heritage systems with this brave new world, but this integration should be performed only where necessary, not as a matter of course ... the need for integration technologies such as those proposed by the ESB movement should be increasingly pushed to the outer-edges of the enterprise world, replaced instead by mature platforms that provide most (if not all) of the capabilities of an ESB at each node in the system."

I like this line of argument because it recognises there is a need for capabilities that ESB provides, but it makes clear that those capabilities shouldn't be in some extra layer that sits above the components in the system. They should be fully distributed to every node — or in other words, built into the very fabric of the architecture.

The only problem with the WS-Fabric approach is that it's very idealistic. Yes, in about 18 months' time, anyone building a greenfield implementation with all-new infrastructure will be able to roll out WS-Fabric. Everyone else is still going to have to make compromises. ESB as a stepping-stone to SOA holds much the same attraction as proprietary application servers used to offer as a foundation for n-tier computing. Although you'll tie yourself into a single vendor's solution, that vendor will already have done a lot of the hard graft of setting up the architecture for you. And at least using an ESB package is itself several steps further forward in terms of platform neutrality than relying on an application server vendor to lay the foundations for your SOA.

In his Loosely Coupled opinion piece, ESB, fabric, app servers, brokers: What's best?, Ronald Schmelzer puts the whole debate into the context of SOA implementation, reminding us that the real reason anyone does any of this is to gain a business advantage:

"While developers often focus on the system-to-system aspects of SOA, the business audience is more concerned about the larger business agility, cost of ownership, and governance benefits that SOA must return to justify the investment in architectural change. As such, the discussion of SOA must rise above the technical details ... The important question is not which method of implementation for SOA is the best, but rather when enterprises should discuss the specifics of SOA implementation."

The point, then, is to start from the point of view of what you want to do from a business perspective, and to engineer the implementation in order to support that objective. Ultimately, he writes, the success of an SOA will be judged on how well it separates the ability to manage service definitions, processes, policies and governance from the specifics of the technical implementation, so that enterprise architects and systems developers can manage their respective layers of the architecture without constraining each others' freedom of action.

The implication is that some enterprises will be better off implementing their SOA using an ESB, while others should move directly to WS-Fabric. Presumably there are other options, too, including following the SOA migration paths offered by their incumbent application server vendor or enterprise applications vendor. To find out more about these options, you'll have to sign up to Wednesday's webinar. I certainly shall. I look forward to hearing much more from Ron and also from Dave Chappell's colleague, Gordon van Huizen, as well as Blue Titan's Frank Martinez, who will be putting the case for fabric.

posted by Phil Wainewright 10:38 PM (GMT) | comments | link