Bruce P. Blackshaw

John R. Ellwood

On-line Transaction Processing (OLTP) applications have special requirements in the areas of scalability and performance. Mincom currently markets a successful product, MIMS (Mincom Information Management System), which is a large, integrated OLTP system consisting of about 16 000 KLOC, mostly COBOL. Our research group is developing prototypes in preparation for migrating MIMS into a distributed architecture. CORBA is our current research focus. This paper will examine the limitations of CORBA for current use in enterprise OLTP development. Major concerns include: lack of a standardised persistence interface for use with major database vendors; immaturity of the Object Transaction Service and Concurrency Service; lack of integrated workflow solutions; scalability and robustness; lack of performance monitoring tools; and poor enterprise development environments. We are optimistic that vendors and the OMG will eventually solve these problems, but feel that it may be a few years before workable commercial solutions are in place.

1. Introduction

This paper describes what Mincom has learnt about the suitability and maturity of the Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA) for building enterprise-scale distributed applications. Mincom’s experience is based on prototypes built over the last two years, which have attempted to explore CORBA's capabilities and to increase Mincom's familiarity with the technology. In particular, a number of limitations of CORBA that currently exist for building enterprise distributed applications are discussed.

Mincom is a medium-sized software company based in Brisbane, Australia. A major part of its revenue is derived from MIMS, the Mincom Information Management System. MIMS is an integrated set of software modules that allows precise monitoring, control and management of a wide range of organisational and commercial activities, particularly for large capital-intensive organisations. MIMS supports areas such as financials, human resource management, materials, and maintenance. It has a large amount (16 000 KLOC) of COBOL which requires an increasing amount of effort to maintain and enhance as MIMS continues to evolve.

MIMS is a large OLTP system utilising a classical 3-tier client/server architecture. The tiers consist of a presentation layer, an applications layer and a database access layer. Proprietary middleware connects the presentation layer with the applications layer.

The presentation layer provides a Graphical User Interface (GUI) to the MIMS user. The Microsoft Windows environment is the target platform for customers. Originally, MIMS supported 24 x 80 terminal screens, but over the last few years Mincom has developed GUI products for this layer.

The applications layer of MIMS provides all the business rules for the system. The application code is written in COBOL, supplemented by a proprietary macro language. An important requirement of this layer has been cross-platform support. The current target platforms for MIMS include Unix, Open VMS, MVS, and Windows NT. In the past, a number of other platforms have been supported, such as Prime, AOS/VS, AS/400 and Unisys 2200, all of which have been discontinued.

The database access layer of MIMS is implemented via a comprehensive macro library. All database transactions use these macros to hide database-specific functionality. Oracle, Informix, Rdb, Sybase and DB2 are all supported.

The other important component of MIMS is the Transaction Processing Monitor (TP monitor). The major purpose of a TP monitor in enterprise systems is to allow resource sharing and thus improve performance. It does this by multiplexing users over a single connection. The sharing of application servers increases performance. The TP scheduler manages user requests, queuing them for the use of an application server. Only a limited number of application servers can be active at any given time.

The TP monitor is also in charge of transaction management. It manages all client-side transactions, ensuring the integrity of data should a transaction be left incomplete for some reason, such as a network failure.

Clients utilise the services of the TP via proprietary middleware, which uses a client/server protocol designed for optimal transmission of MIMS data.

Mincom’s MIMS Technology Research (MTR) group has a charter to develop what is called the MTR "Next Generation Architecture" (NGA) for MIMS. The goal of the NGA is to detail the architectural directions MIMS should be taking over the next three to five years. The resulting system must be able to meet the needs of our customers well into the 21st century.

The key requirements identified so far include the following:

• distributed and deployable — across continents;
• scalability — to thousands of clients;
• support for workflow;
• cross-platform — operating systems, middleware and databases;
• Internet support;
• openness and interoperability.

The NGA is currently under development. Some of the key concepts are being tested via a series of prototype applications.

