Oct 28 2000.	marshaling at the OK Corral

In order for us to transmit the object from one space to another across the fiber, copper, ether, or outer space each of these objects imply based on type marshaling logic that dictates how to marshal itself into a stream using OMG rules about marshaling.

Object in general? Always? Can be broken down in to atomic values, number, characters, strings, and other more complex items, like unions, enums and arrays. These had special marshaling representations. Mind you were begging for trouble if you had recursive data elements, that wasn't allowed. Think BOSS then add some restrictions.

The contents of this datastream would be transmitted to the remote application where it was reconstructed. But how? If the object was dumb, easy just recreate the dictionary. Dictionaries with dictionaries would create a complex object. But what if the object was based on a class?

To solve this problem a "Binding Manager" was used to indicate how to bind classes to ODL objects so you had a chance to indicate which "complete creation" method was used to create a new instance of the object in the ORB space (image). Once all the data arrive either a new was sent to the class, and mutators invoked for each data element, or a complete creation method was invoked to rebuild the object. By using a complete creation method you had a chance to recreate a complex object's state since it might contain much more than just the data, since the ODL specification is just the 'public' view of the object. Database accesses, Gemstone and other exotic things come to mind? But beware of Binding Manager madness.

Some people just used dictionaries and ignored the Bind manager. I preferred classes. With real classes one could setup printString to give you a better representation of the object in the debugger, and working with real objects was more enjoyable than dealing with a dictionary anytime.

Corba allows for more than just data objects. Objects could have data AND behavior, again see our example and note the ability to execute "anObject push: aStartEndTimestampInstance" which closes the logic loop, since we can declare both data and behavior. Golly just like a Smalltalk Class.

Now one of the shortcuts applied here by the vendor was an assumption that you knew what you were doing, so if you called a method with an object FOO then FOO would of course behave according to the ODL definition for FOO. Problem was that people sometimes subclassed FOO and created FUM. Now FUM worked just fine with the inherited FOO serialization, or perhaps with its own FUM serialization, you just asked the object to marshal itself. But over in the remote application a FOO object was always created. Just a minor problem if you didn't realize what was happening. Was this a problem?

You bet. Smalltalkers were guilty of a crime against strong typing. In retrospect this was a crime committed by the vendor, I believe their thought was to reduce the amount of type checking involved with a Corba Call, thus the implied logic was that if you had to pass data element FOO, you really passed FOO, not object FUM which kinda behaved like FOO. Better yet a lurking problem in some cases was a person would pass nil (Undeclared Object) over the interface. Now it would of course be marshaled, transmitted, and reassembled, but it certainly was in violation of the type declaration which certainly didn't refer to an undeclared object. {Note some special logic give us the ability to transmit nil and symbols! When we later sent a symbol to a C++ application things got interesting}

Later when we started to use Corba "type any", see any has no name, we suddenly and painfully found the marshaling logic was different. Let's just say I found this late one night before we were about to do a rollout and my code dropped dead when I received a FUM object versus FOO. This caused the other overworked developer down the hall to freak and thus delayed our rollout a week or so while I sorted out the problem, which was:

The 'type any' logic instead of asking the object to marshal itself, would ask the object for its Corba type, and then lookup the master ODL definition and serialize the object based on that definition. Of course FUM would say it's a FOO object, and we would run the FOO marshaller logic based on the ODL definition. Suddenly we might get a failure in the marshaller! Shades of C or C++ .

A C++ programmer would have been forced to type cast the object in question to match the procedure specifications, otherwise the compiler would have complained, but Smalltalkers don't worry about such things, and as I pointed out earlier, a person could be passing nil as a value. Problem was nil is not of type FOO, thus dead in the water.

{Note some ORB vendors actually have a keyword in their ODL language description to indicate if procedure call's parameter can be either nil, or a value. Nice feature, but it's a vendor specific modification to the standard, but sure saves creating those nasty unions}

ARG! Many times we found that the object in question didn't even specify a Corba type and would inherit Smallalk::Object as its type, a slight laziness on part of the programmers, which they hadn't be caught for yet.

To fix these problems some changes were forced on the developers, like having a union object, where case 1 was nil, and case 2 was FOO. This solved the problem where a value could be nil or FOO. Other cases like having FUM look like FOO required rework on the part of the developer.

Oh and lastly how many definitions of a Timestamp do you think your project group can come up with? Remember Joe's Timestamp isn't the same class as Mary's Timesamp even though '=' in Smalltalk works. Remember strong typing will cut you off at the knees. This issue was another fun weekend for some developers as we consolidated timestamp declarations.