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.

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

  1. Mark Little
    Just ’cause you’ve got objects doesn’t mean you have state. Quote: “In object-orientation we have objects and that suggests, to me at least, that we have state”, which is an incorrect statement. Languages like Smalltalk80, C++ and ObjectiveC encourage an OO methodology, but state is something that is not addressed. Unless you’ve got a different meaning to “state”.
  2. Hey Mark… Obviously we don’t have the same definition of “state”. In order to call a method in C++ you need to have a reference or a pointer which refers/points to an instance of a class. This instance is represented in memory somehow and is seperate from other instances of the same class. It occupies different parts of the memory. I personally see the memory it occupies as state (whether or not the class has been declared to have private data variables). In an object-oriented _architecture_, objects are treated in a similar fashion. Different instances of the same class have different “state”/”contents”. If their “contents”, their “state” is not different why bother having different instances? I’d be interested in examples of objects that don’t encapsulate state.
  3. Mark Little
    Definitely a completely different notion of “state”, particularly when you mix it with CORBA and even Web services. I’d have said the more common interpretation of state in those cases is to do with durable (persistent) representations, e.g., cookies. I’d have gone with something like “In object-orientation we have objects, which are methods and possibly associated instance variables”. I think the in memory handling of multiple objects (class instances) and how operations are despatched (e.g., through a virtual function table) is a bogus argument at best. No matter what architecture is used, something needs to reside in physical memory in order to receive a message. OK, in some architectures I might have a different entity for each “type” of message, whereas in others it might be one entity that can handle lots of different messages “types”. But each entity represents some combination of real and virtual memory. As to objects that don’t encapsulate state, well there are quite a few, but here’s a sample: a square-root function, a cube-root function (!), a console driver, an encrypt engine, … Hopefully you get the picture. There are a number of reasons why you’d want to use multiple entities to do some of this work; for instance performance and reliability.
  4. Mark, I used the memory representation argument as an example of how an object looks like in C++ and how state is seen in that environment because you mentioned it. I didn’t connect it to the CORBA/Web Services discussion. I am surprised that you see a square-root function as an object. I prefer to call it just “function”. A book, a car, a person, a computer are objects. The words in a book, the parts of a car, the organs of a person, the components and programs of a computer are the state of those objects. These are things that can be referred to in a traditional OO manner and can be accessed through their interface. Yes, we can see everything around us an object and we can attempt to model it as such. But is this really how we want to start building distributed applications? Then, why did the CORBA community have to introduce the notion of a “service”?
  5. Mark Little
    We’ll have to agreed to disagree about stateless objects then, but there are many examples of OO toolsets that provide precisely these kinds of objects. You’re imposing your own notion of what an object is on the discussion, which isn’t exactly objective. It could even be argued that your view of objects is colouring your arguments and hence is why you view objects in that way, i.e., if the definition of an object really was more flexible then maybe your argument wouldn’t hold up 😉 (Very circular.) The OMG introduced the notion of services for a collection of objects that work together to fulfill a specific requirement. Seems like a pretty good notion of what a service is too. Importantly, they weren’t forced to introduce a notion of “service”, as your post implies. CORBA Services have been around since 1991, with the POS, CCS and OTS. If you actually go and look at some of these specifications, you’ll find that really all they define is the IDL (interface) for the service: they don’t say how you implement it. Which is really good, because then you can use non-OO techniques if you have to. For instance, Tuxedo from BEA (though originally from AT&T) is a heavily message oriented system designed around the idea of a bulletin-board isn’t written in C++, but can be mapped into an OTS. Likewise, the OTS can be backended with the X/Open XA protocol, which definitely isn’t OO by any stretch of the imagination! If you go back to DCE, which predates CORBA, and AnsaWare (a European equivalent), they all had a notion of services too. It’s a common theme going back many years: it wasn’t invented by Web *services*, and certainly wasn’t something that was forced on to these other architectures because they somehow got their original ideas wrong.
  6. Mark, (just to clarify) I’ve never suggested in any of my posts/articles that the ideas of service-orientation are new. However, I have suggested and I still believe it to be the case that service-orientation != object-orientation. Yes, it is possible to do service-orientation using an architecture that is object-oriented in nature, like CORBA. However, I like to distinguish the two. It seems that others (e.g., WS-RF) can’t make the distinction. It is my fear that because some can’t make the distinction, we will end up with applications that don’t scale. Finally, I don’t think I am imposing my own view of what an object is. I just don’t try to call everything around me an object 🙂
  7. Mark Little
    I prefer thinking about closely-coupled versus loosely-coupled systems. How they are implemented (objects, services, hamsters) is a secondary issue IMO.