Over the past 18 months, two main prototypes have been developed by MTR. The first, known as Genesis, has served primarily to obtain some practical experience in building a small distributed system. The server side implementation was developed using Sunsoft's NEO CORBA environment on the Solaris platform, and ported to Iona's Orbix on both Solaris and Windows NT platforms. The user interface was written in Java, using Iona's OrbixWeb product. Persistence was implemented using both flat files and Persistence Inc.'s object-to-relational mapping product, providing access to an Oracle 7.3 database.

The second prototype, known as EGEN (Enhanced Genesis) is under development at the time of writing. EGEN is modelling a small subsection of MIMS functionality and is designed to implement possible solutions to a number of perceived problems with the technology. These problems include scalability, performance, persistence, transactions, workflow and legacy integration.

Other small prototype applications using Visigenic's Visibroker for Java CORBA implementation have also been developed by MTR.

In computing terms, CORBA has been around for quite a while; about 8 years. For a consortium, the OMG has produced a remarkable number of specifications during that time, and has had considerable success convincing vendors to adopt these specifications. However building enterprise applications is not a simple task, and the authors believe that CORBA is not yet ready to form the architectural basis for an enterprise distributed system. The following limitations are the major points of concern for Mincom.

The way in which data is stored and accessed in enterprise systems has a major influence on system architecture and performance. Currently, most systems use relational databases, which are highly optimised and perform well. Object databases occupy niche markets, but the authors do not expect them to make significant inroads into enterprise systems over the next few years. Instead, relational databases (or extensions) will need to interoperate with CORBA.

The OMG has so far failed to properly integrate the ORB and DBMS technologies. Even the CORBA 1.2 specification recognised that the Basic Object Adapter (BOA) would not be up to the task of handling all types of objects and does allow for other adapters to be specified. A Library Object Adapter and an Object Database Adapter are mentioned in the specification as "might be useful". However, no further adapters have been specified to date.

If the Persistent Object Service (POS) was supposed to provide the answers, it has spectacularly failed. It does not seem to be useful to the object server implementer for providing transparent persistence of fine-grained objects whose persistent state is managed by a DBMS. That POS Version 1 somehow missed the mark has been recognised by the OMG, who have now issued an RFP for POS Version 2.

The BOA is fairly loosely specified, as is demonstrated by the very different implementations from various ORB vendors. Last year, MTR looked at the attempts by Persistence Inc. to integrate their object-relational mapping product with the Orbix ORB from Iona and the NEO ORB from SunSoft. NEO's interpretation of the BOA specification uses a BOA database to store the Reference Data associated with each ORB-object (as per the BOA specification); the object reference points to the BOA database entry. This scheme is unworkable for fine-grained objects. To support persistence, they had to use a NEO-specific feature, the subobject, which enables a subobject-id to be slipped into the object reference. In Orbix, the Reference Data has been interpreted as the object marker and is stored directly in the object reference. Thus, in Orbix, it is possible to handle fine-grained objects by using their database id as the object marker.

The joint submission to the Enhanced Portability RFP[2] by most of the major ORB vendors recommends replacing the BOA specification with a Portable Object Adapter (POA) specification. The POA is more tightly specified than the BOA, and provides a more flexible way of handling object implementations. It incorporates the Orbix-specific features MTR were using to implement persistence using a DBMS: the Loader is now an InstanceManager and the object marker is now an ObjectId. It also incorporates the NEO-specific subobject used to implement persistence, by enabling a servant (object implementation) to handle the requests for more than one object — the subobject-id is now the ObjectId.

The authors are hopeful that the Enhanced Portability proposals will provide what is required for the integration of ORB and DMBS technologies, as well as enable us to write servers that are portable across multiple ORBs and DBMSs.

The use of transactions to provide system integrity and to enable concurrent access to shared data is essential to enterprise systems. Support for transactions is provided by most DBMSs, some of which also support the XA interface that allows distributed transactions, usually under the control of a TP monitor.

