This article outlines how organizations can build and maintain an integrated system infrastructure to support their business needs using open industry standards, such as CORBA, Java 2 Enterprise Edition (J2EE), and XML. In doing this, they can maximize investments in existing technologies and integrate them in a powerful and flexible way into new e-business systems.

Today most organizations are trying to come to terms with the new age of the Internet and e-commerce. Large established companies see this as necessary for survival, while smaller companies view it as an opportunity to expand in markets that aren't confined by geographical location or budgetary constraints. The Internet and, increasingly, wireless communications (telephony or otherwise) are considered the future of business. Companies must be able to embrace this new economy to survive or prosper. Increasing reliance on the Internet is driving the uptake of technologies that support the development and deployment of Internet-enabled applications.

Predominant is Java. In all its forms. Java is clearly the preferred programming language of the Internet and, in the form of Enterprise Java-Beans, is now set to dominate server-side applications.

J2EE, which encompasses Enterprise JavaBeans (EJBs), JavaServer Pages (JSP), Java Mail, Java Servlets, and so on, is the governing standard for Java-based, Internet-enabled applications (although proponents of Microsoft's .NET architecture may disagree with this generality). The numerous J2EE Application Server products now available provide excellent tools and support for developing and deploying new Internet-enabled Java applications. These products are likely to become even more innovative and usable as vendors compete for mind and market share in what's currently a very crowded marketplace.

Although J2EE application servers are excellent products in their own right, they're not the silver bullet their vendors would like us to think they are. The J2EE view of the world assumes that everything is developed in Java - which is great if you're developing new systems from scratch. But who's really in this position? Who can simply ignore and throw away the many years of effort and money spent building existing applications?

As we all know from the problems encountered by "e-tailers," a fancy front-end web site is no longer good enough. Web sites must be fully integrated with the back-end business systems such as order processing, warehousing, logistics, customer care, and so on in order to fulfill the customer's requirements quickly and effectively. In the vast majority of cases these systems are not written in Java (or as EJB applications) and therefore don't fit easily into the world of J2EE.

The question facing enterprise architects is: How do you integrate the new EJB applications with a legacy COBOL program running on an IBM/390? Before we try to answer this, we'll look at another integration technology.

CORBA
CORBA was designed for integrating applications in heterogeneous environments, that is, environments containing applications written in different programming languages running on different operating systems and different machines. In other words CORBA was designed specifically to address the integration problems faced in a typical IT environment!

CORBA achieves this level of interoperability by specifying program interfaces in an implementation-neutral interface definition language (IDL). IDL can be mapped to almost any required programming language (C, C++, FORTRAN, COBOL, Ada, etc.), allowing you to develop your programs in the language of your choice. CORBA also specifies the Internet Inter-ORB Protocol (IIOP) as a common communications protocol for TCP/IP networks. Just as IDL hides programming language differences, IIOP enables different applications to communicate with each other through a standard protocol and hides platform and network differences.

Because CORBA is a much more mature standard than J2EE (CORBA has been around for more than 10 years), it has addressed many of the issues facing the integration of enterprise-scale systems. For example, allowing applications to interoperate using just the abstractions provided by IDL and IIOP isn't true integration. True integration occurs when applications can participate in the same transaction, share the same directory services, and use the same security model. For example, if CORBA-based applications are to participate in the same transaction, they need to know the transaction context. Fortunately, IIOP is designed to implicitly propagate transaction and security context information, allowing remote objects to share this information.

The OMG has specified a number of additional services to support the core CORBA specification, including an Object Transaction Service (OTS), a Security Service, a Naming Service, and an Event Service (now superseded by the CORBA Notification Service). These form a framework of supporting services that are essential for large-scale systems and are designed to promote true integration between applications rather than just interoperability.

The Best of Both Worlds
Fortunately Sun recognized the strengths and advantages offered by CORBA and incorporated them into J2EE. The J2EE specification requires compliant application server products to support RMI over IIOP as a transport protocol, in addition to the Java-centric Java Remote Method Protocol (JRMP). With the implementation of RMI-IIOP, Java RMI objects can be accessed by CORBA objects written in another language. Moreover, Java RMI objects can access CORBA-based applications regardless of what programming language they were written in. This brings the strengths of CORBA - cross-language integration - to J2EE. J2EE Application Servers also benefit from the industrial strength of IIOP when used in large-scale systems. It's now widely accepted that IIOP scales much better than JRMP, and therefore provides a better protocol on which to base enterprise developments.

J2EE support for transactions is provided by the Java Transaction Service (JTS). The J2EE specification currently recommends (in version 2.0, it requires) the support of JTS layered on top of the CORBA Object Transaction Service. The use of OTS, and hence IIOP as a communication protocol, supports the interoperability of transactions between application servers and legacy applications.

J2EE leverages the strengths of CORBA to make J2EE application servers more robust and scalable and, at the same time, provides a more productive and simpler environment for developers. CORBA is difficult for many developers, one of the main hindrances to its mainstream adoption. However, CORBA's weaknesses - such as the lack of a true framework to support the rapid development of applications - are the strengths of J2EE. Together they make a formidable package, as can be seen in Table 1.

Now return to the question facing enterprise architects: How do you integrate your new EJB application with a COBOL program running on an IBM/390? With the implementation of RMI-IIOP, the EJBs can access CORBA-based applications regardless of what programming language they were written in. So we can use an ORB that supports COBOL (e.g., IONA Technologies' iPortal for OS/390) to provide the interface to the COBOL application, and the EJB can use RMI-IIOP to interoperate with the application's CORBA interface and, via this interface, the COBOL application itself.

Therefore, the combination of J2EE to develop new Internet-enabled applications and CORBA to integrate these applications with existing systems, provides a complete solution for integrating enterprise systemsSor does it?

Synchronous vs Asynchronous Architectures
The type of integration we've discussed so far has been based on synchronous interactions. That is, a request is made to the target application (in the form of a remote method invocation) that processes the request and returns any results. This request-reply mechanism is simply the distributed form of a method call to a local Java object. It works well within a Java program contained in the confines of a single JVM, but doesn't scale well when it spans multiple JVMs or even non-Java applications. A synchronous - or closely coupled - architecture can become fragile when it's made to grow this way. Applications become prone to slow performance when the system works at the speed of the slowest component, or even deadlocks - applications end up in a gridlock of requests waiting to complete before subsequent operations can be processed.

An alternative architecture that avoids the pitfalls of closely coupled systems is an asynchronous - or loosely coupled - system architecture. This architecture decouples the applications from directly interacting and uses a messaging system as the "buffer." The messaging system supports guaranteed delivery semantics (also called "store and forward") to ensure that messages are received by the target applications. This means that an application can send a message, then continue to perform other work, confident that the messaging system will ensure delivery to the intended recipient.

An application sends data to the messaging system and then gets on with its own internal functions - it doesn't need to know what other applications receive that data, what methods are in their APIs, or even if they're currently online. Similarly, changes can be made to an application and its interface to the infrastructure, or new applications can be added, without affecting others.

For example, consider the situation in which one application needs to send data to 10 other applications. Using traditional EAI or just an ORB, the sending application's API needs to understand the API "data write" methods of all 10 receiving applications to write the data. If a receiving application's API changes, the method calls in all sending applications may also need to change. Using messaging, the sending application needs to know only one method: how to send data to the messaging bus. If other applications fail, change, or are added, nothing changes for the sending application.

This makes the overall system much more flexible and resilient. To add another application the system is required to be integrated only into the messaging architecture rather than directly to each application that it interacts with, reducing the number of integration points dramatically. The decoupling also reduces the effect on the system when an application fails. As the messaging system acts as a buffer between applications, the remaining applications can continue to operate and any messages destined for the failed application will be queued until it's restored. Finally, with the messaging system acting as a buffer between the applications, they can all work at their optimum speed. A slow application won't affect the performance of the others, because the messaging system will store any messages until the slow application can process them.

Despite these benefits of greater flexibility, scalability, and robustness, asynchronous architectures aren't the solution to all problems. There are circumstances in which a synchronous request-reply mechanism isn't just the best solution, it's the only acceptable one. Consider the case of a customer making a purchase over the Internet using a credit card. The resultant transaction must be processed there and then, so the customer knows that the purchase has been successfully completed and the vendor has the security of a completed transaction.

This scenario requires a synchronous request-reply interaction; an asynchronous interaction wouldn't be ac- ceptable to the customer, who needs to receive transaction reference information (order number, transaction ID, etc.) straightaway. Subsequent fulfillment of the order may, however, be processed in an asynchronous manner; this doesn't concern the customer, who has now received the required reference information in case of a problem later.

Therefore, a typical enterprise system doesn't consist of only closely coupled synchronous integration, nor will asynchronous messaging-based architecture meet all the requirements of such a system. Enterprise-scale systems require a mixture of the two types of architecture, which has led to a new generation of products called Integration Servers or Brokers that complement J2EE Application Servers.

Integration Servers
Both application servers and integration servers are frequently used for integration. Application servers tend to be used by developers building some new part of an application's functionality. They support a closely coupled architecture using a request-reply interaction and tend to support fine-grained components. Integration servers, on the other hand, are focused toward integrating existing functionality rather than developing new applications. They're based on a loosely coupled architecture using asynchronous messaging and support coarse-grained integration. In this sense, application servers and integration servers can be seen as complementary (see Figure 1). The application server provides a core deployment platform and tools for application development, while the integration server augments this with tools for application and data integration, architecture abstraction, and technology and vendor "hiding" layers. In most nontrivial projects, both types of product will be required.

Figure 1 also illustrates the main functional components of an integration server, namely:

• Message broker: Provides powerful interapplication messaging functionality across multiple messaging models (e.g., CORBA, EJB, SOAP) and vendor (e.g., IBM, TIBCO) solutions.
• Data transformation: Makes the complex task of reconciling and using disparate data formats much easier.
• Process modeling and automation tool: The essential link between an end user's business processes and OEM's software applications and IT infrastructure.

Message Broker
This is the "hub" of the integration server. The message broker provides the standards-based asynchronous messaging capabilities that are essential in a loosely coupled architecture. The key standards for the message broker are CORBA, EJB (JMS), and SOAP. The message broker must also integrate to other messaging systems, such as IBM's MQSeries and TIBCO/Rendezvous, so that legacy applications using these products can be integrated into the enterprise system.

The support for standards-based messaging APIs allows developers to use their messaging API of choice. Therefore it should be possible for an EJB to send a JMS message via JMS, and for this message to be received as an MQSeries message by an MQSeries application. The sender should be unaware of the message format required by the recipients, and the recipients should be equally unaware of the format of the message when it was sent. The message broker is responsible for ensuring that the message is transformed into the correct format before it reaches its final destination. The message broker must also support the usual guaranteed delivery ("store-and-forward") semantics and provide content-based routing according to business rule.

Data Transformation
The role of data transformation is to ensure that when data reaches its destination (usually via the message broker) the format of the data is what's expected by the receiving application. The rise in popularity of XML and the "opening up" of ERP and CRM applications to support integration via XML will make data transformation capabilities even more critical to enterprise systems. It's quite possible that two-partner organizations will support different data models (whether traditional data models or XML schema) within their systems and that data transformation will need to be performed if the organizations are to integrate their systems.

Process Modeling and Automation
The final major component of the integration server is process modeling and automation. The process modeling allows business analysts to model the business processes and define the various business rules and activities that drive these processes. The process automation allows the analyst to map these business process models onto the underlying applications. The integration server then coordinates the operations of these applications according to the defined business rules.

The process automation tools must also be standards-based and support interaction between applications that are based on different architectures (e.g., CORBA, EJB, DCOM).

The architecture of a typical integration server is illustrated in Figure 2.

The use of messaging and data transformation also lends itself to supporting XML as a data format. XML has rapidly become the de facto data format of e-commerce, but has just as rapidly become fragmented by the various organizations that are defining business schema for XML data integration (e.g., BizTalk, RosettaNet, OASIS). This has resulted in a number of different forms for representing common business entities, for example, purchase orders. This disparity of forms requires transformation technology to change the data into the expected format, and the combination of asynchronous messaging and dynamic data transformation of XML make this a relatively simple but effective process. This results in the ability to integrate with applications, not just within the enterprise boundaries, but also with applications that are external to the corporate firewall (i.e., applications that exist in the "extended enterprise" - suppliers, partners, and customers that form part of the corporate supply chain). Integrating these applications using J2EE and CORBA alone would be an extremely difficult, if not impossible, task. But integration servers used with the J2EE application servers now make this type of integration more manageable.

The Future - Java Connector Architecture
Sun recently released the proposed final draft of the J2EE Connector Architecture (JCA) 1.0, aimed at providing a standard way for back-end applications to plug into the J2EE Application Server platform. JCA, which was developed under the Java Community Process (JCP), will be part of the next version of J2EE, version 1.3, expected in early 2001. Although JCA is missing some key functionality required in more complex integration situations, it marks an important step toward reducing the costs and burden of back-end integration.

The J2EE Connector Architecture defines a set of functionality that application server vendors must provide and that back-end system vendors (e.g., SAP, PeopleSoft, Siebel, Clarify, or third-party connector developers) can use to plug into the application server. The architecture doesn't specify how this capability is implemented; that's up to the platform provider or the connector developer.

The JCA has two basic components: the Common Client Interface (CCI) and a set of system-specific services. An adapter developer provides an interface to CCI along with its side of the system contracts specified as part of the connector architecture. The application server vendor implements its side of the system contracts as part of its base J2EE platform.

The JCA provides the following capabilities to the application servers:

• Transaction management: Enables the transaction manager provided within the EJB application server to manage transactions across multiple back-end systems.
• Connection management: Enables the application server to create and manage connections to back-end systems. One important capability provided is support for connection pooling, since connections to back-end systems are expensive.
• Security: Enables the developer to define security between the EJB server and the back-end system. The specific security mechanism used is dependent on the security mechanism provided by the back-end system.

It's unlikely that JCA adapters will be available until the latter half of 2001 at the earliest, and even then will be based on the version 1.0 specification. Thus they won't support asynchronous communications between the EJBs and legacy applications. It'll probably be well into 2002 (or later) before asynchronous adapters are available. Until then, integration servers look to be the best way of providing this loosely coupled integration between the Internet-enabled applications and the existing back-end systems.

Conclusion
The rapid acceptance of J2EE has done much to promote the use of the Internet as a viable e-commerce medium. However, J2EE has weaknesses when it comes to building scalable and resilient enterprise-wide architectures. By leveraging some of the features of CORBA, J2EE does overcome some of its limitations. However, it's still not enough to satisfy the real-world requirements facing most organizations. The recent emergence of a new generation of standards-based products - integration servers - will help fill the gap in the J2EE-CORBA combination. The integration server products introduce a more flexible and robust architecture based on asynchronous messaging to J2EE. This helps it extend beyond the boundaries of the corporate firewall and provide integration across the Internet using technologies such as XML and SOAP.