Middleware Matters

I figured Jim would take issue with my previous blog entry, because I recall previously reading Jim's negative views of WSIF.

Jim asks:

Why have a CORBA binding in WSDL? We already have IDL which does that job. Why have a Java binding? Why have a DCE binding? Why have a DCOM binding? You see where I'm going here - there are already interface definition languages for all of these, so WSDL didn't need to go round providing bindings for them (ok - allowing bindings for them).

Let's say I'm the CIO and I value my business computing services. Of course, my enterprise is heterogeneous, as pretty much all are because of numerous natural forces such as the march of technology, vendors coming and going, autonomous organizations making their own purchasing decisions, home-grown middleware, mergers and acquisitions, etc. My CEO wants me to get even more value out of my business computing services, however, and wants broader integration of the enterprise. How can I get this menagerie of technologies and approaches to work together?

Any solution that requires "ripping and replacing" is not viable. I can't afford to have teams of developers trying to rewrite these services with whatever the technology du jour is. For one thing, I simply can't afford it. And even if I could, it would take so long to redevelop, retest, and redeploy these new services that the current technology du jour would be obsolete by the time I finished. Furthermore, many of these services are critical to our business, and we don't have time to debug and qualify their new technology replacements.

Solutions that require me to wrap these services with gateways or "web service front ends" are also out of the question. Such approaches simply add numerous moving parts to an already-complicated system. This means more intermediary processes to manage, more expensive server hardware to buy, more network hops to cross, more data conversions into and out of these intermediaries, all with an end result of added cost and reduced service performance.

What's a poor CIO to do?

A better approach is to avoid intermediaries entirely by making service endpoints and caller endpoints capable of speaking multiple protocols and handling multiple message/data formats over multiple transports. A service can then freely expose a logical WSDL contract that's reachable over whatever physical bindings it chooses to provide, and service consumer infrastructure simply chooses the appropriate binding to call or invoke the service. With this approach, consumer applications depend only on the logical service contract, and are not polluted with physical details about protocols, transfer syntax, or transports.

Why WSDL, rather than the myriad interface definition languages and programming languages that Jim would seem to prefer instead? That's easy. A service has a single logical contract independent of its physical communication details. Like I said in my previous blog entry, you get the same service from a pizza shop whether you order by phone, over the web, by fax, or in person. That's a true SOA. By describing that single logical contract in WSDL, my application code has to deal with only a single service model regardless of the underlying physical bindings. And that's a huge win, as it avoids the need for me to try to cram multiple technologies and models into my application just to integrate my various middleware systems.

Jim, if you still think this can't work, then I invite you to talk to IONA's customers who have systems running on our Artix product that do exactly this. They've realized literally millions of dollars in savings from eliminating all the unnecessary and expensive intermediary hardware and software in the middle. If I may paraphrase my colleague Peter Cousins, the technical director for the Artix product, disintermediation is where it's at.

Jim goes on to ask:

The point is that an entity (I won't call it a service) designed to be consumed by RMI just won't be a good fit for a service designed to be consumed via SOAP. So you can bind this entity to anything you want, but there will only be one comfortable fit - the native binding - and why do I need WSDL in that case?

WSDL defines both the logical service contract and the physical bindings. The logical service contract is independent of the bindings, which only describe possible ways of getting at the service. If you write your application against the logical contract, then you're relieving it from dependencies on underlying technologies, thus helping to protect your investment and giving you the flexibility to change and upgrade technologies without requiring "rip and replace." Like I said above, we have this working in production right now, so unlike Jim, I'm not only hypothesizing about this.

Jim says WSIF is wrong for allowing multiple pluggable bindings. Given the explanation above, I obviously disagree. WSIF does have problems, but not the ones Jim mentions. First, it doesn't go far enough, because it's consumer-side-only and provides no support on the service side for providing access over multiple bindings, and second, it's Java-only. Fortunately, Artix doesn't limit you with such restrictions.