Middleware Matters

My colleagues Peter Cousins and Ivan Casanova like to use audio/video connectors as an analogy for service-oriented architectures (SOAs). Audio has been a long-time hobby of mine, ever since I was 14 or so. A few years ago I built my own home theater. Consider the rear panel of my Denon 4802 receiver:

Wow! Look at all those connectors! Ignoring the speaker and power connectors, there are RCA audio connectors, digital coax connectors, optical cable connectors, RCA video connectors, S-video connectors, and component video connectors. Why so many?

Today, video sources such as DVD players tend to support multiple connection choices: RCA, S-video, and component video. Depending on the quality of service I desire, I pick whichever one I want. Component video gives me the best video quality, S-video next, and the lowest common denominator RCA after that. For audio, I can do Dolby decoding either within the DVD player or within the receiver, whichever I think sounds best. Basically, whatever the DVD player supports, the Denon receiver can handle, and since the DVD player offers multiple connection choices, I can choose the one that best suits my system.

These connection types change over time. But I shouldn't have to replace all the components of my home theater every time someone devises a new approach! Having a receiver like the Denon 4802 capable of accepting and delivering so many different connection types and formats means that I can use my components for many years, without needing to entirely replace the system every time a new connector approach is devised.

In the land of middleware, this is precisely how SOAs are supposed to work. A service is defined not by the protocol or the transfer syntax used to communicate with it, but by its semantics and what it does for the service consumer. A consumer should be able to connect to a service via any reasonable means and use it.

Unfortunately, the middleware industry is largely blind to this revelation. Instead, it remains hung up on protocol and transfer syntax, failing to separate them from the services themselves. SOAP (over HTTP) is of course the darling protocol and transfer syntax of the day, but that will change. It will eventually fall out of favor. Numerous protocols and transfer syntaxes came before SOAP, and numerous others will follow. Do you rewrite your services every time something new comes along?

Our web services Artix product is a lot like that Denon 4802 receiver, in that you can connect to it in a lot of different ways. Your services are likely written in multiple programming languages and are likely hosted over multiple middleware systems running on multiple operating systems. Every other middleware vendor wants you to rewrite your services to use their platform every time they come up with a new idea -- they promote homogeneity despite the fact that computing systems are naturally hetergeneous. With Artix, you can leave your service in MQ, or TIBCO, or Tuxedo, or CORBA, or whatever. Artix can get to it, transparently and with extreme efficiency, even if your service consumer sits on top of a totally different technology. You worry about your service, and let us worry about the connectors and infrastructure required to future-proof both your service and its consumers.

I arrived in Porto, Portugal this morning to attend the ICEIS Web Services Workshop. I have to give the keynote for the workshop on Wednesday. The title of my talk is "Extending Web Services Bindings for Real-world Enterprise Computing Systems."

In addition to looking forward to that workshop, I'm looking forward to catching up with Jim Coplien. Cope has been a positive influence on me and many others for many years due to his work in C++ idioms, patterns, and multi-paradigm design. I look forward to spending some time chatting with him.

Due to my attending ICEIS in Portugal, where Internet access was not easy to come by, I'm a little late in commenting on Jim Webber's and Savas Parastatidis's article about "Why WSDL Is Not Yet Another Object IDL" in the Web Services Journal.

Overall, the article unfortunately states some rather serious misunderstandings regarding object IDL. Since I've been involved in CORBA for 13 years now, I'll focus my comments on CORBA IDL. First, the article claims that, with IDL, "there is always a conceptual association between an interface and an in-memory representation of an object." While this is true of COM IDL, it's wholly and completely wrong with respect to CORBA. A CORBA interface states only what operations and attributes an object supports, not how an implementation of the object is laid out in memory. CORBA supports a rich variety of object implementation approaches in multiple programming and scripting languages, ranging from one programming language instance per interface, to multiple instances per interface, and even to a separate application for each operation or attribute in an interface. Because most CORBA ORBs are written in C++ or Java, everyone thinks the CORBA spec requires a programming language instance per CORBA object instance, but that's not true at all. For example, DEC's ObjectBroker ORB, one of the first ORBs to support CORBA many years ago, supported a separate program per operation, thus allowing an interface to be implemented by a group of server-side applications.

