CHAPTER 20
CORBA CASE STUDY
to whether it is invoked synchronously or asynchronously. (One
exception is theTransaction Service which would need to be aware of the difference.)
Asynchronous RMI adds two new variants to the invocation semantics of RMIs:
• callback, in which a client uses an extra parameter to pass a reference to a callback with each invocation, so that the server can callback with the results
• and
polling,
in which the server returns a valuetype object that can be used to poll or wait for the reply. The architecture of asynchronous RMI allows an intermediate agent to be deployed to make sure that the request is carried out and if necessary to store the reply. Thus it is appropriate for use in environments where clients may become temporarily disconnected – as, for example, a client using a laptop in a train.
20.2.4 CORBA remote object references
CORBA 2.0 specifies a format for remote object references
that is suitable for use,
whether or not the remote object is to be activated by an implementation repository.
References using this format are called interoperable object references (IORs). The following figure is based on Henning [1998], which contains a more detailed account of
IORs:
• The first field of an IOR specifies the type identifier of the IDL interface of the
CORBA object. Note that if the ORB
has an interface repository, this type name is also the interface repository identifier of the IDL interface, which allows the
IDL definition for the interface to be retrieved at runtime.
• The second field specifies the transport protocol and the details required by that particular transport protocol to identify the server. In particular,
the Internet Inter-ORB protocol (IIOP) uses TCP, in which the server address consists of a host domain name and a port number.
• The third field is used by the ORB to identify a CORBA object. It consists of the name of an object adapter in the server and the object name of a CORBA object specified by the object adapter.
Share with your friends: