Key Architecture Requirements for Enterprise CORBA Systems

nterprise systems built using objects require a backbone capable of supporting enterprise computing requirements -- one that delivers scalability, transaction integrity and fault tolerance. But no longer are these features alone enough. Any successful enterprise system must also be distributed and standards based. This article provides a roadmap to the synergistic relationship between a new breed of object application server technology and the standards put forth by the Object Management Group.

A scalable object application server architecture offers a robust and powerful core object system while the OMG's CORBA 2.0 standards deliver interoperability among diverse systems. This combination provides developers with an object execution platform capable of managing the diverse array of applications and platforms found in most enterprises today. CORBA's distributed object architecture extends the reach of object applications to all object languages, the Web, application programming interfaces, and to non-object services.

When high capacity and performance are at issue, an integrated object application server that has been engineered for thousands of users and millions of objects is emerging as the product of choice. It combines both a multi-user object execution engine and a robust object repository in a single object application server. This is the type of scalable, robust platform necessary to support enterprise CORBA applications without limits. Lightweight application servers based on architectures designed for single-user environments fail to deliver sufficient scalability and robustness for enterprise scale applications.

CORBA-Compliant Information Systems

The OMG is driving a set of standards that are achieving widespread adoption to support interoperability among products from a multitude of object technology providers. Influenced by the industry-wide shift from monolithic to distributed systems, the OMG's central focus is CORBA, a collection of standards for the object components of distributed information systems.

The object paradigm was first demonstrated with programming languages, and in particular, with Smalltalk and is now being carried forward into mass popularity with Java. Prior to distributed object systems, monolithic object systems thrived within the boundaries of a single machine, a single language, and in a single address space. Instances of classes were created, objects were called to action by messages, and at the end of an object's lifecycle, the memory allocated to it was automatically reclaimed.

Early applications of object technology exploited the object as a much-improved module for programming. With inheritance and polymorphism to support code reuse and encapsulation to enhance independence, objects quickly became a new and better way to write dynamic, model-based, event-driven applications. As the challenges of distributed computing emerged, however, objects found a new use: as self-contained units of behavior and data, objects were ideal candidates for distribution.

An object request broker extends the object paradigm beyond the boundaries of a single machine or a single programming language. ORBs allow objects residing on different machines to exchange messages as though they were residing in the same address space. For example, when the user of a financial planning system clicks on an icon requesting information from a technology investment portfolio, an ORB may forward that message to a portfolio object stored across the network on a server. In a similar fashion, a request from the portfolio object for investment performance history may be routed by the ORB to a performance history object on another server. The users need not know where objects are stored or where their requests are executed. It is the ORB that silently resolves these issues and carries out the user's request. Of course the ORB does more than simply locate the remote object and deliver requests. When several users request access to the same investment portfolio, for example, then the ORB must manage concurrent access to ensure that each user sees consistent information. In addition to managing concurrency, the ORB is responsible for maintaining a secure environment where only authenticated and authorized users can find their way to certain objects.

Information systems cannot be constructed solely with an ORB. The ORB is often likened to the hardware bus in a computing device. Just as the hardware bus moves data from storage to processors to peripheral devices, so the ORB routes object requests from place to place. Above the realm of the ORB are a number of other critical information system services. Among these services are repositories for object definitions, services for creating and managing objects, and couplings to external (non-object) sources of information. An ORB provides communication pipelines among software components that make up a distributed object system. In order to do so, ORBs provide standards for the object services that define the messages they route.

The OMG stages the development and release of its standards in phases. CORBA 1, released in 1991, focused on the development of an Interface Definition Language [IDL] that is independent of any particular programming language. Thus IDL provided a beginning point for ORB developers and assured users that objects described with the IDL would run successfully on any particular vendor's ORB. CORBA 2.0 added Inter-ORB standards to assure communication among ORBs provided by different suppliers. Along with the IDL and Inter-ORB standards, CORBA presently includes Common Object Services Specifications [COSS]. Agreement on Inter-ORB communication by OMG members was a painstaking process.

Regardless, CORBA has emerged as the dominant middleware for knitting together enterprise systems as well as the communications vehicle for many Web applications going forward. A critical requirement in the enterprise arena, however, is a server-side ORB capable of managing millions of objects, automatically managing memory (i.e., garbage collection), and able to scale to enterprise proportions. An object application server brings precisely this missing capability to the ORB marketplace.

The Three-tier Architecture

An integrated object application server provides a complete architecture for fielding applications and, as Figure 1 shows, plays a central role from its position as the object processing engine in the middle tier of the three-tier client/server architecture. Relational databases from several vendors and mainframe databases such as IMS can be accessed as well. The object application server provides a high-performance execution and persistence engine that is a key component of enterprise-wide distributed object applications. The object application server interoperates with CORBA both as a consumer and as a provider of CORBA's common object services. Using OMG's Internet Inter-ORB communication protocols, the object application server provides a robust, scalable infrastructure for deploying enterprise-wide CORBA-compliant systems.

Figure 1