The article also states that "the type system [of the IDL] characterizes the application since more than one type system cannot coexist (e.g., the type system of CORBA, DCOM, Java RMI, etc.)." This is also wrong for CORBA. For example, for many years IONA has supported a COM-CORBA bridge, and now also supports a .NET-CORBA bridge. In addition, our Artix product effectively joins multiple type systems together and lets them coexist. Granted, not every type from one system can always be easily or practically mapped to another (as I described in my May/June 2003 IEEE Internet Computing column entitled "It's Just a Mapping Problem"), but what we find in practice is that most applications tend to stick to types that are reasonably mapped between type systems.

I agree somewhat with this paragraph from the article:

While it is usually a mistake to do so, consumers of a WSDL document may choose to use it as if it were an IDL document. In fact, many of the current Web services development tools do just that by converting WSDL documents to classes with methods and presenting an object-oriented view of the world to developers.

I wrote about this issue two years ago, also in my IC column, in the May/June 2002 issue, entitled "Web Services Interaction Models, Part 1: Current Practice." However, mapping a WSDL interface into an object class is nowhere near as bad as mapping programming language classes into WSDL, which is what a number of WS toolkits do, most notably .NET. That approach fosters in inexperienced users a complete inability to understand what levels of abstraction are appropriate for the Web Services level vs. the programming language level. It fails to separate implementation from interface.

Also, in the example section, the article talks about wanting to add an operation to get the title from a Book object and, to do so for an object system, having to "recompile the entire application since a shared abstraction has changed. " Bzzt, that's wrong too. In CORBA, you can easily add operations to objects, rebuilding only the object implementation. Existing clients continue to work with no recompilation, no problem. CORBA has versioning problems, but this isn't one of them.

I think that one of the few things the article gets right is its implication that WSDL can support looser coupling than CORBA IDL. By that, I specifically mean that the type system is more flexible, the message exchange patterns can be more easily varied, and it's much easier to add new bindings for other protocols and transports, as we've so successfully done with Artix. With CORBA, you need an ORB on both ends, and having written six of them, I can assure you that ORBs are not easy to write or get right. In reality, CORBA and Web Services are complementary rather than competitive, as I explained a few years back in the "Object Interconnections" column that Doug Schmidt and I write in the C/C++ Users Journal. That particular column, written all the way back in September 2001, was entitled "CORBA and XML, Part 3: SOAP and Web Services." IONA has numerous customers who have successfully deployed systems comprising a mixture of CORBA and Web Services, and they're all happy with the results.

Over on The Mountain of Worthless Information, Ted Neward comments on my critique of the "Why WSDL Is Not Yet Another Object IDL" article.

In Ted's opinion, I missed an important point that the authors were trying to make: that what really matters is not what WSDL or IDL can each do, but what people actually do with them.

While I agree with Ted that people abuse this stuff, I think he must not have read the articles I linked to from that blog posting, otherwise I doubt he would have claimed I missed that point. Not only have I been making that very point in the Web Services space in writing for at least three years, in fact I was making that same point back in the early days of CORBA, over a decade ago. Back then, one of the most popular questions on CORBA mailing lists and newsgroups was, "How can I turn my [insert favorite programming language here, usually C++ back then] objects into CORBA objects?" My response then was the same as it is now: don't do that. The granularities, levels of coupling, and abstractions of the programming language object are wrong for the CORBA object level, just as they're also wrong for the Web Services level.

So, I invite Ted to read this article and this article, for example. I also invite Ted to recall this exact quote from my previous blog entry:

However, mapping a WSDL interface into an object class is nowhere near as bad as mapping programming language classes into WSDL, which is what a number of WS toolkits do, most notably .NET. That approach fosters in inexperienced users a complete inability to understand what levels of abstraction are appropriate for the Web Services level vs. the programming language level.

Not sure how much clearer I can make it!

Sadly, while Ted, I, and many others agree on this issue, the battle to make it more widely understood is far from over, and may even be pointless, given that Microsoft explicitly promotes this approach with their programming language extensions that allow people to directly declare classes as web services.

