(Part of the CORBA FAQ, Copyright © 1996-99)
A transient, opaque handle that identifies an object instance in your ORB. An object reference is the identifier needed to invoke methods on objects.
Object references are not global identifiers that are valid across all machines in a distributed network. Their scope is limited to your local ORB.
[ Top | Bottom | Previous section | Next section ]
CORBA is a dynamic environment and objects move around in an unpredictable manner. You need a soft locator rather than something static and brittle.
[ Top | Bottom | Previous section | Next section ]
Only during the session while your client is connected to the ORB. If a target object moves during a session, the ORB will provide the equivalent of a transparent forwarding mechanism.
[ Top | Bottom | Previous section | Next section ]
Stringify the object reference and save it in a persistent medium. But, we have to warn you, you’re about to get into deep water. Maybe you should just skip to the section on Naming Service, unless you want to be an “expert”.
[ Top | Bottom | Previous section | Next section ]
Use object_to_string(), and reverse the process using string_to_object(). There is some magic in string_to_object(); it not only does the necessary string-to-pointer conversion, it ensures that you get a currently valid object reference that is equivalent to the original reference that was stringified (i.e., both refer to the same object instance).
[ Top | Bottom | Previous section | Next section ]
We can’t tell you because there is no standard for this. OMG wanted to give ORB implementers as much freedom as possible to develop efficient, possibly platform-dependent schemes. Thus, the references are opaque and should be thought of as an interface without regard for their implementation.
[ Top | Bottom | Previous section | Next section ]
Some ORB calls such as resolve_initial_references() and string_to_object() generate an object reference. The object it refers to might or might not exist (the act of using the object reference can result in the creation of the actual object).
Also, a factory might create an object reference by creating an object implementation within the same process. The factory could generate the object reference and cause an object to be created (as above), or the factory could obtain the object reference from some other source (NameService, TraderService).
[ Top | Bottom | Previous section | Next section ]
Use is_equivalent(), but don’t take it too seriously. This method never lies to you, if it says two references are equivalent, then they are. But they might be equivalent but not identical and is_equivalent() can potentially return false. See the October 1996 column by Steve Vinoski and Doug Schmidt in C++ Report.
[ Top | Bottom | Previous section | Next section ]
Remember that is_equivalent() is invoked on one of the two objects, and there are cases where this can cause deadlock. The following example illustrates how this can happen on one particular single-threaded ORB that won’t allow a server to invoke a method on the client (contributed by Jeff Stewart, jstewart+@andrew.cmu.edu; used with permission):
Suppose a server receives updates from cached clients and then has to update all clients except for the one that reported (updating the reporting client would cause a deadlock on this ORB). So, as the server iterates through its client list it must ensure that it does not invoke the reporting client. But it can’t use is_equivalent() because this will eventually cause an invocation on the reporting client just to do the is_equivalent() check, inadvertently creating a deadlock.
[ Top | Bottom | Previous section | Next section ]
Not really. You also have to remember that it typically requires network traffic. It’s easy to fall into the wishful thinking that the ORB can handle is_equivalent() for you, but, in general, it doesn’t.
[ Top | Bottom | Previous section | Next section ]
First, the object may have moved in between the times that its references were stringified, so the strings may not be identical. Also, there are potential problems if you have multiple vendors because stringified object references can be quite ORB-specific.
[ Top | Bottom | Previous section | Next section ]
No, not at all. We’ve taken you into the depths of a topic that has deep philosophical roots, which has been the focus of arguments for many years. Most people never need this kind of knowledge. We warned you earlier, didn’t we? And you just had to know, didn’t you?
[ Top | Bottom | Previous section | Next section ]
From a practical standpoint, these considerations don’t come up all that often, even for people who have to work at this level. Fortunately, most users can merely use the Naming Service and work with (essentially) character strings for names, and avoid all the complexity above.
[ Top | Bottom | Previous section | Next section ]
You’re the one who wanted to be an expert. We just wanted to raise your awareness so that you’ll think twice when comparing object references. Besides, this is a good way to illustrate how CORBA requires a little learning on your part.
[ Top | Bottom | Previous section | Next section ]
The IDL compiler will generate code that typedefs your interface to a CORBA_Object.
[ Top | Bottom | Previous section | Next section ]
Two ways, _var and _ptr. The idea behind _var is to force automatic memory management, where allocation is off of the stack and memory is returned when the object reference goes out of scope. On the other hand, _ptr object references require specific management, including freeing memory at the appropriate time.
[ Top | Bottom | Previous section | Next section ]
Use _var when you can, because they are simpler. Use _ptr when you have to, usually for performance reasons. Sometimes there are critical windows you can’t afford to let the system take over memory management. As a very rough guide, think about _ptr when you have many fine-grained objects and known timing or performance problems.
[ Top | Bottom | Previous section | Next section ]
Then you need to know about interoperable object references (IOR).
[ Top | Bottom | Previous section | Next section ]
Yes, because this is something that inherently requires cooperation between different vendors and ORBs. Ordinary object references exist within an ORB so there was no compelling reason to standardize formats.
[ Top | Bottom | Previous section | Next section ]
The specific details can be found at the OMG web site, and probably shouldn’t matter to you. But it doesn’t hurt to know that an IOR consists of a type ID and one or more tagged profiles.
[ Top | Bottom | Previous section | Next section ]
A tag indicates the protocol ID from the most recent protocol change as the IOR flowed from its home ORB to your local ORB (we’ll discuss what this is all about when we get into more detail on bridges and interoperability), and is something that is registered with OMG; for instance, IIOP has an ID of zero.
[ Top | Bottom | Previous section | Next section ]
A high-performance way for an ORB to tell another ORB what it needs to know to use the IOR properly. There are two types, single- and multiple-component. Both typically contain information about the presence of ORB services such as Transaction Service.
[ Top | Bottom | Previous section | Next section ]
It depends. Profiles are defined by the people who developed the protocol and registered its tag with OMG. IIOP uses a single-component profile, while DCE CIOP uses a multiple-component profile.
[ Top | Bottom | Previous section | Next section ]
You’ll probably never need them because you’ll probably never see an example of an IOR. These only exist in the nether world between ORBs.
[ Top | Bottom | Previous section | Next section ]
It doesn’t. Your local ORB creates a local proxy for the remote object represented by the IOR. All your program ever sees directly is the object reference for the proxy. The ORB takes care of everything else.
[ Top | Bottom | Previous section | Next section ]
You never learn, do you? Let’s discuss this at another time. When you are in a position where you need this knowledge, you won’t be getting your information from this document. In the meantime, learn all about Naming Service.
[ Top | Bottom | Previous section | Next section ]
[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]
[ Top | Bottom | Previous section | Next section ]
E-mail us