Previous | Table of Contents | Next |
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
ObjectId |
Type of Object Reference |
Reference |
|||
RootPOA | PortableServer::POA | Section 11.3.9, “POA Interface? on page 11-34 | |||
POACurrent | PortableServer::Current | Section 11.3.9, “POA Interface? on page 11-34 | |||
InterfaceRepository | CORBA::Repository CORBA::ComponentIR::Repository | Section 10.5.6, “Repository? on page 10-22 Section 10.6.2, “ComponentIR::Repository? on page 10-52 | |||
NameService | CosNaming:: NamingContext | Naming Service specification (formal/00-06-19), the CosNaming Module section. | |||
TradingService | CosTrading::Lookup | Trading Object Service specification (formal/00-06-27), the Functional Interfaces section. | |||
SecurityCurrent | SecurityLevel1::Current or SecurityLevel2::Current | Security Service specification (formal/00-06-25), the Security Operations on Current section. | |||
TransactionCurrent | CosTransaction::Current | Transaction Service specification (formal/00-06-28), the Transaction Service Interfaces section. | |||
DynAnyFactory | DynamicAny:: DynAnyFactory | Section 9.2.1, “Creating a DynAny Object? on page 9-9 | |||
ORBPolicyManager | CORBA::PolicyManager | Section 4.9.3, “Policy Management Interfaces? on page 4-45 | |||
PolicyCurrent | CORBA::PolicyCurrent | Section 4.9.3, “Policy Management Interfaces? on page 4-45 | |||
NotificationService | CosNotifyChannelAdmin:: EventChannelFactory | Notification Service specification (formal/00-06-20) | |||
TypedNotificationService | CosTypedNotifyChannelAdmin::Typed EventChannelFactory | Notification Service specification (formal/00-06-20) |
Table 4-1 ObjectIds for resolve_initial_references
ObjectId |
Type of Object Reference |
Reference |
|||
CodecFactory | IOP::CodecFactory | Section 13.8.2, “Codec Factory? on page 13-34 | |||
PICurrent | PortableInterceptors::Current | Section 21.4.3, “Portable Interceptor Current Interface? on page 21-34 | |||
ComponentHomeFinder | Components::HomeFinder | CORBA Components specification. | |||
PSS | CosPersistentState:: ConnectorRegistry | Persistent State specification (ptc/01-12-02). |
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.