The next release of the CORBA specification will be a major one, CORBA 3.0. The last time the major release number was incremented - to CORBA 2.0 - it signified the standardization of interoperability. What's new and different enough in this version for OMG to increment the major release number this time?
Despite its compact designation, CORBA 3 isn't a single specification - instead, it's the collection of specifications, adopted individually, that will be added to the current CORBA 2.3 to form the CORBA 3.0 release. Although we use "CORBA 3" as shorthand to refer only to the new parts, the official designation CORBA 3.0 refers, formally, to the entire CORBA specification book. With the posting of final submissions for the CORBA Component Model (CCM), Scripting and the Persistent State Service (PSS) on the OMG Web site in early August, all parts of CORBA 3 are finally available. Votes on these last few parts will be underway when you read this, and are expected to be completed by the end of 1999; check OMG's Web site for the latest word.
There are about 10 new specifications in CORBA 3, and I'll touch on all of them here. Java programmers will be particularly interested in the reverse Java-to-IDL mapping and the CCM's embracing of Enterprise JavaBeans (EJBs), so I'll put some extra detail into these sections.
I'll give you the URL for every specification we discuss here. Documents under consideration for all of OMG's works in progress are available to members and nonmembers alike at www.omg.org/schedule. Find the process or future specification you're interested in and click on it. This will bring up a new page with URLs for all related documents. For specifications, go to www.omg.org and look down the left-hand side of the page for "The OMA"; all specifications are available under that heading. You can download any of these OMG documents, specifications, or works in progress without charge.
Introduction to CORBA 3
The specifications included in the designation CORBA 3 divide neatly into three major categories that we'll cover in the following order:
Java and Internet Integration
- Java and Internet integration
- Quality of service control
- CORBA component architecture
The three specifications discussed below enhance CORBA integration with Java and the Internet.
CORBA 3 adds a Java-to-IDL mapping to the "normal" IDL-to-Java mapping you're familiar with if you've done any Java/CORBA programming. To use it, you start out by writing RMI objects in what the specification refers to as the "RMI/IDL subset of Java." It's a pretty full subset; restrictions affect things such as multipath inheritance of overloaded methods, name case collisions, and private types in interfaces. (Java allows private types in distributed interfaces. CORBA can't seem to figure out why anyone would want to keep a distributed variable private.) Objects must extend java.rmi.Remote, and exceptions must inherit from java.lang.Exception. Obviously, CORBA objects passable by value play a large role in the CORBA-side implementation of this specification.
Once you've written the objects, two things happen: first, by compiling through rmic with the proper options set, your objects generate CORBA stubs and use IIOP instead of RMI protocol. Second, the RMI compiler will output the IDL for your object into a file that you can then compile in any programming language, on any ORB, allowing you (or your friends) to write CORBA clients in any language, on any IIOP-speaking ORB, that can invoke your Java object.
This does a number of things. It turns Java object programmers into CORBA object programmers, and lets Java objects play in CORBA's multilanguage environment. (Unfortunately, it doesn't do anything for Java client programmers!) According to the first draft of EJB 1.1, it's a future requirement for Enterprise JavaBeans interoperability and will ensure that EJBs can play in this multilanguage environment as well.
It's not a round-trip mapping, quite intentionally. Since out and inout parameters don't occur in Java, the reverse mapping has no element that corresponds to the Holder classes in the IDL-to-Java mapping, and some IDL types will never occur in the IDL output from rmic. In some ways, though, the mapping is pretty clever: variables that appear only in Java set-and-get operations will be mapped to an IDL Attribute.
This specification is available from the Web at www.omg.org/corba/clchpter.html#jilm.
The CORBA 3 firewall specification defines transport-level firewalls, application-level firewalls and (perhaps most interesting) a bidirectional 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's called back in a reverse-direction invocation. Because standard CORBA connections carry invocations only one way, a callback typically requires a second TCP connection for this traffic heading in the other direction - 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: www.omg.org/cgi-bin/doc?orbos/98-05-04 and an erratum, www.omg.org/cgi-bin/doc?orbos/98-07-04.
Interoperable Naming Service
The CORBA object reference is a cornerstone of the architecture. Because the computer-readable IOR was (until this service) 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 even for that?
The interoperable naming 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 www.omg.org/cgi-bin/doc?orbos/98-10-11.
Quality of Service Control
Asynchronous Messaging and Quality of Service Control
The new messaging specification defines a number of asynchronous and time-independent invocation modes for CORBA, and allows both static and dynamic invocations to use every mode. Results of asynchronous invocations may be retrieved by polling or callback - the choice is made by the form used by the client in the original invocation.
Policies allow control of quality of service of invocations. Clients and objects may control ordering (by time, priority or deadline); set priority, deadlines and time-to-live; set start and end times for time-sensitive invocations; and control routing policy and network routing hop count.
The specification also defines CORBA routers and store-and-forward agents for IIOP invocations. Routers with the highest defined quality of service will pass invocations with a transaction-like handshake and store invocations persistently, providing messaging-like network transmission. The routing specification defines IDL interfaces to the marshaling engine, an interesting piece of work in itself.
The URL for the messaging specification is www.omg.org/cgi-bin/doc?orbos/98-05-05.
Minimum, Fault-Tolerant and Real-Time CORBA
Minimum CORBA is intended primarily 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 DII or the IR that supports it, which is why these features are not included in minimum CORBA. The URL for the minimum CORBA specification is 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 www.omg.org/cgi bin/doc?orbos/99-02-12; an erratum is 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 www.omg.org/techprocess/meetings/schedule/Fault_Tolerance_RFP.html.
Corba Components Package
CORBA Objects Passable by Value
Termed valuetypes, objects passable by value add a new dimension to the CORBA architecture that previously supported passing (and invocation) only by reference. Like conventional CORBA objects, these entities have state and methods; unlike CORBA objects, they don't (typically) have object references and are invoked in-process as programming language objects. It's only when they're included in parameter lists of CORBA invocations that they show their talent by packaging up their state in the sending context, sending it over the wire to the receiving context, creating a running instance of the object there and populating it with the transmitted state. Frequently used to represent nodes in binary trees or cyclically linked lists, valuetypes have been specified and implemented to faithfully represent these important constructs. This specification gives CORBA the capability of the Java serializable, and is used extensively in both the reverse mapping and component model. The valuetype specification may be downloaded from URLs www.omg.org/cgi-bin/doc?formal/99-07-09 and www.omg.org/cgi-bin/doc?formal/99-07-10. Many aspects of valuetypes show only in the language mappings; for these go to www.omg.org/library/clangindx.html.
CORBA Components and CORBA Scripting
The CCM takes the key services you use most regularly - persistence, transactions, security and notification - combines them with the POA's servant-handling capability, and wraps all these tools in higher-level interfaces corresponding to the patterns that experienced programmers use to code enterprise and Internet server applications.
This means that:
- CCM applications are very compact. They use little code, and the little that's required is devoted almost totally to business programming.
- Infrastructure functions - storing data, activating and deactivating servants - are done automatically and coded automatically as well.
- CCM implementations will be built around an industrial-strength infrastructure written by specialists and tuned for optimum performance in stressed environments, including the enterprise and Internet. When this infrastructure runs your CCM application in its tuned environment, you automatically get the benefits - high throughput, great performance, robustness - even though you don't have to write any infrastructure code, or even code to POA and CORBA services interfaces.
The four major parts of the CCM are:
Component model functions are packaged and presented to programmers at a higher level of abstraction than are the bare CORBA services. Component interfaces are declared using newly standardized additions to OMG IDL. Components declare their persistent state using Persistent State Definition Language (PSDL, a superset of OMG IDL), defined in the new PSS (a new CORBA service not presented here). Programmers then use Component Implementation Definition Language (CIDL, an extension of PSDL) to declare some of the component's behavior; CCM products use these declarations to generate code for parts of the implementation. Finally, an XML-based configuration language ties components together in assemblies and configures them for individual installations. Because these new languages work at higher levels of abstraction than CORBA and the CORBA services, business programmers can write enterprise- and Internet-level applications with less help (perhaps no help!) from infrastructure experts. In addition, some of the languages were designed to be generated by visual tools.
- A model that presents common functionality - transactions, security, event handling, persistence - to the programmer at a high level using declarative languages and, optionally, visual tool
- A container environment that packages (at the basic conformance level) transactions and security, adding (at the extended conformance level) persistence and event handling
- A software distribution format that enables a CORBA component software marketplace
- Integration with Enterprise JavaBeans
One objective of CCM is to allow you to write distributed applications that mix CORBA components running in CORBA component servers with EJBs running in EJB-technology-based servers. This allows programmers to create an application by reusing existing components of either kind. To accommodate EJBs the CCM defines two levels of containers and conformance: the basic level container is transactional and secure, and provides simple persistence; its definition corresponds, almost feature for feature, to EJB 1.1. To this the extended-level container adds container-managed (and -implemented) persistence for multiple segments, event handling, multiple interfaces and navigation. The specification covers all of the various ways that CORBA clients can interact with EJBs and how Java clients can interact with CORBA components. We'll go over details of these CCM/EJB interactions in a future column. Since every container presents its services to components through the same set of standardized interfaces, component applications are portable from any vendor's container to another's. A basic-level container packages up subsets of the CORBA Transaction Service, CORBA security, and simple persistence in a new set of interfaces. At level 2 the container adds more of the PSS and a subset of notification service. It's not necessary for a container implementation to furnish its own persistence service; the specification assumes that CCM products will use any standard PSS and that your site administrator will buy and install one. Of course, vendors are free to package PSS and CCM together if they want. Level 1 containers must include Transaction and Security support, however, and level 2 containers have to add their own event handling capability.
Extended CORBA components support multiple interfaces. The CCM defines interfaces, provided by the container, that allow a component-aware client application to navigate among them. To component-unaware clients - including all clients written in a CORBA 2 environment - each interface appears to be an individual CORBA object; these clients can't take advantage of the implementation's component nature but can invoke it as a normal CORBA object without any trouble.
To help build a market in components, the CCM defines a software distribution format with several notable features. The distribution format contains executables for all of the platforms a vendor wants to support, in a type of zip file. Installer code, built into the container, extracts and installs the proper executable for the platform it's going to run on. Following installation, component executables can be configured. This overcomes another resistance point - that it's rare to find two installations that need exactly the same piece of functionality. By building and selling flexible modules to wider markets, vendors can attain the volumes they need and the component market will build to critical mass.
Configuration files contain information on events emitted and consumed by components, at least at the extended level. Containers construct channels for the events and transmit them at runtime. Since CCM applications typically consist of several component types, the container will also have to connect up an invocation by one type to an interface on another; this also is specified in the configuration file and install-time configuration process. By the way, configuration files use XML format.
There's also a scripting language specification that will map various scripting languages to the CCM. This will add another way to assemble components into applications, in addition to the XML-based assembly tools described in the CCM. We'll devote a column to this sometime in the future too.
The CCM and scripting specifications hadn't completed their final votes when this column was written, but may be a done deal by the time you read it. Check out www.omg.org/techprocess/meetings/schedule/CORBA_Component_Model_RFP.html and www.omg.org/techprocess/meetings/schedule/CORBA_Scripting_Language_RFP.html for details, and to download your own copy of the 700-page CCM document.
CORBA does as much as it can to support every programming language and platform. Because Java's object model aligns closely with CORBA's, and Java's Virtual Machine is platform-portable, CORBA is able to do more with it than with other languages, and this shows in the specifications we've reviewed in this month's column. We think this bodes well for productivity and popularity on both the CORBA and Java sides of the aisle, and I may muse more about it in a future column.
Jon Siegel, Object
Management Group's director of technology transfer, presents tutorials, seminars and company briefings around the world. The author of CORBA 3 Fundamentals and Programming, he has extensive experience in distributed computing, object-oriented software development and
geophysical computing. Jon holds a Ph.D. in
chemistry from Boston University.
He can be reached at: [email protected]