ORB Technical Details

What's the difference between Location Transparency and Distribution? 

We were careful to say that the ORB took care of routing details, not distribution details. That's because CORBA is location transparent: that is, clients make their invocations the same way regardless of where the target object might be. It might be remote, out on the network somewhere, but it also might be local, in the same process as the calling client. 

In component-based applications, which are composed of several component types that call each other to perform the total work process, there are many in-process calls. It's much easier to program this type of application if you don't have to fix the local/remote boundary at coding time. Of course, you do have to fix object location when you assemble the application for deployment, and when you deploy it on your server. 

Where can a reply go?

We were careful to say that the response was routed to its destination, and not back to the client. Using the new CORBA Messaging Service, asynchronous replies return to a callback object. Although this object is usually in the client's process, it can be anywhere on the network.  

What are Session and Stringified Object References?

An object reference in session form is an electronic token that, when associated with an invocation in the way prescribed by the language mapping, allows the ORB to invoke the intended object instance. In this form, there is no information in the object reference that is meaningful to the client. Many ORBs store the information about the object in vendor-specific internal structures; for these ORBs, the session object reference may be a pointer to some part of these structures. 

There is a standard form, termed the Interoperable Object Reference or IOR, that ORBs use to pass object references from one to another across vendor boundaries. To enable IORs to be stored, emailed, printed, and retrieved, the ORB will stringify the reference into a sequence of hexadecimal numbers. Because a stringified IOR contains only alphabetic characters plus the digits 0 through 9, it is guaranteed to pass over the network without being translated by any of the various filters that one finds in routers and such. Although the format is standard, it is a very bad idea for a client to interpret a stringified IOR and and use the information about the object. This breaks encapsulation, and makes the application dependent on aspects the object implementation considers its own, and which may change at any time without notice to the client. Architecturally, this makes the application subject to breakdown. Although this may seem harmless enough for a small application, it can be disastrous for a large application containing years of effort by hundreds or thousands of programmers.  

Last updated on 06/18/2009