The blogosphere occasionally shows unusual alignments. First, Jon Udell mentions in his blog my notion of "middleware dark matter", which I first wrote about nearly two years ago. I used the term "dark matter" to refer to middleware based on dynamic languages such as Python, Perl, PHP, Ruby, etc. that invisibly and yet very successfully runs many systems out there, especially the Web. In my universe, at least, everyone talks about "traditional" middleware such as J2EE, CORBA, EAI, and MOM, and there's nary a mention of these dynamic languages as middleware. Jon correctly points out that there's a parallel universe where the opposite is true, where everyone is instead normally focused on using dynamic languages for integration, and there's little to no attention paid to J2EE, CORBA, and friends. Maybe it's like the "Mirror Mirror" episode from the original Star Trek series -- perhaps somewhere out there, there's another Steve Vinoski, but only with a moustache and beard like Spock's, who views my traditional middleware as dark matter. I wonder which one of us is the evil one?

Then, the ever-insightful Sean McGrath talks about "baking the distributed computing abstractions you want into the heart of the programming languages programmers will use," with the goal being to realize "RESTian SOA." He mentions both Python and Ruby as examples of such programming languages. I couldn't agree more -- while we Java, C++, and C# snobs think we're the only ones out there who can actually program, we need to get over ourselves. Not only do our numbers pale in comparison to the masses out there who are successfully developing applications in such "dark matter languages," often our programming capabilities and productivity pale in comparison too.

After that, the also-ever-insightful mnot commented on Sean's comments, saying that REST is what we really need to bake in. I agree. Someone added a comment to mnot's post saying that with tools like the Eclipse IDEs that support incremental compilation and refactoring, you can get the power of dynamic languages in non-dynamic languages, but I don't agree, because the dynamic languages are just easier, quicker to develop and deploy, and most importantly, can be a lot more flexible at runtime.

This particular "blogosphere alignment" provides another indication of something I've been slowly realizing for awhile, the very something that drove me to write the "middleware dark matter" piece in the first place: that the world really is moving away from edit/compile/debug approaches using statically typed languages toward more of a dynamic language "edit and run" approach. Apparently mnot and likely many others are all independently also realizing the same. As a long-time Perl user and occasional Python hack, this is way cool. I love it when a plan comes together.

On a related note, I coincidentally learned the other day while building Perl 5.8.x on my Linux box that my name is still in the Perl distribution. It got there because I ported Perl to Apollo Domain/OS back in, I think, 1988. It's amazing that running the Perl configure script today is basically the same as it was way back then. (BTW, Domain/OS was, and still is, the best OS ever, though OS X, which I really like, is starting to come close to matching it.)

On Wednesday evening I received a great phone call on my cell phone while at home. It was Don Box. I've known Don since about 1995, from when we used to speak at the same technical conferences, he about COM, me about CORBA. He is an all-around great guy.

Don called to take issue with something I wrote about COM IDL in a recent blog entry. Specifically, he took me to task for this:

First, the article claims that, with IDL, "there is always a conceptual association between an interface and an in-memory representation of an object." While this is true of COM IDL, it's wholly and completely wrong with respect to CORBA.

Don wondered if I was trying to take a dig at COM IDL. I can definitely say that that wasn't my intent. What I was trying to do was guess which IDL the authors of the "WSDL vs. IDL" article were thinking of when they said that IDLs imply in-memory object representations. I thought of COM only because of its use of vtables for object dispatch, but as Don correctly pointed out, the vtable choice is independent of COM IDL. In re-reading what I wrote, I see that I could have worded it better to avoid making it seem like a contentious half-truth. Thanks, Don, for pointing this out to me.

Don also said that he felt that in pointing out that ASP.NET allows you to directly map methods on programming language classes into web services operations, I made it seem like it's the only toolkit that does that. Again, that wasn't my intent. I chose that one only because I felt most people would be familiar with it. Lots of web services toolkits, especially the early ones, have provided features that help directly expose programming language artifacts as web services. The main reason for this is expediency -- it helps developers get services up and running quickly with minimal fuss. While I maintain that such exposure is the wrong way to do things, it doesn't do any good to sit on a high horse about it, because people are going to do it no matter what. If a customer asks for such a feature, you give it to them, because if you instead lecture them that this isn't the right way to do things, they'll simply take their business elsewhere.

Anyway, Don, thanks for the constructive feedback. I hope this clarifies things. It certainly was good to hear from you.

I'm currently attending the OMG Technical meeting in St. Louis. I came here to present on two topics:

