B. P. Blackshaw
Enterprise Distributed Technologies Pty Ltd
Abstract. At EDOC’97, I presented a paper entitled "Building distributed enterprise OLTP applications: current CORBA limitations", which examined the suitability of CORBA for building enterprise level distributed systems. A number of areas of concern were discussed, and the paper concluded that at the time of writing, mid-1997, CORBA was not sufficiently mature for the job. However optimism was expressed that within 2-3 years many of the issues raised would have been dealt with by vendors and the OMG. This paper investigates the accuracy of that prediction. It re-visits the issues raised in 1997 and looks at what has changed. It also discusses how the continued Internet revolution and the emergence of Java have changed the distributed landscape, and how well CORBA has adapted to these challenges.
This paper revisits a number of key limitations of the Common Object Request Broker Architecture (CORBA) identified in 1997 [1], and examines how the situation has changed some two years later. The author has been working with CORBA for a number of years - initially with Mincom, an Australian software company, and more recently in the investment banking industry in London, UK. The paper has been written from the pragmatic point of view of a CORBA developer. Its purpose is to outline the current situation faced by developers wishing to build distributed systems using a CORBA infrastructure.
It has now been 10 years since the formation of the Object Management Group (OMG). Its Object Management Architecture (OMA) and Common Object Request Broker Architecture (CORBA) specification [2] have had ample time to mature, as have vendor implementations of these specifications. What can developers and system architects seeking to build distributed applications expect from the OMG and vendors who have implemented the CORBA standard?
In 1997, [1] claimed that not all the pieces of the distributed puzzle were fully in place. Certain critical areas such as persistence and portability were inadequately addressed. Other issues such as transactions did have an OMG specification, but vendors had not yet provided robust implementations. While distributed systems certainly could be built using commercial Object Request Brokers (ORBs), a considerable amount of infrastructure needed to be developed.
The following sections discuss the current situation for each issue identified in 1997.
[1] criticised the OMG for its failure to integrate the OMA with Database Management Systems (DBMSs). Persistence is a vital feature of almost all enterprise systems, and the Persistent Object Service (POS) 1.0 was not a success.
Unfortunately, little has changed for the application developer in the past two years. The second attempt at a specification, POS 2.0, was dropped, and a Request For Proposal (RFP) was issued for the Persistent State Service (PSS) 2.0 [3] during 1997. The latest joint revised submission is [4], submitted in April, 1999. The revised submission deadline is August 2, 1999.
The joint revised submission looks promising. It enables developers to define their own "storage objects" and "tables" in the Persistent State Service Definition Language (PSSDL). Storage objects are stored in tables, which themselves are stored in datastores, which could be object or relational databases or even files. PSSDL is a superset of IDL, and has language mappings to Java and C++. PSS implementations will generate the appropriate code for their supported datastores. The relationship with the Object Transaction Service is specified, and the PSS satisfies the forthcoming CORBA Components specification requirements.
However even though the PSS submission looks promising, the current situation remains problematic for developers. A persistence layer must be developed or a proprietary vendor solution purchased for systems with persistent requirements. It is hoped that a specification will be rapidly approved and that vendor implementations will be available before 2000. The PSS is a conspicuous omission from the recently announced CORBA 3.0 release, discussed in subsequent sections.
Support for transactions has always been essential in most enterprise systems, and has traditionally been provided for in the DBMS. Most database vendors support the X/Open Distributed Transaction Processing (DTP) model. To bring distributed (and non-distributed) transactions to objects, the OMG developed the Object Transaction Service (OTS), specified in 1994. In 1997 implementations were only just beginning to appear.
Two years later, a number of implementations of the OTS are available. Almost all popular ORBs offer an OTS, including Orbix and Visibroker. BEA Systems’ M3 (now part of BEA WebLogic Enterprise), an enterprise ORB offering an integrated Transaction Processing Monitor (TPM), is a notable product where the TPM has been closely tied to the ORB.
An important recent development has been Sun Microsystems’ Java Transaction Service (JTS). The impact of Java on CORBA is discussed subsequently in this paper, but it is a significant endorsement of the OTS that the JTS implements the Java mapping of the OTS 1.1.
These are encouraging developments for CORBA and also vital to its survival, as the Microsoft Transaction Server (MTS) product is becoming popular and is well integrated into Microsoft’s competing COM/DCOM technology. Microsoft is also working to deliver its next generation COM architecture, COM+, with Windows 2000. In COM+, MTS and COM will be completely integrated into the NT operating system. Enterprise Java Beans (EJB) is also gaining momentum.
The equivalent section in [1] was called "Application Partitioning", but in fact it discussed the problem of design techniques for distributed systems. It stated that what was needed was "guidelines that help us determine how a large application is modelled in terms of components", specifically referring to distributed systems.
Distributed systems development is becoming ubiquitous, and yet the author is not aware of comprehensive design guidelines that specifically help to address its many complexities. Issues such as distributed transactions and concurrency control, performance, distributed naming, reliability, deadlock, load balancing, fault tolerance and security all influence design, but there is no coherent approach that assists in taking all these issues into consideration. Instead, many lessons in distributed design are learnt through hard-won experience.
A related issue is that of design with components. Component technology is becoming popular but there are few guidelines available on how to design a distributed system using components.
One promising area is design patterns. The patterns community has had a significant impact on object-oriented design and development, and distributed design patterns are becoming available. For example, [5] is a popular text. Hopefully, a comprehensive catalogue of proven distributed design patterns will become available, which would be of great assistance to architects of distributed systems. The OMG could be usefully involved by providing a central catalogue for such patterns and introducing a review process.
Workflow support is an important part of many enterprise systems. This was recognised by the OMG, and many of the influential Workflow Management Coalition (WfMC) members were involved in submissions for the OMG’s Workflow Management Facility (WMF) RFP [6], intended to address the integration of workflow and CORBA.
It was suggested in [1] that WMF specification would be adopted during 1998. The final standard was accepted in November, 1998.
Subsequently, a degree of CORBA support is slowly beginning to appear in workflow products, such as Concentus Technology’s MetaExpress product [7]. However relatively few workflow products as yet claim CORBA support, including the commercial offerings of the contributors to the WMF specification. It would appear that the WMF has not yet been widely embraced by the vendor community. A search of the WfMC web site [8] yielded no references to the WMF. Since the adoption of the WMF is relatively recent, perhaps implementations will appear during 1999.
For large distributed systems supporting hundreds, possibly thousands of users, scalability and performance are critical. While the CORBA specification is relatively neutral in these areas, in 1997 no ORBs existed that could provide enterprise level scalability. Virtually all ORB implementations used direct TCP connections between clients and servers, resulting in an exponential increase in connections when client numbers increased.
Fortunately, this is a long-recognised problem that TPMs were designed to solve. TPMs multiplex client connections as well as providing server-side load balancing capabilities, and are well suited to enterprise CORBA systems. BEA Systems’ M3 product is an example of a TPM married to an ORB. Rather than establishing direct connections to server objects, clients connect to instances of an Internet Inter-Orb Protocol (IIOP) gateway [9]. Servers are also connected to the gateways, which route requests to the appropriate server. This dramatically reduces the number of connections in the system, significantly increasing scalability. M3 also supports sophisticated state management via the Portable Object Adapter (POA), which gives better control over server memory resources.
Other ORBs are also offering ORB/TPM combinations, although few are as tightly integrated as M3. Looking towards 2000, it appears as though the scalability problem is largely behind us. Of course, scalability will always be dependent on good design, but the appropriate building blocks are now available.
[1] stated that "there is a significant lack of tools available for designing and developing enterprise distributed applications."
Two years, further on, little seems to have changed in the CORBA arena. The success of Java seems to have had an impact in this area, diverting effort into Java development tools. Many tools vendors have been simply re-developing their C++ environments to cope with Java.
In the meantime, Microsoft has made some headway towards seamless distributed development with DCOM and MTS. Its Developer Studio environment is constantly evolving.
Hopefully, the rise of Enterprise Java Beans (EJB) will address this imbalance. EJB has much in common with CORBA, and the two standards are moving closer together (see section 3). Vendors are beginning to offer development tools that focus on EJB development, and in time it is hoped that these tools will support CORBA.
[1] noted that while many ORBs were cross-platform, portability of code between different vendor ORBs was quite difficult to achieve.
A degree of independence from ORB vendors is important to many developers. Few vendors supply source code, and in a market that is still consolidating, portability across ORBs is a desirable precaution. The POA specification was adopted in mid-1997 primarily to solve the portability problems associated with the original Basic Object Adapter (BOA). The POA is well specified and is extremely flexible, permitting the application of a variety of server policies.
In 1997, no POA implementations existed. Unfortunately, although the POA has become part of the current CORBA specification [2], few vendors currently support the POA. For example, neither Orbix (Iona Technologies) nor Visibroker (Inprise), among the most popular ORBs, support the POA in their current releases. BEA Systems’ M3 does support the POA, but wraps it within their proprietary TP Framework. M3 developers thus do not have direct access to the POA. Interfaces, somewhat defeating the aim of portability. PeerLogic’s DAIS supports the POA, as do a number of public domain ORBs such as TAO and MICO. Sun’s JavaIDL currently does not support the POA.
It is hoped that all major ORB vendors will have implemented POA support during 1999. However vendors may choose to wrap POA support into releases that support the entire CORBA 3.0 specification due during 1999, and this may delay releases.
It is always difficult to administer software deployed across a number of machines, particularly if they embrace a variety of hardware and software platforms – often the case for a CORBA deployment. In 1997, [1] claimed that "few tools are available for the administration and tuning" of large distributed systems.
There are a number of general-purpose enterprise network management systems available, most of which rely on the Simple Network Management Protocol (SNMP) or Common Management Information Protocol (CMIP). These systems are relatively mature, sophisticated, and in widespread use. Management of CORBA processes is a logical extension.
The Open Group, together with the Network Management Forum (NMF), have sponsored the Joint Inter-domain Management (JIDM) working group. The JIDM’s goal is to "provide tools that would enable interworking between management systems based on different technologies" [10]. The key technologies identified are CMIP, SNMP and CORBA. The first deliverable, produced in 1997, is a Specification Translation. This document describes the mechanisms for translating between the three technologies’ definition languages. A forthcoming document, "Interaction Translation", will address issues of dynamic, run-time translation.
In late 1997, the OMG issued the CORBA/TMN (Telecommunications Management Network) Interworking RFP [11]. This RFP recognised the work done by the JIDM, and sought proposals that were compatible with the JIDM reference model. The joint final submission [12] was made in late 1998, and was adopted in January 1999.
A number of CORBA/SNMP and CORBA/CMIP gateway products are already available, mostly based on the JIDM specification.
Implementations of the CORBA/TMN proposals have yet to make their way into leading ORBs such as Orbix and Visibroker. However both Iona and Inprise contributed to submissions, and are on the CORBA/TMN voting list, as is BEA Systems. Currently, most management tools are relatively simple Graphical User Interfaces (GUIs) that provide only basic control of CORBA servers, although BEA’s Tuxedo management tools are integrated with M3. Hopefully, CORBA/TMN support will gradually be implemented in these products.
The computing landscape has changed dramatically over the last two years. In 1997, CORBA was competing with DCOM, which was still embryonic, and there were no other obvious competitors on the horizon. In 1999, DCOM is more mature and the Internet is ubiquitous. The Java language and platform has gained broad acceptance. The substantial impact on CORBA of each of these technologies is discussed in subsequent sections.
The rise and rise of the Internet has continued over the last two years. A significant proportion of the world’s population is now on-line, particularly in the United States and Europe. For example, the Nielsen/NetRatings service estimated in March 1999 that 36% of the US population had access to the Internet [13]. A flow-on effect has occurred with software development – companies recognise the importance of e-commerce, and this is driving many development projects.
One very positive effect of the Internet on CORBA is that the world is now thinking distributed systems. Web applications, by their very nature, support many users spread around the world. While most Web applications may not strictly be distributed applications according to the academic definition, they are forcing designers and developers to consider concurrency, performance and scalability issues.
Another positive influence is the steady adoption of browser based technology for the GUI portion of applications. For many users, the client operating system is of decreasing significance, and Web developers try to ensure their applications work with multiple browsers. On the server-side, Unix is an extremely popular Web server platform, and the most popular Web server, Apache, is primarily found on Unix. These factors have played a significant role in reducing the dependency developers and to a lesser extent users have on Microsoft Windows, and indeed any operating system.
The popularity of operating systems other than Windows has also helped promote one of CORBA’s strengths – its cross-platform and cross-language support.
Netscape Communications provided another boost to CORBA by bundling the Visibroker ORB client libraries with Netscape Navigator. While this move does not appear to be particularly successful, it has certainly raised the profile of CORBA among Web developers.
1998 was the year of the Open Source movement. Although Open Source has been around for many years in the form of the GNU project, and has had many successful projects such as gcc, emacs and Apache, during 1998 and 1999, Linux pervaded the IT press headlines. The measure of Linux’s success is the way that major vendors are rushing to port their applications to the platform – Sybase and Oracle are some notable database products.
This has all been helpful for CORBA. Besides the slow but continual erosion of Windows dominance, a number of free ORBs have been made available, generally with full source code [14]. In particular, the popular GNOME Linux desktop uses ORBit, a free ORB, as its distributed framework. This has meant anyone can build their own CORBA applications on almost any platform for little or no cost. Developers are also able to examine ORB source code. In contrast, DCOM source code has not been released by Microsoft, and complete implementations are not readily available on platforms other than Windows.
Over the last two years, Java has evolved from a Web applet programming language to an enterprise development platform. Virtually all platforms support Java, and there has been a rush of Java development tools. The OMG rapidly adopted an IDL to Java mapping, and most major ORB vendors now support Java.
Java is significant for CORBA in a number of ways. C++ is currently the most popular language for writing CORBA applications. Unfortunately, CORBA development using C++ is very complex, particularly in regard to memory management issues. By contrast, Java’s automatic garbage collection frees developers from the management of client-side proxies and the necessity of allocating memory in the server for out parameters and return values. Java programmers are generally familiar with exceptions, as they are an integral part of the Java environment, and consequently application development with Java and CORBA is not a huge leap for Java programmers. As a result, Java is gaining in popularity for CORBA development.
Many Java programmers are also familiar with Java’s Remote Method Invocation (RMI), which has much in common with CORBA. Recently, Sun enhanced RMI to run over CORBA’s IIOP protocol, meaning RMI clients can now communicate with CORBA servers (written in any supported language) with no changes in client source code.
Java 2.0 has brought perhaps the most significant push for CORBA – JavaIDL. JavaIDL is almost a complete CORBA implementation, and is a standard Java 2.0 library. Although it is perhaps not sufficient for deployment in a production environment, JavaIDL has brought CORBA to every Java programmer. Of course, Java programmers do not automatically become CORBA developers, but JavaIDL should gradually increase the numbers of developers familiar with the technology.
Enterprise Java Beans (EJB) is Sun’s integrated server-side component framework. A specification that can be implemented by any vendor, EJB allows developers to focus on building business logic rather than infrastructure. Middleware services such as persistence and transactions are handled by EJB containers and servers, which will normally be supplied by vendors.
Although few EJB applications exist at the time of writing, application server vendors are rushing to offer EJB support, and it is clear that EJB has broad industry support.
How will EJB impact on CORBA? Sun has made some effort to support interoperability between EJB and CORBA, even publishing a mapping specification [15]. The OMG has been working on a language-neutral component model, the CORBA Components specification [16] for some time. Considerable effort has been made to ensure that this specification is compatible with EJB. CORBA component servers and EJB servers will be able to manage both CORBA components and EJBs. It is clear from the recent OMG press release [17] that the OMG is committed to CORBA/EJB interoperability. Revised submissions were due August 2, 1999.
ORB vendors are also committing to EJB technology. For example, BEA Systems acquired the EJB Tengah server in 1998, now rebranded as WebLogic. As mentioned earlier, their M3 ORB has recently been merged with WebLogic, the combination being called WebLogic Enterprise. Early in 1999, Iona Technologies acquired EJBHome, another EJB implementation.
It seems that with such close interoperability between EJB and CORBA, EJB will be a useful ally that will help broaden CORBA’s appeal. (and vice versa). The only caveat is that the OMG must be careful to continue to maintain a language neutral position, part of the reason for CORBA’s broad appeal.
There is little doubt that Microsoft’s DCOM and MTS technologies compete directly with CORBA. When Windows 2000 and COM+ arrive during late 1999 or early 2000, Microsoft will have an impressive offering consisting of an ORB, a TP monitor and message queue tightly integrated into the operating system.
Comparisons are difficult to make, as both technologies are complicated and few people have a neutral position. Also, implementations are evolving quickly.
Perhaps the most significant distinction is that of cross-platform support. DCOM is available only on Windows NT, rendering it unsuitable for cross-platform environments. Microsoft’s attempts to port DCOM to other platforms such as Solaris and VMS do not appear to have been successful. Of course, Microsoft’s strategy of making NT ubiquitous may make this argument obsolete. However the combination of the Internet, Java, and the open source movement, (particularly Linux), seems to be ensuring this does not happen.
A number of positive changes have happened to CORBA in the last two years. There have been significant changes in some of the areas criticized by [1] in 1997. However there is still progress to be made, particularly in providing a simple way to implement persistence – an area vital to most systems.
The IT industry has changed dramatically during this time, with the rise of the Internet and Java both being particularly significant. This paper has argued that these technologies have been and will continue to be beneficial influences on the rate of CORBA adoption in industry. With the rising popularity of component-based distributed development, the combination of CORBA and EJB may well become the primary basis for the development of distributed systems.
Microsoft has not been idle during this time, and has been working to improve its DCOM/MTS offering. COM+ may well prove to be a formidable competitor when it finally arrives as part of Windows 2000.
However CORBA is now a relatively mature, widely supported architecture. Robust implementations are now offered by dozens of vendors. Its adoption rate appears to be increasing, and the author believes that CORBA is well positioned to be the distributed framework of the new millenium.
[1] Blackshaw, B.P. & Ellwood, J.R., "Building distributed enterprise OLTP applications: current CORBA limitations", EDOC’97, Gold Coast, Australia.
[2] Object Management Group, The Common Object Request Broker: Architecture and Specification, Edition 2.2. February 1998.
[3] Object Management Group, Persistent State Service, Version 2.0 Request For Proposal. OMG document orbos/97-06-07.
[4] Object Management Group, Persistent State Service 2.0 Joint Revised Submission. OMG document orbos/99-04-01.
[5] Mowbray, T.J. & Malveau, R.C. CORBA Design Patterns. Wiley, 1997
[6] Object Management Group, Workflow Management Facility Request For Proposal. OMG document cf/97-05-06
[7] Concentus Technologies, Internet address. http://www.concentus-tech.com
[8] Workflow Management Coalition, Internet address. http://www.aiim.org/wfmc
[9] E. Cobb, "Making component-based systems scale with BEA M3". BEA Systems, May 1998.
[10] The Open Group, Inter-domain Management: Specification Translation. Preliminary specification, document P509.
[11] Object Management Group, CORBA/TMN Interworking RFP. OMG document telecom/97-09-04
[12] Object Management Group, CORBA/TMN Interworking RFP Final Submission. OMG document telecom/98-08-[13/14/15]
[13] Nielsen Media Research, Press release, March 22, 1999. http://www.nielsenmedia.com/newsreleases/releases/1999/netratings2.html
[14]. T. Valesky, The Free CORBA page. http://adams.patriot.net/~tvalesky/freecorba.html
[15] Sun Microsystems, Enterprise JavaBeans to CORBA Mapping.
[16] Object Management Group, CORBA Components Final Submission. OMG document orbos/99-02-05
[17] Object Management Group, The OMG Outlines Application Server Standard. OMG press release, April 6 1999.