The integrated object application server executes shared application logic and hosts the common business object model in a scalable object execution environment that provides persistence and a shared object cache. CORBA access and services are provided by being implemented inside this scalable, persistent environment. It is important to note, when building large-scale systems, that the shared repository is really a logical concept. Objects in the repository exist in different physical locations and even in different types of databases, such as in the object application server itself or in a relational database or in legacy systems. This three-tier architecture offers a very flexible and scalable model for distributed applications.

Integration in Enterprise Applications

Two complementary mechanisms provide access to objects that are remote with respect to a particular server: replication and forwarding. The replication mechanism provides a local copy and the forwarder mechanism provides message routing to the remote object. Together, these two mechanisms allow application developers to tune systems for optimal performance. The nature of the objects to be distributed is critical in determining whether to use replicates or forwarders.

In applications where many users rely on a core set of objects that change slowly, replication is the best choice. For example, pricing information for a national retail store is likely to be best replicated at each store. The object application server should provide mechanisms for systematically updating replicated objects. In the case of retail pricing, such updates might occur overnight. Through replication, high-speed access to information is handled locally without burdening wide area networks.

In applications where subsets of objects are used predominantly at a site and where occasional access to all objects is necessary, the forwarder mechanism is best. Equipment information for a leasing company, for example, is best stored locally. If the staff of the local depot needs to locate additional equipment stored at other depots, forwarders provide access to repositories. Federated object application servers provide support for other needs as well. Fault tolerance can be targeted to particular subsets of objects, for example. Overall application performance across a network of servers can be better balanced with mechanisms that reconfigure processing and network loads. Workflow systems in which objects migrate from one part of an enterprise to another are better designed with federated repositories. System designers can weave together federated object application servers and CORBA inter-application communication. CORBA's strength is interoperability with any and all CORBA-compliant languages, interfaces, packages and services. Federation is appropriate for portions of the system where a single logical object model is necessary and, at the same time, the model must be distributed to many physical locations.

The Object's Application Server's Special Role

The primary role of the object application server is the management and execution of business objects, the substance of the application itself. Business objects (the domain objects that occupy the middle box in CORBA diagrams) are likely to number in the thousands or millions in enterprise wide applications. These objects require the transaction, concurrency, and security services provided by a mature object application server. In addition, the object application server is a powerful tool for managing access to legacy data. By way of the CORBA bus, the object application server can be integrated into enterprise applications as a robust, high-performance, object storage and execution subsystem. In addition, developers can use the CORBA connection to provide access from the object application server to other CORBA-compliant component software.

A Practical Example

The customer support function, common to most organizations, varies by industry. For insurance, product, or utilities industries, customer service may be called claims adjustment, help desk, or repair dispatch respectively. In a health care environment many different providers may access and contribute information to patient records. Despite many manifestations, customer support systems share many common design attributes. In a typical transaction, a customer encounters a problem and telephones the enterprise, where legacy databases store customer, product and services information. Help desk representatives assist customers by using information systems that provide access to the data. This may include history of an open problem, advice from product diagnostic knowledge bases, or support for querying databases containing part lists, regional repair shops, shipping information, and so on. Many organizations are also implementing a gateway to customer access via the Internet.

Customer support systems are a challenge to build, and often depend on legacy data stored on different hardware platforms. While some data may be textual, other data may be images or diagrams (i.e. schematics, maps). Help desk staff equipped with workstations must navigate efficiently in order to locate the right information in a matter of seconds. Automated telephony applications, helpful in screening incoming calls to increase leverage for the support organization, demand additional sub-system integration. If help desk personnel dispatch repair crews or enter orders for parts, then the update of databases by concurrent users must be managed as well.

An automated help application attempts to assist customers who have called for help and, along the way, collects information about the customer, product, and problem. The application runs independently until it determines that it cannot help the customer. At this point, the application bundles up the information gathered and, via CORBA, calls for help from an object application server. The logic being executed on the object application server quickly sorts out the customer information, locates an appropriate help desk person who is both capable and available, and dispatches, via CORBA, a work order. This provides the help desk person with knowledge of the problem at hand before he or she talks to the customer.

While many help applications may access, via CORBA or the Internet, many different sources of information, the object application server is used to manage concurrent access to shared data. Dispatching repair crews or configuring an order for parts are best handled by the fault tolerant, secure object application server environment. Increasingly, customers engage the enterprise through the Internet and interact with Java-enabled applets that collect information and dispense basic advice. When these Java applications reach their limit and can no longer offer advice, they are able, through CORBA, to pass information to the object application server.

From a design point of view, CORBA enables object application servers to participate in peer-to-peer distributed systems and, at the same time, to offer object application services when necessary. The CORBA bus provides a standard mechanism for communicating between multiple object and non-object applications and subsystems. Over the coming years, products built around CORBA standards will provide improved services and facilities for constructing distributed systems and the object application server will emerge as a key enabling technology in the enterprise computing landscape.

Enjoy the article? Subscribe to Eye on Objects!

Brian J. Edwards directs technical, market and competitive research projects for GemStone Systems Inc. He has more than 12 years experience in the high technology industry and has been with GemStone for the past five. He can be reached at brian@gemstone.com.

Home Page