Precisely how this technology will evolve into the world of distributed objects is not yet clear. The OMG's Object Transaction Service (OTS) and the Concurrency Control Service (CCS) have been specified for some time but it was only at the beginning of 1997 that implementations became available. MTR have started to use the Orbix/Encina OTS/CCS beta in our EGEN but it is too early yet to report on either their suitability or performance characteristics.

A more general point is worth making. Just as, in a traditional system, the DBMS mediates access to shared data for multiple users, the object server must mediate access to shared objects amongst multiple clients. There are basically two ways to achieve this:

• provide the concurrency and transaction control directly in the object server,

• provide isolation between the persistent state of objects in the server being accessed (especially modified) by multiple clients and let the DBMS, the storer of the persistent state, sort out the concurrent access.

The first way is logically more sound and potentially more efficient, as it can properly share unmodified objects. But it effectively duplicates much of the concurrency and transaction control already found in the DBMS. Perhaps in the long term these functions will move to the object server and the persistent store can become much simpler.

The second way is more appealing at the moment, as it requires less work to implement, but it does leave some issues open regarding global concurrency control. Also, it may not scale well if unmodified objects are not shared between concurrent transactions.

Such issues do not seem to be addressed currently. Only as the OTS and CCS start to be used in earnest, and are shown to be able to perform adequately, will such concerns be put to rest.

The role of the TP monitor in a distributed object system will also need to evolve. There is still a requirement for a Distributed Transaction Manager, as provided for in the OTS, and an even greater need for the monitoring and control of servers (object instead of application). The Gartner Group's prediction of TP monitors’ evolution into an Object Transaction Monitor (OTM) seems probable.

Building an enterprise system is a difficult and risky proposition. The risk and difficulty increase markedly if requirements dictate that the system be distributed. Because of CORBA's immaturity, particularly with respect to stable, CORBA 2 compliant vendor implementations, very few large systems have been built with this technology. Consequently, few guidelines exist as to how these systems should be constructed.

The current version of MIMS is a monolithic application, consisting of thousands of COBOL programs which access a large database in a less than ideal non-modular manner. To some extent this approach can still be workable, as long as it is not a distributed application. Once a large application is distributed over a number of machines, application partitioning becomes vital.

Part of the answer to the application partitioning problem seems to be to develop in terms of software components. Unfortunately, component technology appears to promise much, but is poorly understood. The very concept of what is a component has not achieved consensus within the software engineering community. How should a distributed enterprise application be developed in terms of components, ensuring performance, interoperability and other important properties? As far as the authors are aware, no implementations exist that prove the viability of this approach, making it a very risky proposition. What is needed for large-scale development are modelling guidelines that help us determine how a large application is modelled in terms of components. Current standards such as the Unified Modelling Language (UML) focus more on the object-oriented class level rather than the system level.

CORBA’s current level of granularity for components is the CORBA server — an executable that supports a number of Interface Definition Language (IDL) interfaces. In current prototyping, partitioning choices have been made quite early in the development cycle. It is clear that the later partitioning decisions are made, the better, given that the location of components in a distributed environment can have a considerable impact on performance. Ideally, partitioning should be left to the deployment stage as a configuration option. As far as the authors are aware this is not currently possible in popular CORBA implementations, but it is a very desirable goal.

Support for workflow is increasingly becoming an important requirement in enterprise systems such as MIMS (at least for winning contracts!). The most influential organisation involved with workflow is the Workflow Management Coalition (WfMC), a consortium of over 100 members whose aim is to establish standards for workflow software.

The OMG has issued a Workflow Management Facility RFP to begin addressing the integration of workflow with CORBA. Revised submissions are due in December 1997, and specifications should be adopted in early 1998. At the time of writing three submissions had been received.

In the absence of an OMG specification, it is unclear how workflow can be smoothly integrated into a CORBA architecture, and how much impact workflow will have on design decisions. The current WfMC standard has a number of characteristics that could make it unsuitable for a distributed, heterogenous environment [7]. For example, the standard defines a monolithic, centralised workflow server — the antithesis of a distributed system.

