WHAT
IS IMPORTANT FOR INTEROPERABILITY BESIDES IIOP?
The IIOP
specification provides resolve initial references as a mechanism to obtain an
initial object reference. This object referenced must be implemented with the same
ORB product as the client. If this is not the case, then string to object can
be used. CORBA 2.0 does not provide a mechanism to transport this string or
provide direct access to “foreign objects” The Interoperable Name Service
specification will address this and other related problems.
WHAT IS AN
IOR?
An IOR is an
Interoperable Object Reference. It is a specialized object reference. An IOR is
used by an application in the exact same way that an object reference is used.
An IOR allows an application to make remote method calls on a CORBA object.
Once an application obtains an IOR, it can access the remote CORBA object via
IIOP. The CORBA object can be implemented with any CORBA 2.0 compliant product
that supports IIOP. The application that obtains the IOR can be developed with
a different CORBA 2.0 product. The application constructs a GIOP message and
sends it. The IOR contains all the information needed to route the message
directly to the appropriate server.
ARE
IORS OBTAINED IN THE SAME MANNER AS OBJECT REFERENCES?
Obtaining
IORs is exactly the same as obtaining object references. The one caveat is that
ORB::resolve_initial_references returns an IOR but it
usually must be implemented within the same CORBA product environment.
CAN
AN APPLICATION REFER TO OBJECTS IMPLEMENTED WITH MULTIPLE CORBA PRODUCTS?
Well,
they’re sure supposed to be able to do so. Here’s how.
Let us
assume that an application needs to access two objects. Object A is implemented
with CORBA product Aa and
object B is implemented with CORBA product Bb. Let us look at several
scenarios:
The
front-end application will be implemented with CORBA product Aa: The simplest approach is for the front-end application
to obtain an object reference to A by calling ORB::resolve_initial_references(). Since the
front-end application is implemented with product Aa
it cannot obtain an object reference to B by calling ORB::resolve_inital_references(). It can acquire
the stringified object reference to B and convert it
to an IOR by calling ORB::string_to_object(). How
does it obtain the stringified object reference?
Object B’s constructor could be implement to stringify
itself and write the string to a file that is accessible to the front end
application (access might be provided by NFS). Every CORBA product that
supports IIOP should be support ORB::string_to_object().
The
front-end application will be implemented with CORBA product Cc: This scenario
is very similar to the first. The application can not use ORB::resolve_initial_references() since neither object A or B
are implemented with product Cc. The front end application will obtain an IOR
to A and an IOR to B by first acquiring stringified
object references. It will then converting the strings to IORs by calling to
ORB::string_to_object(). Every CORBA product that
supports IIOP should be support ORB::string_to_object().
The
front-end application will be implemented with CORBA product Cc. It will obtain
IORs A and B from product Cc’s implementation of the CORBA NameService.
It will not need to acquire any stringified object
references. The real question is how are IOR A and IOR B bound within product
Cc’s CORBA NameService. The processes implementing
object A and Object B must acquire an object reference to product Cc’s CORBA NameService. This can only occur by obtaining a stringified object reference to product Cc’s CORBA NameService. How is the stringified
object reference to product Cc’s NameService
initially created? A simple application implemented with product Cc obtains the
NameService by calling ORB::resolve_inital_references(),
it then stringifies it by calling ORB::object_to_string(), once this has been done it externalizes
the string so that it can be accessed by the processes implementing object A
and B.
Note: Stringified objects cannot be exchanged using CORBA based
communication. This is your classic catch 22 situation
CAN CORBA
VENDORS SIMPLIFY INTEROPERABILITY AND THE PROCESS OF OBTAINING OTHER VENDOR’S
OBJECT REFERENCES?
CORBA
vendors can simplify the process of obtaining external object references by
providing small pieces of code designed only to create external IORs. This
might be a function called ExternalORB::create_external_references(). Vendors could provide this
code to the public or directly to other ORB vendors.
WHAT
IS THE INITIALIZATION SERVICE?
The
Initialization Service is used to find well-known system and user-defined
services. The Initialization Service is best understood in the catch-22
presented by the Name Service:
If the Name
Service holds the system’s application object references (IOR)...
...and the
Name Service, itself, is composed of NamingContext
objects (IORs) for storing and retreiving application
IORs...
...and a
client cannot access an object until it has its IOR...
...then, how
does a client get a reference to a root NamingContext?
The answer
to the above question is that the reference has to be supplied to the client
administratively. The Initialization Service provides a simple interface into
this administrative information. The method is named “resolve_initial_reference()”
and takes a string representing the name of the service, and returns a
CORBA::Object accessing that service.
WHAT
ARE THE IDL INTERFACES DEFINED WITHIN THE COSNAMING MODULE?
The CORBA
Name Service is composed of two basic interfaces. The NameContext
and the Binding Iterator. Remember that since the NameContext and the Binding Iterator
are both CORBA interfaces, they are accessed via object references and are
distributed. The NameContext contains “named” object
references or other “named” NameContexts. It is
similar to a directory that can contain named files or other named directories.
NameContexts and Binding Iterators
are usually implemented in the same Name Server process, but this is not a
requirement. The CORBA NameService can be constructed
as a set of interconnected NameContext objects and NameService processes.
The BindingIterator is used to iterate across object references
contained within a particular NameContext. It
basically provides a mechanism to get the number of named object references
within a NameContext. It also provides a next_one and a next_n operation
to retrieve individual named object references or contexts. Continuing with the
directory analogy, The BindingIterator is a mechanism
to do a ls or dir operation on a directory.
HOW
DO I USE A NAMECONTEXT?
The NameContext interfaces supports two main operations, bind
and resolve. Once a NameContext object reference is
obtained, it can be used to “name” some other CORBA object, or retrieve an
object reference by name. This means that you can call the bind method on a NameContext passing it an object reference and a name. This
will place a named object reference into the NameContext
for future resolve calls. If an application wishes to obtain an object
reference by name is simply obtains the appropriate NameContext
and call resolve with the particular name. This will cause the named object
reference to be returned to the application making the resolve invocation.
WHAT
IF I DO NOT KNOW THE NAME OF THE OBJECT?
The CORBA NameService was designed to allow object references to be
obtained by name. Names need to be either agreed upon between servers or
clients, or perhaps passed between components in the distributed application.
It is also possible to use the BindingIterator
interface to connect to any name object reference. The CORBA trading service
might be more appropriate if the CORBA NameService is
too limiting. Other architectures such as factories might be appropriate
mechanisms to obtain object references.
WHAT
IS THE INTEROPERABLE NAME SERVICE (INS)?
The
Interoperable Name Service (INS) fixes a technical glitch in the original CORBA
Name Service. The original Name Service did not truly allow object references
from different ORB vendors to be stored and accessed from within a single Name
Server. This is fixed by the INS. There are no API or IDL changes, so
application developers should not notice a difference.
WHAT
IS THE EVENT SERVICE?
The CORBA
event service provides support for the producer/consumer pattern. It support a
channel which provides the producer with the ability to create “events” and the
consumers with the ability to receive these “events”. Events are any valid IDL
defined interface or data type. Both consumer and producer applications must be
a CORBA server. There may be multiple channels in use. A single channel may
have multiple producers and multiple consumers. A consumer receives all the
events on the channel.
No comments:
Post a Comment