Steve Vinoski’s Blog

I see that at least one person on the planet believes I’m the “Father of CORBA.” I can certainly understand why people would think that, but I can definitely say that it’s inaccurate.

In 1989 Hewlett-Packard bought Apollo Computer, where I worked as a diagnostics engineer. Five years prior to that I started my career at Texas Instruments as an electrical engineer working on integrated circuits, and ended up having to write a lot of testing software despite having no software training whatsoever, except for a freshman class in BASIC required for all engineering majors. I found I really liked software, though, so I joined Apollo because the job there was half hardware and half software. By late 1990, though, Hewlett-Packard politics had just about killed the group I worked in, and my manager told me I’d be smart to find myself something else to work on before I was forced to do so. I had been developing a hardware debugger in C++ that involved distributed computing, so I looked around the former Apollo site for any groups using C++ in distributed systems. Turned out Jim Waldo was leading such a group — they were building the first Object Request Broker (ORB). I joined them in January 1991, which was 6 months before the first version of the CORBA spec was published. Ken Arnold was also part of that group. I joined just as they wrapped up the first ORB prototype.

One could argue, therefore, that Jim Waldo is the Father of CORBA, since he led the development of the first ORB. Alternatively, one could argue that Joe Sventek is the Father of CORBA, since he was the editor of the first CORBA specification (Joe was also at HP, though he worked in a different group located in California). However, while they both played important roles in initially defining CORBA, there is to the best of my knowledge no single person who can be called the Father of CORBA. Rather, it was definitely a “design by committee” effort, and I certainly don’t count as one of the fathers since at that time I wasn’t even part of the committee.

BTW, here’s a bit of trivia: for those of you who remember Cliff Stoll’s “Stalking the Wily Hacker” and “Cuckoo’s Egg” publications, documenting his successful effort to identify who was hacking into computer systems at Lawrence Berkeley Laboratory, Joe Sventek’s account was one that the hacker used to gain access. Joe explained to me that he had been away from the laboratory for quite awhile, residing in the U.K. I believe, so red flags went up when there was activity in his account.

When I spoke at QCon San Francisco last November, Stefan Tilkov interviewed me, and the video is now available on InfoQ.com.

We covered a range of topics: CORBA, dynamic languages, REST, distribution, concurrency, Erlang. Stefan asked some great questions, and I hope I gave some worthwhile answers. Thanks again, Stefan.

Regarding the REST and IDL discussion, Joe Gregorio already wrote an excellent explanation six months ago. Perhaps the rest of us should have just linked to it to begin with and avoided wasting our time rehashing it all.

But then again, rehashing is fun! :-) On the same topic, I agree with much of what Dare said, except for this:

When building services with WS-*, you have a WSDL to describe your methods & expected inputs/outputs and XSD schema(s) to describe the schemas for said inputs/outputs. When building a RESTful Web Service, the need for both of these documents does not go away regardless of how often you repeat the phrase “uniform interface”.

I still disagree. The HTTP verb set defines a RESTful uniform interface. When comparing CORBA IDL or WSDL to HTTP web services, that verb set must be considered because it’s the only thing that you can directly relate to IDL and WSDL interfaces. Otherwise, you’re talking apples and oranges. The uniform HTTP interface is the only way for applications to interact with web resources in the same sense that CORBA applications interact with CORBA objects, and WSDL applications interact with WSDL services.

Much of the typical IDL and WSDL definition is devoted to defining one or more specialized interfaces consisting of specialized methods/operations and specialized data types to pass across them. For web resources that use the uniform interface, however, there’s simply no need whatsoever to define interfaces like that. What are you going to do, define GET again and again for each of your resources, each time with exactly the same semantics already specified in RFC 2616? Obviously not.

It’s easy to see that Joe’s OpenSearch document bears no semantic resemblance to a CORBA IDL or WSDL definition. Similarly, an AtomPub service document is nothing like IDL or WSDL either. Both of those documents essentially inform you of service URIs and media types, but they don’t define methods or operations. They don’t have to, because of the HTTP uniform interface. That’s important, and it’s why I disagree with Dare’s point quoted above.

Consider the mindset of the CORBA and WS-* developer. They use systems that force them to always think about all their service endpoints in terms of specialized interfaces. Given how much time I’ve spent in that world (and don’t forget, I still use CORBA too), I know for certain that the concept of the uniform interface is one of the big items that trips these developers up when they try to figure out what REST is about. It’s therefore important to keep the uniform interface as part of the conversation.

Patrick Mueller responded to my previous blog posting on interface definition languages, and I wanted to comment on his response. Long ago Patrick was involved in defining the Smalltalk bindings for CORBA IDL, so he’s a CORBA veteran like me, and in the big picture we agree on many things. It’s nice having him cast a critical eye on this stuff.

Note that Patrick mostly talks about data schemas, whereas my posting talks only of interface definition languages. These are two very different things, which I’ve noted in comments on his blog. In a reply comment he said they’re both metadata, which is true, but still, they’re very separable. REST depends heavily on data definitions, but it doesn’t require specialized interface definitions because it promotes a uniform interface. For data definition REST relies on and promotes media/MIME types, and the standardization of such data definitions is critical to allowing independently-developed consumers and providers to interact correctly. I doubt Patrick and I really disagree on this last point.

One area where we apparently do disagree, though, is in the area of documentation. In my previous post I said that users of services ultimately rely on human-generated and human-readable documentation, not interface definition languages, to ensure their consuming applications interact correctly with those services. Patrick commented:

