 |
|
||
|
|
Corba a distributed Journey |
It's sufficient to say I spent a few years trying to learn all there was to know about how to get Corba to work with VisualWorks. {Just follow the story below and ensure you've seen Any Has no Name, Binding Manager madness, An Identity crises, Marshalling at the OK Corral }
But how does it work? Keep in mind there are at least two implementation. One being the HP creation, which was bought by ParcPlace aka ObjectShare now bought by Cincom and bundled as Distributed Smalltalk. The other being SmalltalkBroker from Promia, formally DNS Technologies. I can't say which implementation is better since I didn't have the chance to compare vendors. So I'll go ahead and discuss my exposure to SmalltalkBroker.
My first exposure to Corba was when I was given an image and told "take a look around". First thing I did was run it, then I put in some halts and stepped through the logic. At some point I got to a method call which was to go off and perform a business function. I then innocently asked for the implementation of the method and was told no such implementors existed? Huh? Darn. VisualWorks was lying to me again. Much searching, yet more coffee and a stroll, and I confirmed that the method in fact didn't exist in this image, but why did it work? After some thought and grins from conspirators I realized Corba was at work.
My first exposure to a Corba call!
So what was really going on was when the message was sent to a Corba Object proxy it triggered the proxy's doesNotUnderstand method. The proxy's doesNotUnderstand method then checked to see if the method invoked match the procedure call documented in the ODL (Object Description Language) definition. If so then it serialized or marshaled all the parameters according to their types. Much like BOSSing out objects, Corba has a specification on how to convert objects to data you can transmit on a serial line. Just think 'C Data Structures'
Thus the marshaller would ask each object to marshal itself on a stream. This output was then taken and a TCP/IP socket opened to the remote application, and the information about the identity of the target object, and the contents of the stream sent to the remote ORB based on information the Proxy has on hand about where the remote ORB exists. The ODL indicates if the call is async or sync, if a result is expected, and if any exceptions could be raised. From a debugging viewpoint you just stepped over the method call and magic, the code invoked was 'elsewhere' and of course it did what was asked.
To make debugging easier you could setup the reference to a Corba object that was actually within your image you just asked for the Corba Object Reference to the object, any object in question. The invocation of the call would then really trigger a perform:with: against the actual object in your image, since the doesNotUnderstand logic would determine the object was local versus remote. But there were a few issues since marshaling/unmarshalling didn't occur, and call performance was misleading. But the power here was you could move a class to another image/machine and your application would be none the wiser. Mind you might learn a lesson about application partitioning.
Over in the other Corba application, which could be a Smalltalk image, or a C++ program, or a Java application, it identifies the targeted object using the Object Identifier byte array, and reconstructs the data before invoking a perform:with: against the object of interest, any exceptions are captured and return, if not the result if any is returned. But first you should understand an identity crises, before we go on to look at marshaling at the OK corral