1157-1160

Previous Table of Contents Next

Page 1157

The CORBA Architecture

The basic CORBA architecture can be expressed in terms of three primary components : the client, the Object Request Broker (ORB), and the object implementation. The client requests services from the ORB. The ORB locates the object implementation required to satisfy a particular request, invokes a method of the implementation (possibly passing data received from the client as parameters), and returns a result received from the implementation to the client. The implementation exposes methods to be invoked by the ORB, performs any operations required to satisfy the request (reads a record from a database, for example), and returns results to the ORB.

The client has no knowledge of the underlying implementation. It knows only how to access the ORB and request a service. It may have knowledge of specific interfaces, which are invoked through client stubs or directly by using supplied IDL definitions to form the invocation. You can use dynamic invocation to generate interface-independent invocations at runtime. Dynamic invocations must specify an object, a method, and the types and values of the supplied parameters. This information can be hard-coded, read from a configuration file, or read from an interface repository. Software to support dynamic invocation resides on the client, and, regardless of the means of invocation, the resulting request is the same.

The ORB provides services to both clients and object implementations through several interfaces, which may be implemented as separate components. The IDL stubs and dynamic invocation interface are client interfaces. When an ORB receives a request through one of these interfaces, the ORB core is responsible for locating the object implementation, invoking the method, passing parameters, and transferring control to the implementation. The ORB core invokes methods on object implementations through IDL skeletons or the dynamic skeleton interface. IDL skeletons and the dynamic skeleton interface are roughly analogous to the IDL stubs and dynamic invocation interface in the client.

An object adapter provides the interface between the ORB and the object implementation. An ORB supports one or more object adapters, which can be used by object implementations to generate object reference identifiers, resolve existing object references, or authenticate requests. The ORB core may support multiple object adapters for different types of objects. In any case, interaction between object adapters and the ORB core is ORB dependent and completely transparent to the client.

When a method is invoked on an object implementation, the implementation might require additional services supplied by an object adapter to satisfy the request. An object implementation can require an opaque reference to another ORB-based object as a parameter, for example. The implementation would use an object adapter to resolve the reference. This service can be provided by the adapter itself, or it might need to access services in the ORB core.

The ORB interface provides generic services to both clients and object implementations. These basic operations are object adapter independent and ORB independent and include ORB initialization, location of initial object references, and basic operations on object references. An

Page 1158

ORB supplies operations to copy an object reference, release an object reference, compare two object references, and so on, for example. Examples of ORB initialization and location of initial object references are provided in the "Binding Server Objects in the Name Service" section, later in this chapter. Figure 52.1 illustrates the interaction between the basic components and interfaces of the CORBA architecture.

Figure 52.1.
CORBA components
and interfaces.

The architecture defined by the CORBA standard provides enough structure to ensure interoperability between ORB implementations while providing enough flexibility for ORBs to be implemented in almost any language and optimized for specific tasks .

Page 1159

Internet Inter-ORB Protocol

The Internet Inter-ORB Protocol (IIOP) is based on General Inter-ORB Protocol (GIOP). GIOP defines the basic data representations, message formats, and general transport assumptions for inter-ORB communications. IIOP is a mapping of GIOP to a specific transport: TCP/IP. The concepts described in this section apply equally to the GIOP specification and conforming IIOP implementations. The actual message format defined by GIOP is fairly complex, so only the key features are highlighted here.

The Common Data Representation (CDR) defined by the GIOP specification maps all IDL datatypes to low-level byte representations. In general, all types are converted into one or more 8-bit values (defined as octets in IDL), which are guaranteed not to be converted during transmission. Basic types (short, long, float, and so on) are aligned along natural boundaries. A 32-bit long, for example, is converted to 4 octets. Constructed types are encoded by the primitive types defined within them. Additional information may be required to express a constructed type. A string is encoded as an unsigned long containing its length, for example, and the individual characters that make up the string (including a null terminator). "Hello", for example, would be represented as a stream of 10 octets: 4 octets for the length, 5 octets for the individual characters , and 1 octet for the null terminator. These octet representations simplify the process of marshaling and unmarshaling on diverse platforms.

The GIOP message format includes a header that indicates the message type, message length, and other useful information (such as the byte order). Byte order information is particularly important, because it allows messages encoded on little-endian platforms to be decoded on big-endian platforms and vice versa. Table 52.3 lists the possible message types and their originators.

Table 52.3. GIOP message types and their originators.


Message Type Originator
Request Client
Reply Server
CancelRequest Client
LocateRequest Client
LocateReply Server
CloseConnection Server
MessageError Both

A message can consist of as many as three components. All messages have a GIOP message header; some also have a message-specific header and a message body.

Page 1160

Request messages are sent by the client. They contain a request header (in addition to the GIOP message header) and a request body. The header is used to uniquely identify the request, identify the target object and method, and identify the requesting principal. The request body contains any in or inout parameters that must be supplied.

LocateRequest messages also are sent by the client. These messages are used to locate a particular service or to validate an object reference and method. LocateRequest messages have no body and can be used to minimize retransmission of long parameter lists as an optimization in large, distributed systems.

CancelRequest messages are sent by a client to notify the server that a reply to a Request or LocateRequest no longer is expected. This is treated as a "suggestion" to the server. The client cannot assume that processing will be halted on the server or that a reply will not be sent. This message has no body. The CancelRequest header contains the ID of the message to be canceled .

The server sends Reply messages in response to client requests. The Reply header contains a status code, which indicates whether an exception occurred, and can indicate that a Request should be forwarded to another object. The body of the reply contains the return value and any out or inout parameter values. If the status indicated that the message should be forwarded, the body contains an object reference to use as the new target.

LocateReply messages are sent by the server in response to LocateRequest messages. The LocateReply header indicates that the request can be satisfied, is unknown, or should be forwarded to another object. If the request should be forwarded, a new target object reference is included in the body.

CloseConnection messages are sent by the server to notify clients that the connection is being closed so that clients know they should not send additional requests and that any pending replies will not be sent. If a client receives this message when one or more replies are expected, this message should be treated as an error. The message consists of the GIOP message header only.

MessageError messages are sent by the client or the server in response to a message that could not be interpreted. The MessageError message also consists of the GIOP message header only.

This simple overview of IIOP is provided as background information. When using a vendor-supplied ORB, the messaging layer often is transparent to the developer, and methods are invoked on remote object references as if they were local. However, a basic understanding of the ORB protocols can be very useful in interpreting cryptic error messages and tracking down bugs . The full specification is readily available for those interested in the specific details of the protocol at http://www.omg.org.

Previous Table of Contents Next


Oracle Unleashed
Oracle Development Unleashed (3rd Edition)
ISBN: 0672315750
EAN: 2147483647
Year: 1997
Pages: 391

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net