It is crucial that vendor implementations be made available as soon as possible after publication of the adopted specifications. For this to occur, the OMG specifications must have the strong support of the WfMC. It is encouraging that many WfMC members are on the OMG voting list, and that a joint proposal from major workflow vendors (as well as other proposals) has already been submitted.

In an OLTP environment, scalability and performance are critical. Users expect rapid response times, and it is not acceptable for these to increase significantly when more people are using the system. In particular, our requirements generally are sub-second response times and scalability up to thousands of users. To complicate matters, many clients have quite low-speed links between users and application servers.

A number of optimisations have been introduced to meet these requirements in the current version of MIMS. Our proprietary middleware is designed to minimise both the number of network messages and the amount of data being transmitted. For example, multiple client/server requests can be bundled into a single network message.

The authors’ concerns with CORBA scalability and performance can be divided into two main areas.

The first is with general ORB performance. Gokhale and Schmidt [3],[4],[5] have shown that the overheads of data copying, marshalling and demarshalling method parameters are significant compared with low level implementations using C/C++. Our proprietary communication protocols in the existing version of MIMS are optimised as much as possible for our requirements — the overhead of a more generic system such as CORBA is significant when response times are important. In particular, CORBA does not have an efficient way of passing large amounts of binary data, which is an important requirement for interfacing with our current MIMS implementation. A sequence of octets provides this functionality, but a pointer to the internal memory block holding the data cannot be used in a compliant manner to memcopy the data elsewhere. Instead, the inefficient sequence interface must be used, or proprietary vendor extensions which affect portability.

Our second concern is with the OMG vision of writing distributed applications transparently — where applications programmers treat local and remote objects as equivalent. We do not believe this is realistic, and believe programmers should be aware of issues such as network delays and the overheads of different techniques. An example is using get() and set() methods on object attributes: these calls are relatively expensive. Waldo et al. [6] point out some of the consequences of this transparency. We prefer not to use public attributes at all, but rather to use more generic retrieve methods that can fetch many attributes in the one request.

Developing enterprise applications requires a tightly controlled development environment. At any given time hundreds of developers are working on many different versions of MIMS. Version control, source control and program maintenance are general problems associated with any large development. CORBA does, however, introduce some complicating factors.

The development cycle we have used so far involves developing detailed object models for CORBA servers, documented in UML using Rational Rose. Rational Rose 4.0 can generate IDL source, which is convenient. However, a problem arises because server side models contain implementation details which generally are not made public via IDL interfaces. Instead, the output must be tailored to obtain the public interface. Rational Rose has extensive scripting capabilities, and we hope to embed this information in the object models so that useable IDL can be generated automatically.

A more serious problem arises with generation of code from the IDL compiler. Orbix, the ORB the authors have most experience with, requires extensive hand tailoring of generated C++ code. It has no facilities for modifying the IDL and merging in changes with the existing code base. This is a considerable impediment to using Orbix for large-scale development projects. Other products such as NEO have more sophisticated tools, but these are currently not mainstream.

In general, there is a significant lack of tools available for designing and developing enterprise distributed applications. Two tier client server tools such as Powerbuilder, Visual Basic and Delphi have yet to find equivalents for large distributed systems development.

Portability was an important consideration in the design of MIMS. MIMS runs on a number of databases (Oracle, Sybase, Rdb, DB2 and Informix), and on a variety of hardware platforms (Unix, VMS and MVS). Most recently, MIMS has been ported to Windows NT using the SQLServer database.

In the context of developing an enterprise distributed system, we require portability of product across:

• ORB architectures
• hardware platforms and operating systems
• databases.