The documentation? What documentation? I’m picturing here that Steve has in mind a separate document (separate from the code, not generated from the code) written by a developer. But human generated documentation like this is still schema, only it’s not understandable by machines, pretty much guaranteed to get out of sync with the code, probably incomplete and/or imprecise. Not that machine generated schema might fare any better, but it couldn’t be any worse.

But there are more problems with this thought. The notion of hand-crafted documentation for an API is quaint, but impractical if I’m dealing with more than a handful of APIs.

I understand what Patrick’s saying here. Yes, documentation can get stale and out of sync. Still, I disagree. I’ve been near interface definition languages for at least 20 years now, and never once — not even once — have I seen anyone develop a consuming application without relying on some form of human-oriented documentation for the service being consumed. Such documentation might be as simple as a conversation with a developer across the hall, or reading comments in the definition language file itself, or might be from a README, email, a web page, a wiki, a Word document, a PDF, or a whole formal specification. I mean, what if the OMG had published only the ORB and Object Services IDL interfaces without the accompanying reams of human-oriented description and definition? Or if WSDL were enough, why the need for so many pages of human-oriented WS-* documentation?

Like I said in my previous post, interface definition languages exist for machines to generate code. They’re totally inadequate, though, for instructing developers on how to write code to use a service. The need for human documentation in this context isn’t quaint or impractical at all — it’s simply reality.

I have to say that I agree with Ryan Tomayko on this one.

Among other things, Ryan touches on one of the favorite assertions of the REST detractors, which is that REST can’t be effective without an interface/service/resource definition language. After all, without such a language, how can you generate code, which in turn will ease the development of the distributed system by making it all look like a local system? Not surprisingly, the first comment on Ryan’s blog entry is exactly along these lines.

As I’ve been saying for years, trying to reverse-map your programming language classes into distributed services, such as via Special Object Annotations, is an attempt to turn local design artifacts into distributed ones, which we learned long ago is just plain wrong. You often end up paying for such shortcuts in areas such as reliability, flexibility, extensibility, versioning, reusability, and especially scalability.

Back in the halcyon days of CORBA, we generated code from OMG IDL, but IDL is not a local design artifact. OMG IDL was designed from Day One to define distributed systems (though we did add the “local” keyword to IDL sometime around 1999 or so to allow for easier local call optimizations). Note also that unlike the usual approach to defining WSDL, we never reverse-generated IDL from C++, Java, or any other programming language (though a questionable group eventually did come along and, trying to ride the Java popularity wave, define an OMG standard reverse IDL mapping for Java, despite strenuous objections from a number of us, including me). IDL also allowed for generating code in different programming languages for different parts of the same system. But the RPC roots of CORBA, its interface specialization requirements, and the inflexibility of the generated code, especially with respect to versioning, ultimately limited CORBA’s possibilities when it came to medium- to large-scale systems.

Proponents of definition languages seem to assert that such languages help with understandability. Such languages, they say, are required because they alone tell you how to invoke the service, what to pass to it, and what to expect in return. The problem with the way they make this assertion, though, is they make it sound like the application figures all that stuff out on its own with no human involvement. What happens in reality is that an actual human programmer sits down, reads the interface definition, more than likely reads some comments in the definition or a whole separate document that describes the interface in more detail, and perhaps even talks to the person who wrote the interface definition in the first place. Based on the knowledge gained, he then writes the application to call that interface. Similarly, with REST, you read the documentation and you write your applications appropriately, but of course the focus is different because the interface is uniform. Depending on the system, and assuming REST as implemented by HTTP, you might also be able to interact with it via your browser to help understand how it works, which I’ve found extremely valuable in practice (and yes, this works for application-to-application systems that are not designed primarily for browsers or human consumption). But ultimately, there’s no magic, regardless of whether or not you have a definition language.

What the proponents of definition languages seem to miss is that such languages are primarily geared towards generating tedious interface-specific code, which is required only because the underlying system forces you to specialize your interfaces in the first place. Keep in mind that specialized interfaces represent specialized protocols, and IDL was developed oh so long ago to generate the nontrivial code required to have RPC applications efficiently interact over such protocols, since back then computers and networks were far slower and less reliable than they are today, and getting that code right was really hard. When you have a uniform interface, though, the need to generate interface-specific interaction code basically goes away.

(BTW, the first IDL I ever saw was at Apollo, where it was used not only for RPC in the Apollo Network Computing System (NCS) but also to define Domain/OS header files once and generate them into their C and Domain Pascal equivalents, rather than writing and maintaining them twice, once for each language.)

Some REST proponents like WADL. I’ve looked at it but haven’t used it, so I can’t really comment on it. I’ve never felt the need to seek out a resource definition language of any kind for my REST work, at least to date. YMMV.

BTW, on a somewhat related note, I still use CORBA, contrary to what some jackasses out there would like you to believe. In some industries, certain CORBA interfaces are standardized and even legally enforced. In others, leading players have defined CORBA interfaces for 3rd-party integration. These interfaces work, so those companies and industries have no intention of changing them to another technology anytime soon, and in fact they simply have no need to change them at all. I’ve had to work within some of these CORBA scenarios lately, and I have to say I’ve found it to be fun, like meeting up with an old friend you haven’t seen in awhile. I’m sure many of these interfaces could be done better with REST, but they work as is, and there’s just no need to throw them out. Coincidentally Ryan spoke of CORBA when he responded to the commenter mentioned above. All in all, I remain proud of my CORBA work over the years, as we did a lot of good stuff back then, even if since then we’ve found simpler ways of doing a few things.