Networking / Beginners

---

The Architecture

COBRA is a client-server architecture. The client is a management agent that performs operations on objects that are controlled by the server. The client and server are connected by the Object Request Broker (ORB), which is responsible for correlating the location of the client and server and managing the communications between them. This architecture protects the client from knowledge of the location of the server for each object and allows local and remote objects to be managed in a uniform way.

The Object Management Architecture (OMA) is illustrated in Figure below. Central to the architecture is the ORB that is responsible for relaying the client's requests to the correct component at the correct location. Client requests are typically passed to the ORB through an application interface developed for the specific management application. Application interfaces are usually developed for specific purposes or management applications, although because these purposes are sometimes common, they may be standardized by the OMG. The ORB delivers the requests to the appropriate components, which may be local or remote. Common facilities are utilities or operations oriented toward applications, and they may be common across multiple applications such as system and task management, operations on distributed document handling, and information management such as the embedding of an object from one application within a document from another application. Common object services (COS) are the underlying common functions used by the ORB to answer the requests issued by the client. COS include the necessary components to ensure end-to-end delivery of object transactions, and also common services that range from object location and naming, through the management of object relationships, persistence and life cycles to timing, security, and event notifications.

The domain interfaces are a collection of components that serve purposes similar to those of the common facilities and COS, but have scope limited to a particular application (that is, to a specific domain). These components are specified as part of the object definition, but if any of them is discovered to be common across multiple domains, it may be standardized and moved into the set of common components.

Finally, the ORB delivers object operations to the server for application to the objects themselves through the object adaptor. Like the application interface, the object adaptor is domain specific (that is, it is developed for managing a specific set of objects) and implementation specific, converting between the standard ORB requests and the local server implementation. In particular, the object adaptor may convert between the public and standard form of an object and the local storage format.

Figure below shows the interaction between the ORB and the client and server in more detail. It also shows the information repositories that are held at the client and server. The interface repository is held on the client and contains information about how the objects are handled, such as the interfaces and data attributes. The implementation repository is held on the server and contains the information that allows the ORB to locate and manage the objects; it also contains the active values of the fields within the object.

Interaction between client, server, and an ORB is handled by a set of components that provide abstraction and mapping functions. Communication between ORBs is provided by a general protocol with a specific adaptation to bridge the gap to TCP/IP.

There are three components that provide the application interface from client to ORB. The ORB interface is a standard abstract interface to the ORB defined by the COBRA specification to allow application implementations to be decoupled from the ORB with an abstract representation of the objects. The IDL stub provides a mapping of object formats between the local application and the ORB. This mapping is important when the local application has not been coded using an IDL programming language-ORB development kits typically support mappings to standard languages (e.g., C, C++, and Java) and provide IDL compilers to allow new objects to be defined in IDL and converted to the local programming language. The third application interface component is the dynamic invocation interface (DII), which provides direct access to the request-response mechanism of the ORB, including an IDL stub but with full awareness of the format of the objects.

Similarly, at the server, there are three components that provide access to the implementation repository. The ORB interface supplies the same level of standard abstract interaction on the server that it does on the client. The other two components interact with the ORB through the object adaptor described earlier. The IDL skeleton fulfills the same role on the server that the IDL stub does on the client: It provides a mapping between the standard object formats and the local formats stored in the implementation repository. The dynamic skeleton interface (DSI) provides direct access to the request-response mechanism of the ORB, including an IDL skeleton, but with full awareness of the format of the objects.

Figure previous also shows how the ORB communicates with other client or server ORBs. The ORBs talk to each other using the General Inter-ORB Protocol (GIOP) that defines a set of application-level messages and data representations for transactions between ORBs. GIOP may be carried over a variety of transport protocols, but we are interested only in transport over the Internet. For this purpose, COBRA requires that an additional adaptation layer be used to bring the level of function of TCP/IP up to the requirements of GIOP and to make visible the IP addresses of the nodes on which objects reside. The combination of GIOP and this adaptation layer is known as the Internet Inter-ORB Protocol (IIOP). GIOP and IIOP are described further in the next section.