Yes, “CORBA objects are virtual” but they are still part of the architecture

Steve Vinoski replies to my “Love the message campaign”. In his post, he explains that CORBA does not imply a particular implementation technology. Indeed, I cannot argue with that and I have no misconceptions that this is the case. One could implement CORBA using a procedural language, untyped, scripting language if they wanted, say CORBA/tcl-tk for example. No disagreement there.

However, what about the architecture? How will an architect design the application? How will the components of the architecture be glued together? How would one reason about the components/actors of the architecture? In service-orientation we have services and messages (refer to my earlier post… expect more on that front soon). In object-orientation we have objects and that suggests, to me at least, that we have state (even if we don’t see it), an interface to that state, and a reference to that state. We can pass references to objects around and we invoke methods through those references. Yes, we can do clever things like late binding, treat an object as a service, etc. But these tricks are introduced into the architecture as tricks rather than being a fundamental part of it from the beginning. I may not have a good understanding of what an object is in an object-oriented architecture so I welcome other descriptions/definitions/corrections.

Now, in CORBA the “O” stands for “Object”. The architecture is object-oriented in nature. Don’t get me wrong. I really like object-orientation and I use it all the time. Even the focus of my PhD research was the development of an object-based, all-in-software, distributed memory system for a tightly coupled parallel system. It is my belief, though, that object-orientation (please note that I am separating the architecture from the implementation technologies and I am concentrating on the former) is not the best model for building internet-scale applications.

I am not an expert in CORBA so I am ready to be corrected from heavyweights like Steve but I thought that CORBA encourages an architecture that is object-oriented in nature. It encourages the creation of distributed applications where the abstractions are the objects and the way of “communication” is the method invocation (again, I am talking about architecture abstractions and not implementation details). WSDL was created to describe message formats (despite some people’s efforts to focus on the “operation” abstraction). When WSDL is used to describe method invocations, then effectively we reason about the architecture as being a collection of objects on which we can call methods, we introduce a level of coupling between the invoker and the actor which is seen as an object (again, at the architecture level 🙂

I have no problem with describing message exchanges using WSDL and then binding those message exchanges to various underlying transports or other distributed objects technologies. What I am afraid of is how such bindings are going to be (mis)used when building systems that directly expose their implementation details because that will be the easy thing to do. Many Web Services advocates agree that representing services as objects to the programmers is not the right level of abstraction. Is there anyone who doesn’t see tools emerging which will be generating CORBA objects stubs in Java from WSDL documents?

This is the reason I was so keen to focus everyone’s attention to the importance of the message and the focus on services and messages rather than other forms of abstraction.