1. IONA would like the OMG to standardize a CORBA binding for WSDL. Such a binding, which we already successfully support in our Artix product, allows CORBA servers to be abstracted to more easily handle invocations from non-CORBA clients, and to allow multi-middleware clients (similar to those of WSIF) to natively invoke CORBA services without requiring SOAP-IIOP gateways. I'll present a draft Request for Proposals (RFP) for this at the next meeting. (I hope this doesn't reignite the recent "WSDL vs. IDL" debate.)
2. I presented some further progress on my work to add reflection/introspection into CORBA. Such a facility would make integration of CORBA systems with other middleware easier. I originally described this work in a C/C++ Users Journal article, but I've modified it quite a bit since that article was published. One major change, for example, is to add the ability to obtain object metadata in the form of a CORBA 3.x ExtFullInterfaceDescription struct, as suggested by Frank Pilhofer from Mercury, which keeps applications from having to use the Interface Repository (which nobody really uses anyway). I'm hoping the OMG will eventually adopt work this via its Request for Comments (RFC) process, but I still have work to do on the metadata XML schema.

After I presented this morning, I spent the afternoon and evening finishing up my OOPSLA paper reviews. Boy, was that a lot of work! It was well worth it, though -- looks like some really good papers will be presented at OOPSLA this year.

Bill de hÓra makes some good points, as do Tim Bray and others: the web services specs are somewhat out of hand.

I think one reason we have so many web services specs is that we have a terminology problem, specifically with the term "web service." If you're really talking about services that are programmatically accessed over the WWW without human intervention using standard Internet protocols, then everything written about REST and HTTP and XML and messages definitely applies. I was a charter member of the now-defunct W3C Web Services Architecture Working Group (WSAWG), and the first thing we set out to do was to define what a "web service" is. Something close to the definition above was in fact one of the first candidates. After two or three months of arguing, we finally settled on something along those lines, only to have the whole question reopened several months later. Not being able to exactly define a "web service" was what doomed the WSAWG to ineffectiveness and eventual extinction. I mean, how can you define an architecture for something unless you know what it is? Different WSAWG members had very different ideas of what a "web service" was, and those different ideas often conflicted with each other, preventing any real progress.

Like it or not, however, the term "web service" is often used to apply to things that don't fall precisely under the definition above. Most of the people I encounter in my circles, for example, use "web services" to describe intra-enterprise business services that can be accessed over a variety of protocols. These services are not and will never be offered over the WWW. They're not necessarily RESTish. They don't need to scale to web scale, and never will. Some are stateful, some are not. They might in fact be steaming piles of poorly designed and poorly written code, and in fact are often built on what many purists might consider to be obsolete technologies. Regardless, what's most important about them is that they work, and so these businesses want to make them even more valuable by making them much more accessible within their businesses. They're happy to describe these services in WSDL, since that helps them abstract the services, but they don't want to have to redesign them or rewrite them or change their protocols or adopt new unproven approaches just so they can ensure that the services conform to some purist's view of what's a "real web service."

The end result of this terminology issue? Lots of people argue endlessly about web services, and they write myriad specs for web services features, but they're often neither arguing about nor writing about the same thing. Not even close.

So what do you call these services? The term "service" is too generic. "Business service" and "computing service" are no better. For better or worse, "web service" is currently the best term to use for them, especially given that (at least in my circles) they all have WSDL definitions, and WSDL includes the word "web." Perhaps WSDL should just be called SDL. I take issue with the purists who say that a "web service" is defined as a SOAP-based service, nothing more, nothing less. It's like saying that a Domino's pizza shop shall only take verbal orders over the phone, and if it accepts orders via a website or by fax or from a person who physically walks into a shop and verbally speaks their order to an employee, then it's not a Domino's pizza shop. Obviously such a restrictive definition is pointless, because what customers ultimately want is the service that Dominos provides, regardless of how they request it. Similarly, what ultimately matters with a "web service" is the "service" part, not the "web" part.

So, I'm afraid that we're stuck with the numerous web services specs, at least for awhile, because "web services" has become such an umbrella term. Some of those specs will prove to be useful in practice, others won't. Like many others, I also take issue with many of those specs, but in the end, the market will naturally cull the herd.

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.