In 1990, the Object Management Group (OMG), then just a few dozen members strong, introduced the world to the idea of distributed objects with its Common Object Request Broker Architecture (CORBA) 1.0 specification. Since then, acceptance of CORBA as a distributed computing standard has grown rapidly, culminating in widespread commercial acceptance of the CORBA 2.0 specification, its Internet Interoperability Protocol (IIOP), and associated services, such as the CORBA Object Transaction Service (OTS), Event Service, and Security Service. In addition, CORBA is now being commercially integrated with other popular object models, such as Java/JavaBeans and Microsoft’s DCOM/MTS, and with various traditional systems services, such as messaging middleware and transaction managers.
OMG membership has now soared to over 800 (and still growing), and new CORBA-based specifications are being adopted and implemented on a regular basis. If the OMG were viewed as a company, and CORBA as its product line, nobody would even question its enormous success or marketplace dominance in its chosen area of distributed object computing. However, since OMG does not itself create or market running software, it is ultimately dependent on getting other firms — CORBA vendors — to adopt its specifications and generate working products that sell successfully to end-users with real-life applications.
Therefore, it is an even more important measure of OMG’s success that, since the first of such vendors seriously entered the commercial marketplace in the mid-1990s, CORBA products have already evolved through at least two generations. Compared to even a couple of years ago, today’s CORBA products have matured significantly from a perspective of performance, reliability, scalability, administration, and ease of use. Moreover, the CORBA vendors – and their marketplace — have grown significantly, and larger companies have begun to enter the market through acquisitions and licensing.
In the rest if this article, we will trace the evolution of CORBA vendors and their products over the last few years, and provide an analysis of current and upcoming offerings. We will also provide a glimpse of what CORBA products are likely to evolve into over the next few years, as new specifications now being developed by the OMG reach commercial maturity. As applicable, well tie all this in with developments in Java, the Internet, Microsoft DCOM/OTS, and other related products and standards.
First Generation CORBA (1990-1996)
In 1989, when the OMG was founded, distributed object computing was only a gleam in the eye of its founding members. The new OMG moved quickly, adopting a formal architecture – the Object Management Architecture (OMA) — and its first specification, CORBA 1.0, in just one year. As a result, OMG was able to build a lot of industry momentum and mindshare for distributed objects. Overnight, CORBA’s common Interface Definition Language (IDL) and the Object Request Broker (ORB) specification gained a significant following, and OMG started to grow. Over the next several years, OMG also developed specifications for a few CORBA services, including a Naming Service, an Event Service and a Transaction Service, all designed to support the management of objects running on a commercial ORB. Specifications were also developed to allow access to IDL-defined interfaces from C, C++, and Smalltalk.
During this time, a number of vendors announced their intention to deliver commercial CORBA products, and a few such products, with limited functionality, actually became available. However, real commercial success for CORBA, in the form of successful products, came only with the adoption of CORBA 2.0 in 1995. CORBA 2.0 settled a number of open questions about how to locate and send requests to an object on another ORBs, how to program to the ORB interface, and how to find and connect to ORB services. In addition, CORBA 2.0 also provided IIOP as a standard protocol for providing interoperability among different ORBs across the emerging Internet. This gained the attention of Internet vendors like Netscape, who became a public supporter of the CORBA 2.0 specifications, and a commercial licensee of CORBA products that are still embedded into their Navigator browser.
By 1996, vendors were able to ship – and sell – reasonably robust first generation commercial products supporting the CORBA 2.0 standard. In addition to implementations of the core specification, a number of vendors successfully delivered implementations of several of the key service specifications. At that time, there were between ten and fifteen vendors attempting to deliver compliant products. Products were available from hardware vendors, software vendors, and even a few operating system companies. These vendors included Iona, Visigenic, ICL, Sun, IBM, HP, Digital and a variety of smaller companies. However, available products varied widely in both their support of the standards, their robustness, their performance, their support of rapid development and their ease of administration.
The Evolution of CORBA (1996-1998)
Since then, a lot of excellent work has been done within the OMG to both refine the existing specifications and to provide basic extensions to them. Critical specifications such as the core specification and the C++ language binding have been steadily improved. A Java language binding has been approved and vendors have been able to deliver compliant products. The OMG has also been hard at work to replace several deficient specifications. For example, the original Basic Object Adapter (BOA) specification, first defined in CORBA 1.0, was seriously under-defined, forcing vendors to provide so many extensions that the BOA became non-portable. In response, the OMG adopted a new object adapter specification, called the Portable Object Adapter (POA), which covers the space much more robustly.
Another example of a successful but under-defined specification is the Event Service. While the Event Service met its original objectives as a standardized channel-based distribution mechanism for object events, it included no event-channel filtering, creating the possibility of an unwanted flood of event notifications across a widely distributed network. Naturally, vendors provided non-standard filtering mechanisms, prompting the OMG to issue an RFP for a complementary Notification Service. This standardization process is almost complete and will shortly result in adoption of a formal extension to the original Event Service.
The OMG has also been busy defining adjunct specifications where needed including the Objects-By-Value (OBV), Firewall and Asynchronous Messaging. The OBV submission specifies changes to IDL allowing the declaration of types of objects that are to be passed along in request by value, instead of only by reference, as originally specified by CORBA 1.0 and 2.0. The Firewall submission proposes several changes to IIOP that will enable ORBs to communicate more effectively across today’s firewall-filled Internet. The Asynchronous Messaging proposal delineates several changes to the CORBA core to support asynchronous requests and to designate quality-of-service (QOS) levels for message transport.
Along with the maturing of the OMG specifications, we have recently seen a major consolidation within the CORBA vendor community. This consolidation has occurred in several different ways. In 1995, most hardware companies were doing signification development on ORB products for resale. This included HP, Digital, Sun, IBM, and ICL. Since that time, Digital has sold their ORB technology (Object Broker) to venture-funded BEA Systems, which is now combining it with another acquisition, the Tuxedo transaction manager. HP has stopped promoting its ORB-Plus. Sun has largely dropped their NEO product, although Java Soft has decided to include the basic CORBA standard as part of the actual Java language. Meanwhile, IBM has refocused from their DSOM version of CORBA in favor of CORBA-based business frameworks like San Francisco.
We have also seen consolidation within the software vendor community. Tiny Post-Modern was acquired by slightly larger Visigenic, which was in turn acquired by the much larger Borland (now Inprise). Iona’s sales continue to rise and the market recently responded with a very successful IPO. At this point in time, the CORBA vendor community consists of fewer but stronger vendors. This is very good for the industry. As this consolidation occurs, we are seeing a maturation of compliant products from these vendors.
Rapidly Maturing CORBA Products
As a result of these developments, we are starting to see some true second generation ORBs, ready for robust mission-critical applications. For example, Iona’s Orbix has been totally reengineered in both C++ and Java to improve performance and scalability . Iona has added or improved basic administration capabilities, firewall support, and other important features. Inprise’s VisiBroker has also gone through several iterations in both Java and C++. It has undergone extensive optimization and provides excellent raw performance. ICL DAIS is now supporting both C++ and Java and even has an implementation of the new Portable Object Adapter.
If we look at the CORBA Services market today we can purchase four or more different CORBA services implemented in a variety of languages and layered on top of different underlying ORBs. We have seen the emergence to graphical administrative interfaces to the Naming Service, the Interface Repository, and CORBA/COM Interworking bridges. Both Inprise and Iona are shipping extended Naming Services implemented in both C++ and Java. The extended Naming Service provides the ability to support a straightforward (although limited) approach to load balancing. The basic extension allows groups of objects to be bound to a single COS::Name in order to implement round-robin load balancing at resolve time. NEC is also delivering a preliminary Notification Service built on top of Orbix.
In addition to purely CORBA-compliant services, Iona, NEC and Inprise have all been able to deliver firewall services. Running IIOP over the Internet presents some interesting issues. Some are defined by application requirements (such as the need to utilize callbacks) and some are defined by security requirements (such as the need to block incoming file-descriptor usage).
The Visibroker IIOP Gateway allows CORBA applets to send GIOP requests over HTTP instead of IIOP. This is very important for firewall configurations, which do not allow IIOP communication. Unfortunately it can not be utilized if HTTP Tunneling is not allowed or if ORB interoperability is required. The NEC solution is based on the publicly available SOCKS package for providing circuit gateways. The circuit gateways is installed into an ORB via a library or class files. The gateway allows multiple IIOP conversations to be multiplexed over a single file descriptor and proxy server. This can allow pure IIOP to be easily funneled through Intranet firewalls. Internet applicability of the SOCKS package still requires minor alterations to IIOP itself.
Iona has attacked the Internet/Firewall problem from many different angles. On the first front, Iona’s Wonderwall supports HTTP tunneling in a very similar way as Inprise’s IIOP Gateway. Unlike Visibroker, WonderWall allows the ORB to support callbacks over the single outgoing file-descriptor instead of requiring an additional inbound file-descriptor. This is important since many sites do not allow inbound file-descriptors to be used directly. WonderWall also provide the ability to multiplex IIOP requests via the use of multiple IIOP profiles. This means that WonderWall can be used to authenticate, log and route IIOP traffic. All of these things are important in Internet solutions. While providing a number of excellent features, WonderWall still suffers from some problems. WonderWall features such as Internet callback support and HTTP tunneling require Orbix or OrbixWeb clients. Another problem is that CORBA objects which are accessed (via a single IOR) from both the Internet and Intranet must all flow through Wonderwall. Unlike the NEC/SOCKs solution, WonderWall does not dynamically configure itself and requires security administration.
We are also beginning to see products supporting the OMG Object Transaction Service (OTS) specification. Hitachi/Inprise and Encina/Iona both have generally available products. These products support C++ servers and Java clients. Another interesting entrant into the OTS market is BEA’s new M3 product. M3 combines and updates a major CORBA ORB – formerly Digital’s ObjectBroker – with a proven transaction manager – formerly AT&T’s Tuxedo. This is intended to provide CORBA developers the reliability, scalability and manageability they could expect from a Tuxedo based system, meanwhile leveraging the open OTS interface. In essence, this product represents a second generation ORB implemented on top of a fifth generation transaction manager.
BEA’s M3 supports critical components of the CORBA 2.0 specification including IDL, C++ binding, IIOP, FactoryFinder, OTS, and Security. M3 has been specifically designed to provide a very high degree of scalability. Objects are almost always stateless and rely upon XA-compliant RDBMS for storage and retrieval of persistent state. M3 provides a specialized subset of POA object activation/deactivation policies. Typically, object servants are automatically deactivated at either method-end or at transaction-end. M3 can then automatically re-activate the object servant the next time an appropriate reference is utilized. Re-activating the object allows for dynamic load balancing based upon Tuxedo’s highly optimized distributed blackboard.
image
Looking at Figure 1, we can see that within a particular client application, we can have multiple client stubs leveraging the same object reference via a smart pointer. We can also have multiple client applications leveraging an object reference based on the same object identifier (host, port, key tuple). With M3’s preferred stateless architecture, multiple servants are activated for a given object reference/identifier. This can occur each time a request come in, or each time a request associated with a new transaction comes it.
image
In an effort to make the development of transaction processing CORBA systems, BEA extends the specification with their own services or APIs. The main service included is known as TPFramework. Its job is to coordinate object de-activation/re-activation with state management and to integrate state management with XA transaction management. TPFramework attempts to minimize the amount of coding required by the developer. Base classes are provided so that the developer does not need to implement mainline code associated with basic server functionality. Servant base classes are also provided to minimize the amount of code required to develop the actual objects themselves. While the C++ code developed for services relies on BEA specific frameworks, the objects developed are defined with IDL and are accessible from any compliant client ORB (Java or C++).
The other main service is known as TPBootstrap. Its entire purpose is to allow non-M3 ORBs to gain easy access to M3 services. For example, an OrbixWeb applet could use the BEA supplied Java implementation of TP::Bootstrap to easily gain access to the M3 IIOP gateway. The gateway ensures that even pure IIOP access obtains the benefits of M3’s Tuxedo-based transport, known as TGIOP, a specialization of the CORBA specification that underlies IIOP. Once the Bootstrap is obtained, resolve_initial_reference calls provide access to the M3 TS::Current object (required to start/stop transactions), the Security Current Object, and the M3 FactoryFinder object. These steps are diagrammed in figure 2. The use of the TPBootstrap eliminates the need utilize string_to_object/object_to_string as well as the need to distribute the ‘stringified’ object through a non-ORB mechanism. The Java code associated with foreign ORB bootstrapping is included below:
//Java code
// Initialize non-M3 ORB
ORB orb = ORB.init();
// Create M3 bootstrap object using URL for IIOP gateway
Tobj_Bootstrap bs = new Tobj_Bootstrap(orb, “//myserver.beasys.com:4000”);
//Resolve M3 Factory Finder
org.omg.CORBA.Object off = bs.resolve_initial_references(“FactoryFinder”);
FactoryFinder ff = FactoryFinderHelper.narrow(off);
//Resolve Security Current
org.omg.CORBA.Object osc =bs.resolve_initial_references(“SecurityCurrent”);
org.omg.SecurityLevel2.Current sc = SecurityCurrentHelper.narrow(off);
//Resolve Transaction Current
org.omg.CORBA.Object otc = bs.resolve_initial_references(“TransactionCurrent”);
org.omg.CosTransactions.Current tc = TransactionCurrentHelper.narrow(otc);
Embedded CORBA
A big step in the maturing of CORBA is the emergence of new development tools that embed CORBA, but do not necessarily expose it. One such category of tools has become known as an “Application Server”, a three-tier development package which implements a pre-defined architecture that can allow Java, C++, or even HTML front end applications to access middle-tier components. The Application Server environment provides out-of-the-box capabilities like load balancing, transactional access to back-tier relational data, distributed access to business logic, etc. Examples of these tools include products from NetDynamics, SilverStream, Progress, Persistence Software, Kiva, Vision Software, WebLogic, and others.
image
While many of these tools have been developed using CORBA, they do not typically expose the components via CORBA bindings. For example, NetDynamics generates C++, Java or HTML front ends, which access middle-tier components. While Visibroker is used internally by NetDynamics, users do not develop their own CORBA applications to access the middle-tier components. Access to components is only through the proprietary layer using common languages. NetDynamics does provide a generic mechanism to interface to arbitrary legacy components implemented outside of the NetDynamics realm. The Platform Adapter Components (PAC SDK) has been designed to ensure that new NetDynamics applications can be deployed on top of existing legacy applications or services. The NetDynamics architecture is shown in figure 3.
Like many of the Application Server tools on the market, NetDynamic provides support for management, load balancing, database integration, and different front-end environments. Support for pure HTML front ends ensures that even the most security-conscious — or Java-leery — Internet user can access corporate services via the Application Server paradigm.
Extending CORBA
Within the last few years, the OMG has expanded its focus beyond providing open access to distributed object interfaces, and into the area of modeling those objects and their interfaces. OMG now includes within its charter the specification of common business objects for a wide variety of domains, including finance, healthcare, telecommunications, and manufacturing, to name a few. However, while CORBA IDL is fine for specifying the interfaces to such business objects, it was never designed to adequately express the complex behavior and relationships needed to define a business object model. Therefore, OMG is now extending the notion of CORBA specifications to include object modeling techniques.
OMG’s first major move in this direction was to standardize on a version of the Unified Modeling Language (UML), originally developed by Rationale as a fusion of the popular Booch, Rumbaugh, and Jacobsen modeling methodologies. In addition, OMG is now also in the process of standardizing on a variant of UML called the Component Definition Language (CDL). CDL is based on an extension to CORBA called Business Object Component Architecture (BOCA), which is specifically designed to support CORBA-based common business objects. Both of these modeling specifications are being designed to work with a new Meta-Object Facility (MOF), which will allow tools and infrastructures to store and retrieve model information through a common interface. Figure 4 – New OMG Specifications
image
Figure 4 describes the relationship between UML, CDL, MOF and the existing CORBA 2.0 and CORBA Service specifications. Analysis and design work is done in UML, and mapped to CDL, where additional information associated with business object configuration and deployment is added. All this information is stored in the MOF, and IDL interfaces are generated. Depending on the tools used, implementations of the business objects may also be directly generated, or the objects may be associated with custom implementations. The business objects are then hosted by a Business Object Facility (BOF) running over CORBA and CORBA services. In addition, the BOF has run-time access to all the design and configuration information stored in the Meta-Object Facility.
CORBA is also moving into different territory with the CORBA Component Model (CCM) specification, currently in the early stages of development. While the precise scope of the CCM area is still being decided, it will focus on the area of a common ‘packaging’ model for CORBA components. This is similar to the notion of a ‘bean’ in Java, where a set of related interfaces and their implementations can be placed in a package that can be distributed across any CORBA environment, including, of course, the Internet. Not surprisingly, the idea of a CCM is being promoted by many of the same vendors who support notion of Enterprise Javabeans (EJB). Therefore, it is likely that the two standards will converge, with CCM a generic model for packaging CORBA components, and EJB a particular version designed for packages that contain Java implementations only.
CORBA and Microsoft’s DCOM
Just as the OMG specifications (and products supporting them) have evolved, we have seen a similar maturation of Microsoft’s software environment. Microsoft’s initial delivery of OLE/COM supported a thriving market of desktop development components. These technologies required that different development tools supported a common set of interfaces. Supporting these interfaces allowed a variety of products and components to interoperate within the Microsoft operating system environment. While this was very effective at the desktop level, the lack of support for distributed components greatly limited the ability to support truly enterprise level solutions.
In an effort to address distributed system requirements within the OLE/COM environment, Microsoft developed DCOM and ActiveX. While these technologies provide some low-level distributed computing capabilities, they do not really address the requirements of large-scale, robust software systems built from distributed software components. More recently, Microsoft has introduced its Transaction Server (MTS), a more rigorous attempt to host such components in a transaction-oriented run-time environment. Details about these components and their deployment are stored in an Active Directory, and are used by MTS to manage them at run-time. MTS has yet to be proven as a truly scalable and portable environment, even across Microsoft platforms. However, it at least begins to seriously address in the Microsoft world some of the key areas covered by CORBA services.
For some time, CORBA specifications – and commercial implementations of these specifications — have existed to cover interoperability between CORBA and COM. These specifications mainly describe how CORBA interfaces can be mapped to COM interfaces, and vice versa. The most typical commercial use of this technology is to allow CORBA objects running on a server to appear as COM objects on a desktop. However, as both the CORBA and COM worlds have grown, it is becoming a priority to extend the standards to cover interoperability among services, such as transaction management and security. Most notably, Microsoft itself announced a partnership with Iona to integrate MTS with CORBA OTS, allowing objects to participate in transactions that span the two kinds of transactions managers. Microsoft has also announced support for the OMG’s UML and MOF specifications, meaning that tools and services in both the CORBA and DCOM environments will be able to (at least in theory) share common design and run-time information about objects.
Future Trends
Considering what has occurred over the last ten years, where can we expect CORBA technology to go in the next three or four years? First of all, we must remember that the challenges of improving or increasing business drive the evolution of information technology, and CORBA is certainly no exception. Corporations will continue to increase in size through massive mergers, and will need to support ever-increasing numbers of products, orders, transactions, and volumes of data. In addition, as the world gets smaller, they will require complex global distribution of information and functionality across heterogeneous platforms and networks, including an increasingly robust Internet.
All this will drive the current generation of CORBA products to become more robust in terms of administration, scalability, and ease of development. We will see CORBA applications deployed to tens of thousands of users, and CORBA frameworks of business objects supporting hundreds of related applications. These systems will be capable of supporting millions of distributed objects involved in thousands of concurrent transactions. The security capabilities of these systems will improve significantly in the next years as well. In essence, these future products will provide the back plane for true enterprise-wide computing based on software components. As these environment mature, development tools for building these interoperable components will become available as well, based on the emerging class of CORBA standards in this area, such as the BOCA, the MOF, and CCM.
The next great challenge for OMG, and the software industry as a whole, will be standardization of the business components in each vertical domain. This is a more daunting task than the standardization of systems services that has largely characterized OMG to date. While end-users are more than happy to accept a standard interface to a request broker or a transaction manager, it will be interesting to see how quickly they can reach agreement on standard interfaces to a Customer, Account, Policy, or other business component that directly represents their business domain. However, until there is agreement on such common business objects, it will not be possible to built truly reusable, interoperable business components.
Fortunately, work has already begun within the OMG to define such common frameworks in a variety of business areas, including finance, insurance, manufacturing, healthcare, and transportation. This work is being driven by a number of far-sighted end-users and ISVs who see business component interoperability across their whole industry as a key to the long-term viability of their individual businesses. This is particularly true for industries with complex supply chains, and/or where mergers and acquisitions are major business drivers. The more these industries standardize on business components, the lower the overall cost of doing business for everyone.
Bibliography
1: page 14 Business Object Component Architecture (BOCA) Proposal OMG Document: bom/98-01-07
2: CORBA Component Model Multiple Interfaces and Composition OMG TC Document orbos/97-12-21
3: Combined Business Object Facility Interoperability Specification OMG Document Number: bom/ 98-01-10
4: “Selecting Java App Servers”, Object Magazine June 1998: Dan Kara
5: Graphics and bootstrap code sample from BEA Iceberg EAP Documentation
6: Graphics from NetDynamics 4.0 Whitepapers