Middleware Matters

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.