4.5.2 Obtaining Initial Object References

   Applications require a portable means by which to obtain their initial object references. References are required for the root POA, POA Current, Interface Repository and various Object Services instances. (The POA is described in the Portable Object Adapter chapter; the Interface Repository is described in the Interface Repository chapter; Object Services are described in the individual service specifications.) The functionality required by the application is similar to that provided by the Naming Service. However, the OMG does not want to mandate that the Naming Service be made available to all applications in order that they may be portably initialized. Consequently, the operations shown in this section provide a simplified, local version of the Naming Service that applications can use to obtain a small, defined set of object references that are essential to its operation. Because only a small well-defined set of objects are expected with this mechanism, the naming context can be flattened to be a single-level name space. This simplification results in only two operations being defined to achieve the functionality required.

   Initial references are not obtained via a new interface; instead two operations are provided in the ORB pseudo-object interface, providing facilities to list and resolve initial object references.

   list_initial_services

   typedef string ObjectId;typedef sequence <ObjectId> ObjectIdList;ObjectIdList list_initial_services ();

   resolve_initial_references

   exception InvalidName {};

   Object resolve_initial_references ( in ObjectId identifier ) raises (InvalidName);

   The resolve_initial_references operation is an operation on the ORB rather than the Naming Service’s NamingContext. The interface differs from the Naming Service’s resolve in that ObjectId (a string) replaces the more complex Naming Service construct (a sequence of structures containing string pairs for the components of the name). This simplification reduces the name space to one context.

   ObjectIds are strings that identify the object whose reference is required. To maintain the simplicity of the interface for obtaining initial references, only a limited set of objects are expected to have their references found via this route. Unlike the ORB identifiers, the ObjectId name space requires careful management. To achieve this, the OMG may, in the future, define which services are required by applications through this interface and specify names for those services.

   resolve_initial_references never returns a nil reference. Instead, the non-availability of a particular reference is indicated by throwing an InvalidName exception (even if a nil reference is explicitly configured for an ObjectId).

   Currently, reserved ObjectIds are RootPOA, POACurrent, InterfaceRepository, NameService, TradingService, SecurityCurrent, TransactionCurrent, DynAnyFactory, ORBPolicyManager, PolicyCurrent, NotificationService, TypedNotificationService, CodecFactory, PICurrent, ComponentHomeFinder and PSS.

   Table 4-1 ObjectIds for resolve_initial_references

   Table 4-1 ObjectIds for resolve_initial_references

   To allow an application to determine which objects have references available via the initial references mechanism, the list_initial_services operation (also a call on the ORB) is provided. It returns an ObjectIdList, which is a sequence of ObjectIds. ObjectIds are typed as strings. Each object, which may need to be made available at initialization time, is allocated a string value to represent it. In addition to defining the id, the type of object being returned must be defined; that is, “InterfaceRepository? returns an object of type Repository, or ComponentIR::Repository, which is derived from Repository, depending on whether the ORB supports components or not, and “NameService? returns a CosNaming::NamingContext object.

   The application is responsible for narrowing the object reference returned from resolve_initial_references to the type that was requested in the ObjectId. For example, for InterfaceRepository the object returned would be narrowed to Repository type or ComponentIR::Repository type, depending on whether the ORB supports components.

   Specifications for Object Services (see individual service specifications) state whether it is expected that a service’s initial reference be made available via the resolve_initial_references operation or not; that is, whether the service is necessary or desirable for bootstrap purposes.

   4.5.3 Configuring Initial Service References

   4.5.3.1 ORB-specific Configuration

   It is required that an ORB can be administratively configured to return an arbitrary object reference from CORBA::ORB::resolve_initial_references for non-localityconstrained objects.

   In addition to this required implementation-specific configuration, two CORBA::ORB_init arguments are provided to override the ORB initial reference configuration.

   4.5.3.2 ORBInitRef

   The ORB initial reference argument, -ORBInitRef, allows specification of an arbitrary object reference for an initial service. The format is:

   -ORBInitRef <ObjectID>=<ObjectURL>

   Examples of use are:

   -ORBInitRef NameService=IOR:00230021AB...

   -ORBInitRef NotificationService=corbaloc::555objs.com/NotificationService

   -ORBInitRef TradingService=corbaname::555objs.com#Dev/Trader

   <ObjectID> represents the well-known ObjectID for a service defined in the CORBA specification, such as NameService. This mechanism allows an ORB to be configured with new initial service Object IDs that were not defined when the ORB was installed.

   <ObjectURL> can be any of the URL schemes supported by CORBA::ORB::string_to_object (Section 13.6.10, “Object URLs? on page 13-24), with the exception of the corbaloc URL scheme with the rir protocol (i.e., corbaloc:rir...). If a URL is syntactically malformed or can be determined to be invalid in an implementation defined manner, ORB_init raises a BAD_PARAM exception.

   4.5.3.3 ORBDefaultInitRef

   The ORB default initial reference argument, -ORBDefaultInitRef, assists in resolution of initial references not explicitly specified with -ORBInitRef. -ORBDefaultInitRef requires a URL that, after appending a slash ‘/’ character and a stringified object key, forms a new URL to identify an initial object reference. For example:

   -ORBDefaultInitRef corbaloc::555objs.com

   A call to resolve_initial_references (see the “NotificationService?) with this argument results in a new URL:

   corbaloc::555objs.com/NotificationService

   That URL is passed to CORBA::ORB::string_to_object to obtain the initial reference for the service.

   Another example is:

   -ORBDefaultInitRef \

   corbaname::555ResolveRefs.com,:555Backup.com#Prod/Local

   After calling resolve_initial_references(“NameService?), one of the corbaname URLs

   corbaname::555ResolveRefs.com#Prod/Local/NameService

   or

   corbaname::555Backup411.com#Prod/Local/NameService

   is used to obtain an object reference from string_to_object. (In this example, Prod/Local/NameService represents a stringified CosNaming::Name).

    Section 13.6.7, “Profile and Component Composition in IORs? on page 13-22 provides details of the corbaloc and corbaname URL schemes. The -ORBDefaultInitRef argument naturally extends to URL schemes that may be defined in the future, provided the final part of the URL is an object key.

   4.5.3.4 Configuration Effect on resolve_initial_references

   Default Resolution Order

   The default order for processing a call to CORBA::ORB::resolve_initial_references for a given <ObjectID> is:

   1. Resolve with register_initial_reference entry if possible.

1. Resolve with -ORBInitRef for this <ObjectID> if possible

2. Resolve with pre-configured ORB settings if possible.

3. Resolve with an -ORBDefaultInitRef entry if possible.

   ORB Configured Resolution Order

   There are cases where the default resolution order may not be appropriate for all services and use of -ORBDefaultInitRef may have unintended resolution side effects. For example, an ORB may use a proprietary service, such as ImplementationRepository, for internal purposes and may want to prevent a client from unknowingly diverting the ORB’s reference to an implementation repository from another vendor. To prevent this, an ORB is allowed to ignore the -ORBDefaultInitRef argument for any or all <ObjectID>s for those services that are not OMG-specified services with a well-known service name as accepted by resolve_initial_references. An ORB can only ignore the -ORBDefaultInitRef argument but must always honor the -ORBInitRef argument.

   4.5.3.5 Configuration Effect on list_initial_services

   The <ObjectID>s of all -ORBInitRef arguments to ORB_init appear in the list of tokens returned by list_initial_services as well as all ORB-configured <ObjectID>s. Any other tokens that may appear are implementation-dependent.

   The list of <ObjectID>s returned by list_initial_services can be a subset of the <ObjectID>s recognized as valid by resolve_initial_references.