As previously discussed, integration of ORB and DBMS technologies is not yet achievable in a portable way, although the Enhanced Portability proposal will do much to facilitate this. It is up to vendors to make their CORBA implementations cross-platform, and companies such as Iona have done a good job in this area. Again, the Enhanced Portability proposal will make portability of code between different ORBs much simpler. So although portability is currently a major problem, the OMG has recognised and begun to address the situation. Final submissions were due in September 1997, and it is hoped that a specification will be published early in 1998. This suggests that vendor implementations are unlikely to be available until the middle of 1998, which implies that designing enterprise applications based on this specification will not be practical until late 1998 or early 1999.

MIMS is a complicated system that requires a considerable amount of expertise to tune for any given combination of hardware and software. Also, once an installation is complete, the systems administrators responsible must be able to monitor and adjust the system as required. Sophisticated tools are available to simplify much of this administration. In a distributed environment, however, this task is vastly complicated. CORBA servers may be running across hundreds of machines, which may have vastly different hardware and operating systems. Currently, few tools are available for the administration and tuning of such systems, and this is a considerable impediment to their deployment. Customers do not want to spend large amounts of money for ongoing consulting time to keep their systems running efficiently.

The situation is slowly improving, but vendors have a long way to go before administration of a complex distributed system can be performed by the average system administrator.

Microsoft’s Distributed Component Object Model (DCOM) is in direct competition to CORBA, and may have a significant impact. The Component Object Model (COM), is already entrenched on the desktop via Windows, and DCOM is the distributed extension of COM. DCOM appears to be more immature than CORBA, and detractors doubt Microsoft’s ability to scale to the enterprise. However via its BackOffice product suite, including Windows NT, Microsoft is determined to break into these markets.

Because the OMG is a consortium of hundreds of vendors, standards inevitably take time to develop and finalise, evidenced by CORBA’s development over 8 years. Microsoft, having complete control over the operating system as well as DCOM, has an enormous advantage, and is rapidly pushing its technology forward. It also has available the OMG specifications from which it can borrow ideas, as well as an impressive cash reserve and cash flow.

As Mincom looks to implementing an enterprise distributed system over the next few years, we feel that while CORBA is not yet mature and robust enough to meet our requirements, it is gathering momentum and becoming mainstream. We expect that in the next two to three years CORBA will be a suitable basis for building such systems if the above deficiencies are addressed.

Mincom's key concerns with CORBA are in the areas of general portability and persistence. The OMG has addressed these concerns with the issue of the Enhanced Portability RFPs, and the revised submissions are encouraging. We consider it very important for vendors to implement the specifications as soon as possible after publication. It is also important that development environments mature for distributed systems.

Hopefully, the advantages of an open system that has had the input of over 760 member companies will ensure CORBA's long-term survival despite the Microsoft juggernaut.

[1] Object Management Group. The Common Object Request Broker: Architecture and Specification, Edition 2.0. July 1995.

[2] Object Management Group. ORB Portability Joint Submission. Draft 14, April 14 1997.

[3] Gokhale, A. & Schmidt, D.C. The Performance of the CORBA Dynamic Invocation Interface and Dynamic Skeleton Interface over High-Speed ATM Networks. GLOBECOM Conference, London, November 1996.

[4] Gokhale, A. & Schmidt, D.C. Evaluating CORBA Latency and Scalability Over High-Speed ATM Networks. IEEE 17th International Conference on Distributed Systems (ICDCS 97), May 27-30, 1997, Baltimore, USA.

[5] Gokhale, A. & Schmidt, D.C. Optimizing the Performance of the CORBA Internet Inter-ORB Protocol over ATM. Washington University Technical Report (wucs-97-10). 1997.

[6] Waldo, J., Wyant G., A.Wollrath, A., Kendall, S. A Note on Distributed Computing. Sun Microsystems Laboratories, Inc. Technical Report 94-29. November 1994.

[7] Paul. S, Edwin Park, E., and Chaar, J. Essential Requirements for a Workflow Standard: Why the current version of the WfMC standard is not suitable for a distributed world. Business Objects Workshop III OOPSLA’97.