What's Coming in CORBA 3

siegel@omg.org

The umbrella term CORBA 3 actually refers to a suite of specifications which, taken together, add a new dimension of capability and ease-of-use to CORBA. Most of the specifications in the suite are available now; the last few will be available in draft form around the beginning of August and will start their final adoption votes at the OMG meeting in San Jose, California, on August 27, 1999. Under a new OMG procedure, these specifications will start out classified as "pre-production", and transform to "available" (that is, an official OMG specification representing the current CORBA specification) only after they have finished a round of maintenance revision and the first products become available. Even though this won't happen until mid to late 2000, you can read most of the specifications now or very soon and know whats coming; the revisions can only change technical details and not affect the structure of any part of the new release. In this article, we'll list all of the parts of CORBA 3 and tell a little about each one. For details, check the individual specs on OMG's website. We'll give the URL for each one in its section.

INTRODUCTION TO CORBA 3

• Internet Integration;
• Quality of Service Control; and
• The CORBAcomponent architecture

1: INTERNET INTEGRATION

Firewall Specification
The CORBA 3 Firewall Specification defines transport-level firewalls, application-level firewalls, and (perhaps most interesting) a bi-directional GIOP connection useful for callbacks and event notifications.

Transport-level firewalls work at the TCP level. By defining (courtesy of IANA) well-known ports 683 for IIOP and 684 for IIOP over SSL, the specification allows administrators to configure firewalls to cope with CORBA traffic over the IIOP protocol. There is also a specification for CORBA over SOCKS.

In CORBA, objects frequently need to call back or notify the client that invoked them; for this, the objects act as clients and the client-side module instantiates an object that is called back in a reverse-direction invocation. Because standard CORBA connections carry invocations only one way, a callback typically requires the establishing of a second TCP connection for this traffic heading in the other direction, which is a no-no to virtually every firewall in existence. Under the new specification, an IIOP connection is allowed to carry invocations in the reverse direction under certain restrictive conditions that don't compromise the security at either end of the connection. The Firewall Specification comprises two documents: http://www.omg.org/cgi-bin/doc?orbos/98-05-04 and an erratum, http://www.omg.org/cgi-bin/doc?orbos/98-07-04.

Interoperable Name Service
The CORBA object reference is a cornerstone of the architecture. Because the computer-readable IOR was (until recently) the only way to reach an instance and invoke it, there was no way to reach a remote instance - even if you knew its location and that it was up and running - unless you could get access to its object reference. The easiest way to do that was to get a reference to its Naming Service, but what if you didn't have a reference for even that?

The Interoperable Name Service defines one URL-format object reference, iioploc, that can be typed into a program to reach defined services at a remote location, including the Naming Service. A second URL format, iiopname, actually invokes the remote Naming Service using the name that the user appends to the URL, and retrieves the IOR of the named object.

For example, an iioploc identifier

iioploc://www.omg.org/NameService

would resolve to the CORBA Naming Service running on the machine whose IP address corresponded to the domain name www.omg.org (if we had a Name Server running here at OMG). The URL for the Interoperable Naming Service Specification is http://www.omg.org/cgi-bin/doc?orbos/98-10-11.

2: QUALITY OF SERVICE CONTROL

Minimum, Fault-Tolerant, and Real-Time CORBA
Minimum CORBA is primarily intended for embedded systems. Embedded systems, once they are finalized and burned into chips for production, are fixed, and their interactions with the outside network are predictable - they have no need for the dynamic aspects of CORBA, such as the Dynamic Invocation Interface or the Interface Repository that supports it, which are therefore not included in Minimum CORBA. The URL for the Minimum CORBA specification is http://www.omg.org/cgi-bin/doc?orbos/98-08-04.

Real-time CORBA standardizes resource control - threads, protocols, connections, and so on - using priority models to achieve predictable behavior for both hard and statistical realtime environments. Dynamic scheduling, not a part of the current specification, is being added via a separate RFP. The URL for the Real-Time CORBA specification is http://www.omg.org/cgi-bin/doc?orbos/99-02-12. ; an erratum is http://www.omg.org/cgi-bin/doc?orbos/99-03-29.

Fault-tolerance for CORBA is being addressed by an RFP, also in process, for a standard based on entity redundancy, and fault management control. The URL for all information on this RFP is http://www.omg.org/techprocess/meetings/schedule/Fault_Tolerance_RFP.html.

3: CORBACOMPONENTS PACKAGE

• A container environment that packages transactionality, security, and persistence, and provides interface and event resolution;
• Integration with Enterprise JavaBeans; and
• A software distribution format that enables a CORBAcomponent software marketplace.

The CORBAcomponents container environment is persistent, transactional, and secure. For the programmer, these functions are pre-packaged and provided at a higher level of abstraction than the CORBAservices provide. This leverages the skills of business programmers who are not necessarily skilled at building transactional or secure applications, who can now use their talents to produce business applications that acquire these necessary attributes automatically.

Containers keep track of event types emitted and consumed by components, and provide event channels to carry events. The containers also keep track of interfaces provided and required by the components they contain, and connect one to another where they fit. CORBAcomponents support multiple interfaces, and the architecture supports navigation among them.

Enterprise JavaBeans (EJBs) will act as CORBAcomponents, and can be installed in a CORBAcomponents container. Unlike EBJs, of course, CORBAcomponents can be written in multiple languages and support multiple interfaces.

The specification defines a multi-platform software distribution format, including an installer and XML-based configuration tool, and a separate Scripting specification will map CORBA and component assembly to a number of established scripting languages.

The CORBA Component Model is not yet complete, but you can download a snapshot of this specification-in-progress from http://www.omg.org/techprocess/meetings/schedule/CORBA_Component_Model_RFP.html, and the scripting work from http://www.omg.org/techprocess/meetings/schedule/CORBA_Scripting_Language_RFP.html.

IN CONCLUSION…

Additional Links: