In-Depth
The CORBA State of the union
For more than a decade, industry has developed a wide variety of implementations of the Common Object Request Broker Architecture (CORBA) specification -- products and projects supporting interoperability ranging from enterprise-level transaction applications to small-footprint, performance-critical controllers. Java 2 programmers who use that language’s distributed computing capabilities are using CORBA, whether they realize it or not. CORBA implementations provide support for markets as diverse as finance, telecommunications, manufacturing and life sciences research, and are a key underpinning of many military systems both within and outside the U.S.
CORBA continues to serve as middleware that provides an open, vendor-neutral solution for developing systems for distributed computing environments, from networks that span the enterprise to groups of single board computers (SBCs). This article provides a “health report” on where CORBA is today -- and where it will be tomorrow.
First, some background
For readers who are new to CORBA or even for the “old hands” who would not mind a little refresher, let us first review CORBA’s history. In October 1991, the OMG released the Common Object Request Broker: Architecture and Specifications, Version 1.0, which included the CORBA Object Model; the Interface Definition Language (IDL) specification; the core set of APIs for dynamic request management and invocation (DII) and Interface Repository (IR); and a single language mapping for the C programming language. Since then, two major revisions and eight minor revisions, issued approximately one a year, have added interfaces for the Basic Object Adapter (BOA) [since replaced by the Portable Object Adapter (POA)]; memory management; an Interoperability Protocol specification; specs for a suite of Object Services; additional language mappings (C++, Ada, COBOL, Lisp, PL/1, Python, Smalltalk, Java and XML); security features; and support for deploying CORBA in real-time, fault tolerant and embedded systems. The latest release, CORBA 3.0, issued in September 2002, moved the chapters relating to real-time and minimum CORBA into their own volume and designated them as Specialized CORBA Specifications. The remaining set of specs, including Fault Tolerant Services, was renamed the CORBA Core Specifications. CORBA 3.0 also introduced the CORBA Component Model (CCM); defined a specification for firewall traversal; and enhanced CORBA’s integration with the Java language and the Internet, building on the existing language mapping for Java to CORBA IDL.
The state of the CORBA union
We begin our “State of the Union” update with a tour of CORBA and CORBA related specs at www.omg.org/technology/documents/spec_catalog.htm. Follow the trails leading from any of the CORBA, CORBA-related or IDL-language mapping specifications, and you will be presented with a wealth of technology specs that are all available to the public. Note that some specifications are undergoing a vote to recommend adoption, while others have been adopted during the past year. The following is a sampling of the specifications that relate specifically to CORBA and its services, or that provide a specialized CORBA service and are being implemented in today’s systems or incorporated into the design of systems that will come out during the next five to 10 years:
* Data distribution service for real-time systems provides for the predictable distribution of data in real-time apps and is based on the data-centric publish/subscribe model. This spec was recommended for adoption in March 2003 and is in finalization, which means that early adopters of the specification can still influence its final form by reporting any bugs or issues to www.omg.org/technology/issuesform.htm. (This holds true for all specifications in the finalization phase, as long as the issues are received before the issues deadline.)
* Lightweight logging service provides an efficient, central facility inside an embedded or real-time environment to accept and manage logging records. Note that although this specification was initially targeted at Software Defined Radios (SDRs), it is also applicable to embedded systems (such as machine control or onboard vehicle systems); ubiquitous computing devices (pocket computer and electronic organizers); and any system requiring a small, memory-only logging facility. This spec was recommended for adoption in June 2003 and finalization is just beginning.
* Deployment and configuration of component-based distributed applications is a CORBA-related specification that provides middleware mechanisms, methods and notations for automated deployment and configuration support for component-based distributed applications. Like the Lightweight Logging Service, it was initially targeted at SDRs, but extends beyond that. This specification was recommended for adoption in June 2003 and has also entered finalization.
* GIOP tunneling over Bluetooth specifies how messages are transmitted over Bluetooth technology in a Wireless CORBA network. Finalization for this specification is scheduled to be completed in November 2003; the deadline for submitting issues was in August 2003.
* WSDL/SOAP–CORBA interworking, two companion specifications that are both in finalization, specify translation rules and interaction translation mechanisms to enable Web Services Description Language (WSDL)-defined Web-based services, with ports bound to HTTP/ SOAP, to access CORBA clients. One offers a WSDL-to-IDL mapping for implementing a Web service in terms of CORBA, while the other provides a valid set of IDL constructs to WSDL.
* Notification/Java Message Service interworking specifies an architecture and the interfaces for managing CORBA Notification Service interworking with the Java Message Service. The interworking involves several aspects, such as Event-Message mapping, QoS mapping, and Event and Message filtering. This specification is in finalization.
* Online upgrades provides a facility for upgrading objects on-the-fly, which is particularly important for critical apps that must operate 24x7 and whose operations cannot be suspended to perform upgrades. This spec completed finalization in June 2003 and is poised to become a formal OMG specification in September.
As you examine these specifications, remember that they were the first to be produced since the OMG introduced the concept of the Model Driven Architecture (MDA) two years ago. Because of this, they were required to include a Platform Independent Model (PIM) and a Platform-Specific Model (PSM) for the CORBA middleware technology. Also keep in mind that the key word in PIM is “Independent,” so this part of the specification, expressed in UML, is platform-neutral. In contrast, the PSM is typically, but does not necessarily have to be, a CORBA-specific platform model -- it could just as well be a Java PSM and it would still be perfectly acceptable.
Where can CORBA be found today?
The answer is fairly simple -- in pretty much any distributed system that needs interoperability and portability across diverse operating platforms -- and even in places where you might not expect to find it. The problem is that in many systems, it is buried so far inside and its presence is so well hidden, it is difficult to know that it is even there. It just is. Let us look at a few specific cases.
Telecommunications: In telecommunications, CORBA is used as a standard for network management platforms providing services such as billing. This means that network management platforms around the world deploy CORBA. It is estimated that at present there are more than a million such platforms deployed in the industry. Based on previous technology experience, network management technology normally has a life cycle of about 10 years. However, due to current economic conditions and expected upgrades, it is anticipated that CORBA will extend this life cycle by an additional five years, resulting in a total of more than 15 million network management deployments.
Examples of other CORBA deployments include providing real-time broadband access to the Internet, e-mail, firewall-protected corporate intranets, and audio and video entertainment on trans-Atlantic flights. CORBA is also behind the next-generation Mobile Data Infrastructure system for the Mexican State of Nuevo Leon Police and District Attorney departments.
Finance: In finance, CORBA has recently been deployed in a trade workflow and execution system that completely automates the trade order-management process, from trade generation through allocation for buy-side traders and portfolio managers worldwide. This deployment effectively leverages the Financial Information Exchange (FIX) standards to quickly and efficiently communicate with external liquidity sources such as brokers, exchanges and automated trading systems.
Traffic management: In preparation for the 2008 Olympic Games, the Beijing Traffic Management Bureau has selected a CORBA-based implementation to develop an advanced traffic management system that will ensure the smooth running of the enormous transport operation during the games.
U.S. military applications: This is an area that is somewhat difficult to report on because of public disclosure rules. But all U.S. military systems being developed today are required to use commercial and open standards, such as CORBA, to the greatest extent possible. The document that guides which standards must be used to provide critical services within these systems (with allowances for the use of emerging standards) is the Joint Technical Architecture (JTA). The JTA is a living document and keeps up with the latest standards -- quite an achievement considering that the document is produced and coordinated across a vast military bureaucracy. The JTA specifies CORBA as the standard to be used to develop and provide distributed computing services. Two military uses of CORBA are well-known because of their active participation in the OMG. These are the Navy’s Open Computing Environment (OCE) and the Joint Tactical Radio System (JTRS) programs. While other specific military uses of CORBA are not easy to cite, CORBA’s use, both in commercial and open-source implementations, is widespread in the military services.
Standards activities
The OMG has a number of Task Forces (TFs) and Special Interest Groups (SIGs), from both the Domain and Platform arenas, that focus on different aspects of the object-oriented IT “universe”: UML, IDL, XML and MDA. The following highlights just a few of the groups whose stated mission is to work on CORBA and its related services. These groups work in close coordination with each other, working jointly on specifications as appropriate. Such collaboration ensures that the specs produced have been given, and survived, a technically complete review.
Middleware and Related Services (MARS) Platform Task Force (PTF): The OMG’s MARS PTF is focused on request broker technology such as CORBA; MDA pervasive services fundamental to developing distributed applications; mappings for these pervasive services to specific middleware platforms, and from generic PIM constructs to platform-specific constructs and protocol rules; and supporting technologies for application integration, information integration and collaboration. For those wondering what happened to the ORB/OS PTF -- the task force that was known as the “keeper” of the CORBA ORB -- a little more than two years ago, it was re-chartered as MARS to reflect the maturity of CORBA and to position itself to accommodate the technologies anticipated to support a mature CORBA and the needs of the MDA.
In the coming year, MARS expects to review and, barring any unforeseen complications, recommend a number of specifications for adoption: Extensible Transport Framework for Real-time CORBA, Quality of Service (QoS) for CORBA Components, Streams for CORBA Components, a Security Service protocol, UML Profile for CORBA Components and Web Services for Enterprise Collaboration (WSEC). During the past year, MARS began interacting more with the RTESS Fault Tolerant Working Group (WG). As a result, they plan to prepare a white paper, followed by a Request for Information (RFI), that will focus on how to use configuration management to achieve fault tolerance in large-scale networks. Of course, MARS/RTESS collaboration will not be limited to just fault tolerance -- a quick examination of the submissions in the review queue will quickly dispel that misperception -- but this is one that is expected to bear fruit in the immediate future. MARS and the Telecoms DTF have started to organize and plan for a Focus Day on Middleware, tentatively scheduled for the February 2004 meeting in Anaheim, Calif. What influence this Middleware Focus Day will have on MARS’ future plans remains to be seen.
Real Time, Embedded and Specialized Systems (RTESS) PTF: The mission of the RTESS PTF is to adapt and extend OMG technologies that apply across domains for real-time, embedded and related specialized kinds of systems. Systems that come under the RTESS have one or more of the following characteristics: real-time, embedded, fault tolerant, highly available, high-performance and safety-critical. Thus, the RTESS works to extend specs for CORBA, Common Object Services (COS), UML Profiles, Platform-Independent Models (PIMs) and other standards that satisfy the needs of these systems.
In some cases, the RTESS develops new standards for specialized systems where no current baseline specifications exist. The real-time and embedded systems group has been active in the OMG since 1995 and was elevated from a Special Interest Group to a Task Force in April 2002.
As needed, the RTESS collaborates with other TFs and SIGs. For example, the Data Distribution Service for Real-Time Systems specification was the culmination of a coordinated RTESS/MARS effort and was then issued from MARS. Similarly, the Lightweight Logging Service was the product of a coordinated effort of the RTESS, SWR DSIG and the Telecoms DTF (and was then issued by RTESS).
During the past year, RTESS had a number of submissions that experienced multiple revisions, but they are expected to reach adoption in the next year: Lightweight CCM and Lightweight Services, both suitable for Software Radios and similar embedded systems; Reliable Ordered Multicast Services; Real-time Notification Services; a UML Profile for Modeling QoS and Fault Tolerance; and, if some sticky issues can be resolved, mechanisms for mapping Real-time CORBA to Real-time Java (two mechanisms: one for Sun’s real-time extensions to the Java language and one for the J-Consortium’s real-time extensions to the Java language).
As a follow-on to a series of focus days held over the past year and a half, the RTESS will prepare RFPs targeted at safety-critical systems, starting with an RFP for a High-Assurance ORB. Furthermore, it is expected that the Embedded Systems Focus Day during the September 2003 Technical Committee (TC) meeting will crystallize ideas regarding how to tackle updating the existing Minimum CORBA specification and how to define an Embedded CORBA. Many other efforts are also in the works.
Telecommunications Domain Task Force (DTF): The mission of the Telecommunications DTF, called “Telecoms” for short, is to develop MDA- and CORBA-based technology relevant to the telecommunications industry; to communicate requirements from the telecommunications industry to the OMG as appropriate; to assist and advise the OMG regarding its relationship with telecommunications-related standards organizations and consortia; and to promote the use of OMG technologies as solutions to the needs of the telecommunications industry.
To date, specifications produced by Telecoms have focused primarily on CORBA-based network management solutions. With the advent of the OMG’s MDA, future Telecoms activity will be expanded to include the analysis and design of, as well as the implementation of, CORBA and other middleware-based implementations for New-Generation Operating Systems and Software (NGOSS), mobile infrastructure and network management systems where the CCM will play a significant part. To that end, Telecoms is or will be working with MARS on at least three submissions regarding CCM: UML Profile for CCM, Streams for CCM and QoS for CCM. Further into the future, Telecoms intends to develop a UML profile and a Notification Service for Web services and a UML profile for embedded systems (jointly with RTESS).
Software Radio Domain SIG (SWR DSIG): The mission of the SWR DSIG is to communicate the requirements of the software radio community to the OMG and to promote the use of OMG technologies within that community. Since it is a DSIG, OMG policy dictates that it cannot issue or vote to recommend OMG technologies. Instead, it works very closely with the Telecoms DTF, RTESS PTF, and the Analysis and Design Platform Task Force (the TF that works on UML) as appropriate to develop technologies and services needed by the SDR community. Note that this group has a strong relationship with the U.S. military’s Joint Tactical Radio System program and the Software Communications Architecture (SCA).
Future activities of the SWR DSIG will include a specification for a PIM and CORBA PSM of radio infrastructure facilities that can be utilized to support developing waveforms, and to promote and ensure the portability of these diverse waveforms across SDRs.
Despite the proliferation of middleware technologies, CORBA continues to play a dominant role in distributed computing and will live on in systems both commercial and military for the next 10 to 15 years. But let us not forget that CORBA is not simply a request broker, it is also an architecture with services, mappings and a component model that relate to and support it. The assertion that CORBA is complex and expensive, with the implied message that these constitute an insurmountable barrier to its use, is totally without merit. Designing and deploying a distributed system that is geographically and materially (in the hardware and OS sense) dispersed is, by its very nature, a complex undertaking. It is not realistic to expect that technology, such as CORBA, that is particularly suited to work under these conditions will be simple or inexpensive: It will be complex and it will not be cheap.
Nevertheless, the complexity of deploying a CORBA solution can be greatly simplified by the development of design standards and technology, such as MDA and CCM, that abstracts some (but not all) of CORBA’s complexity away from the software developer. (Unfortunately, there is no mitigation for the cost.)
In closing, let us return to our tour of the CORBA specifications that we started earlier in this article. If time allowed us to expand our tour to include all the other OMG specifications, we’d find that these specifications do exactly that.
[The author’s affiliation with The Mitre Corp. is provided for identification purposes only, and is not intended to convey or imply Mitre’s concurrence with, or support for, the positions, opinions or viewpoints expressed by the author.]
Rebecca Bergersen of Iona, Michel Ruffin of Alcatel, Dock Allen and Kevin Richardson of The Mitre Corp., and Virginie Watine of Thales Group also contributed to this article.