Open Hypermedia Systems Working Group

CORBA

CORBA is certainly mature enough to handle the needs of the Open Hypermedia Protocol. The current needs include the ability to:

• specify a set of related components
• develop and run the components cheaply (e.g. for free) and on multiple platforms.
• exist in an Internet environment (e.g. with associated scale and security issues)

CORBA is currently in its second generation of design and is based on a network protocol which enables interoperability between ORBs of competing vendors. IDL is well designed and includes support for object-oriented concepts, namespace management, and exception handling. IDL is similar to C++ but is, in actuality, language-independent. Most CORBA vendors offer IDL language bindings to C++, Java, and SmallTalk. IDL specifications are the key unit of currency within the CORBA architecture. They are used to generate the glue code for both clients and servers and the information stored in the interface repository. The interface repository supports dynamic discovery and use of remote components.

From this discussion, CORBA can handle the first requirement just fine. In fact, CORBA may be the easiest component framework for the OHS Working Group to adopt given the (interim) decision to specify component interfaces using IDL. If adopted, the existing specifications could be run through an IDL compiler to start the process of developing a reference OHP implementation. If another component technology is selected, the IDL specifications may have to be changed to a different format to ease the transition between specification and implementation. Alternatively, the IDL specifications can remain, regardless of the adopted component technology, and an IDL compiler can be used to verify at least that the specifications are syntactically correct before being released to development groups.

With respect to the second requirement, the availability page makes it clear that most CORBA technology is not cheap. The advent of freely-available CORBA technology, such as offered by OOC, Inc., is a recent phenomenon and an evaluation should be performed of such technology to determine its quality. On the other hand, all CORBA vendors typically support several flavors of Unix and Windows (95/NT). A few even support the Macintosh. So, in general, CORBA technology is available on multiple platforms and, as previously mentioned, supports multiple programming languages.

To address the third requirement, it should be noted that CORBA has been designed to scale up to environments as large as the Internet, however CORBA technology has not yet met this promise in practice. While it is true that most ORBs can connect components distributed across a WAN, performance is often slow especially when transferring large amounts of data. CORBA's Common Object Services are supposed to include support for security, but it is unclear how widespread the support for this service is implemented. Finally, the WWW and its associated standard protocols, came into existence during or after the design of CORBA 2.0 and it does not appear that much thought has occurred in how the two should coexist in the future.

In summary, the OHS WG should consider the following issues when choosing CORBA as the component technology for the OHP. From the perspective of design, CORBA is an extremely strong technology with a flexible and powerful architecture. CORBA should have no problem in specifying the components needed for the OHP. However, in practice, CORBA is held captive by its CORBA vendors. CORBA users must wait until vendors implement CORBA specifications as well as rely on the performance of the supplied tools. All of these things will improve in the future, but OHP must be able to advance and become operational without waiting for that future to be realized. If CORBA is adopted, OOC, Inc. appears to be the obvious choice as a CORBA vendor to support the OHP effort.

Feedback? Send it to Ken Anderson.
Last Modified: 12/11/97; 1:49:58 PM PST