Bionic Buffalo Tech Note #25: Quick Start Guide to Writing CORBA Server Applications
associated with specific servants, but will not return the references. To obtain the references for the
new objects, one of the
POA operations servant_to_reference() or id_to_reference
() must be invoked.
These operations need not be done in a servant. An application can them invoke outside of any servant
if it has the
POA and maybe the servant references, and a servant for one object can create objects for
another servant. To get the
POA,
From within a servant, the application can use
ORB::resolve_initial_references() to
find “POACurrent”, which will be an object of type
PortableServer::Current. That
object's
get_POA() operation will return the POA for the current request.
From outside a servant, the application can use
ORB::resolve_initial_references() to
obtain the Root POA, then use
POA::find_POA() to find the specific POA needed. (This works
from within a servant, too.)
In any case, finding the servant (if needed) is language mapping and application dependent. Also, it is
not necessarily obvious from the CORBA documentation how to obtain a reference for the
ORB from
within a servant: the operation is the same as for any other application, namely,
CORBA_ORB_init
().
Once the servant or any other application has an object reference, it must somehow make that
reference available to clients. The common mechanisms are summarized in more detail in Tech Note
#20, but are again listed here with some mention of server (rather than client) considerations:
Name service. The client will need the name of the object, which can be sent as a string using non-
CORBA mechanisms.
Trading service. The client will need the attributes of the object, which can be sent using non-
CORBA mechanisms.
Object identifier. This method is used for fundamental objects such as the interface repository. This
method is not generally applicable to application objects.
Object URL. The simplest way to create an object URL is to invoke the
ORB's
object_to_string() operation, which will return a string which can be understood by another
ORB's string_to_object() operation. The interoperable string can be transmitted among
programs by any ordinary mechanism. Object URLs may also be constructed manually by the
application, when the type of URL specifies a commonly understood and well specified technique
such as the name service.
.
External Mechanisms. Details of this mechanism, if used, will depend on the implementation.
Unless the object reference is in string form (as a URL, perhaps created by
ORB::object_to_string), it is not generally portable among different ORBs. Non-string
references may be passed among
ORBs only as arguments to operations mediated by the ORBs
involved.
Page 7 of 12