Standards & Protocols
CORBA —
Interoperability
In the telecom world, it is particularly important to use products that conform to interoperability standards, especially when trying to design multiplatform systems.
By Mike Rodbell
One of CORBA’s selling points is that, as a standard, it can be used to develop applications that span multiple vendors’ applications. In that spirit, the CORBA specification includes considerable discussion on the topic of interoperability. The primary goal of the
interoperability specifications is to establish a set of object request broker (ORB) interfaces that can be used to tie multiple products together into a set of integrated applications.
The interoperability portions of the specification are most important to the folks developing the CORBA products, and not the specific application. If you’re in the business of developing applications based on CORBA, you’re most likely to be concerned that folks sell you products that conform to the
interoperability standards. In the telecom world, this can be particularly important if you are trying to build multiplatform systems or are developing against standards that other equipment vendors are also working against. Some real-world scenarios can include the following:
- You’re developing a combination of communication products and management systems. It’s not unusual to be developing communication network element (NE) products in a more traditional embedded computing
environment, while the management systems are most frequently built in the world of larger scale, virtual machine-based environments running OSes such as Windows NT or Unix. In some cases, you can go to a single vendor for both the embedded and non-embedded pieces. However, it’s not unusual to find cases in which two different ORB products need to be integrated.
- You manufacture networking equipment, and your customers have either developed or purchased management software from some other
organization. They are expecting you to provide a management interface not unlike other standards for your equipment. Thus, it’s important that the toolkit you select supports the interoperability standards. The ORB supported by your equipment must have a seamless level of integration to coexist in the general information domain accessed by the management system. Alternatively, you could be developing the operational support system (OSS) requiring access to products based on different ORB components.
It is important to carefully distinguish between standards compliance and the ability to provide applications that work with a third-party vendor’s software. In some areas, CORBA solutions have taken hold, but there are always challenges to managing interfaces between products from different vendors.
Going beyond interoperability between ORB-based products, several implementations of gateway services exist which allow you to develop applications that span the worlds of both CORBA and the
distributed component object model (DCOM) services provided by Microsoft’s product line. There are several products available that can support the CORBA/DCOM interworking.
The general areas covered by the CORBA v. 2.2 interoperability standards include:
-
Inter-ORB bridge support.
This discusses and identifies the various approaches that can be taken to map and share information, type, security, and object reference domains. These are generalized approaches to bridging information
and object services across multiple ORBs, and the example of CORBA/DCOM bridging is included in this functional area.
-
General Inter-ORB Protocol (GIOP).
This specifies a “standard transfer syntax, and set of message formats for communications between ORBs.” This is a flexible, application-layer protocol intended to be run over user-specified transport services. It is for ORB-to-ORB communication services
- Internet IOP (IIOP).
IIOP provides the specifics of how
to use the GIOP to transfer information over TCP/IP networks. If you think in terms of protocol layers, the IIOP services run beneath the GIOP on the protocol stacks, to transfer application information.
- Environment-specific IOPs (ESIOPs).
ESIOPs are interoperability solutions geared toward environments that are not well supported by the GIOP family of bridging services. An example of an ESIOP that is included in the CORBA v. 2 specification is the set of services that can be used to
map between CORBA and distributed computing environment (DCE) applications. With a DCE based on an interface definition language (IDL) and a remote procedure call (RPC) architecture loosely similar to CORBA, mappings can be provided between the two environments.
As you can see from this assortment of interfaces, the CORBA interoperability strategy is based on providing a rich set of options in distributing information through an application enterprise. Of these interface options, only IIOP
(along with GIOP) is standardized as a complete protocol. The remaining options are proposals and solutions, which only provide a framework.
GIOP — least common denominator
The GIOP is developed and specified by the Object Management Group (OMG) to provide a standard, simple technique to allow products from different CORBA ORB vendors to interoperate. It’s goals (as specified within the CORBA v. 2 specification) include:
-
Broad availability.
It should be
easy to support.
-
Simple.
It should be as simple as possible, while meeting the general design goals.
- Scalable.
It must support collections of ORBs that extend to the size of the Internet. This is a rather bold statement, given the virtually limitless scope of the number of machines that can be installed on the Internet.
-
Inexpensive.
The nonrecurring engineering (NRE) investment required to implement the GIOP should be relatively small, and operating
overhead is expected to be minimized.
-
Extensible.
While the only standards-based realization of GIOP is the TCP/IP-based IIOP, the IIOP is designed to operate on top of any connection-oriented data networking protocol.
-
Architectural Neutrality.
The GIOP is designed to be usable on a wide range of system architectures. It’s not designed with a specific system in mind.
In line with these goals, the specifics of how an ORB developer makes use of the GIOP is
left entirely to the product vendor. However, in order to support interoperability, ORB vendors must provide a GIOP/IIOP interface to their product.
The GIOP/IIOP protocols are similar to other information exchange protocols. They contain standard elements including data representations, message sets, and service mappings. The major elements of the specification are:
-
Common data representation (CDR).
As in the case of the basic encoding rules and marshalling standards used in
other information exchange protocols, the CORBA CDR provides a data-presentation syntax that provides an interoperable set of mechanisms to transfer information. For those of you that have experienced some of the standards-based “big endian” versus “little endian” wars, the CDR includes solutions to support variable byte ordering. Data types can be aligned to simplify processing. In recognition of the mission that the CDR is providing, it completely maps all OMG IDL primitive data
types.
-
GIOP message formats.
Aligned to support a set of generic client-server actions, the GIOP message formats provide a message set that, while relatively small, can be used to support all of the CORBA primitive actions.
-
Transport assumptions.
While GIOP has not been specifically designed to require TCP/IP, it does make some base assumptions about the services provided by the transport protocol. It expects to operate over a connection-oriented service that provides
reliable delivery of a data stream (such as how TCP works). As you can see, while this is suspiciously similar to TCP, it does not preclude operation over other similar protocols (for example, the OSI TP4 transport protocol could be used).
-
IIOP message transport.
The IIOP message transport specification identifies how GIOP can operate over TCP/IP. The CORBA v. 2 specification identifies two general IIOP dialects — IIOP v. 1.0 and IIOP v. 1.1. These two versions of the protocol are
coupled to GIOP v. 1.0 and v. 1.1. The wording of the specification requires implementations of v. 1.1 to support communication with peers (clients or servers) running v. 1.0.
With this protocol architecture, CORBA meets its simplicity goals by addressing the needs for object distribution, while not complicating the design with large amounts of extraneous mechanisms and services.
CDR
CDR provides the encoding services used to transfer all of the IDL definable data types
between any machines operating within the CORBA operating space. These data types can range from simple primitives (integers) to user-defined, constructed types such as structures, unions, arrays, and sequences of information. To keep from falling into the data-byte ordering pit, the CDR specification can support either big or little endian data representations on the wire. The specific format to be used is negotiated during the establishment of connections. The specific format is identified in the message
format.
Message formats
The GIOP messages are used by the client and server implementations to control the exchange of information and commands over the CORBA infrastructure. The types of messages supported by GIOP can be seen in Table 1. As you can see from Table 1, the set of messages is particularly small. With the exception of the CloseConnection message, the clients initiate all activities.
IIOP
The IIOP provides services that transport the GIOP messages over
TCP/IP connections. When operating on top of IIOP, servers can publish information-describing objects using IIOP IOR profiles. These IOR profiles include information that points clients to the servers that can support the requested objects. With that information, the client can then establish TCP/IP socket connections and send the corresponding Request and LocateRequest messages to the server over the socket. With TCP providing a reliable, stream-based transport, all that the GIOP layer needs to do is
provide framing services, which it accomplishes through message length fields.
The GIOP/IIOP services can be used within a CORBA product (with the ORB mapping to both the client and server machines), or could alternatively be used solely as a mechanism for the exchange of information between ORBs developed by different vendors. Regardless, if you’re looking to develop CORBA applications for consumption by your customers (who may want to assemble broader enterprise solutions), the interoperability
gains achieved by these protocols merit attention. If you are interested in the specifics of this set of protocols, a good starting point is the CORBA v. 2 standard, which is available from the OMG Web site (www.omg.org).
Mike Rodbell is director of embedded software development for CIENA Communications, Inc. He has developed voice and data communication systems for a wide range of commercial and military systems. He holds a BSCS from Trinity College in Hartford, CT, and and and MSEE from Loyola
College of Baltimore, MD. He can be reached at
mrodbell@ciena.com
or
http://www.ciena.com.
Return to the
Table of Contents
Puzzled by a network processing design issue?