In-Depth

EJBs to the Rescue

• May 1, 2001

According to Forrester Research, 30 to 40% of corporate IT budgets are typically spent on integration activities. According to a GartnerGroup estimate, by 2005 e-business initiatives and infrastructure will consume 30 to 50% of enterprise IT spending. Based on these forecasts, there will continue to be strong budget and financial incentives to leverage successful integration strategies. The key to accomplishing this is to create and leverage reusable integration points within the corporate IT computing environment.

Packaging existing corporate computing assets as components enables the rapid assembly of integrated solutions. Enterprise Java-Beans in the J2EE framework provide the ability to create and package integration points in the Enterprise Application Integration (EAI) space. By leveraging J2EE technologies such as JMS in combination with Enterprise Information System (EIS) integration brokers and business-to-business integration brokers, components can be created that allow standard access to enterprise computing assets. These components can then be placed into reusable frameworks that allow them to become an integral part of e-business solutions.

The integration imperative
The backbone of the modern enterprise is spread across a diverse set of technology and applications, including legacy, Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) and Supply Chain Management (SCM) applications. The root of e-business is integrating this intricate set of application systems with new information from external partners so that they work together to form composite apps that provide business value and unlock the information assets locked up in isolated applications and data sources.

The rapid rise of e-business as a viable mechanism for expanding business opportunities and creating new supply chain solutions has added another dimension to the integration challenge. The need for dynamic business-to-business (B2B) integration requires infrastructure that can support the automation of business processes that encompass a diverse range of packaged and legacy apps both within organizations as well as with external partners. Successful e-business-enabled organizations need to integrate cross-functional business processes, including customer management and SCM that cut across many departments and business units into new composite applications. These composite apps are "new" applications that are created by integrating functionality from existing apps using integration techniques.

The greatest challenge for most organizations is unlocking the processing assets stored in legacy systems, enabling their usage in new e-business initiatives. According to a Gartner estimate, by 2003, 80% of application development organizations will leverage some form of legacy extension technology to accelerate the benefits of composite applications without the associated expense of application replacement.

EJB + middleware = integration platform
To accomplish e-business integration, an integration platform must be created that combines the presentation capabilities and technologies required of Internet-based apps with the multitude of technologies that can be utilized to integrate application systems. This platform provides "magic in the middle" by uniting multiple delivery channels on the front end with multiple information sources on the back end through a middle tier of reusable components (see Fig. 1).

Figure 1

This integration platform provides "magic in the middle" by uniting multiple delivery channels on the front end with multiple information sources on the back end through a middle tier of reusable components.

There are several approaches to creating such an integration architecture:

• Point-to-point integration that leverages APIs to create reusable components,
• EAI integration brokers that provide single-point access to a variety of back-end systems using a uniform API,
• B2B integration brokers that provide access to external data in the form of XML messages and
• Composite platforms that utilize a combination of the above to achieve maximum "connectivity."

The rest of this article will explore each of these in detail as well as provide a glimpse of what the next-generation Java platform has in store.

The J2EE platform is a solid platform upon which component-based integration solutions targeted to e-business can be built. Java technologies fit into the J2EE platform and provide a platform for creating apps that combine elements in the client tier with applications in the EIS tier via a middle tier that is comprised of presentation and business logic entities (see Fig. 1). This combination of components packaged using standard technologies, such as servlets, Java Server Pages (JSPs) and Enterprise JavaBeans (EJBs), with enterprise services provides a solid foundation for e-business integration architectures.

At the heart of the J2EE platform are EJB components and containers. The EJB component model defines the interfaces between the bean and container that provide enterprise-computing capabilities, including security and transaction support. The behavior of these capabilities is dictated by instructions specified in the bean's deployment descriptor, allowing control outside of program code.

There are two types of Enterprise Java-Beans—session beans and entity beans. Session beans are aptly named because they are executed on behalf of a single client and are limited to the lifetime of that client. The EJB component model provides no provision for persisting the state of session beans, leaving the job of saving any data for the bean as an exercise for the developer. Stateless session beans provide a collection of related but disassociated service methods, while stateful session beans maintain state for the entire session between the bean and the client. In addition, both types of session beans can participate in transactions.

Entity beans support shared access from multiple clients. Unlike session beans, the EJB component model provides the ability to automatically persist the state of the bean into a database. While session beans provide "services" for their clients, entity beans are the "packaging" for business components.

There are two types of entity beans, and they differ in how their state is persisted. Container-managed beans hide all of the dirty work of storing state in a database. The bean developer simply indicates in the deployment descriptor which attributes to store automatically, and the EJB container does all the hard work. With bean-managed components, the developer is responsible for writing code to persist specific attributes of the bean. This has the added advantage of allowing bean attributes to be stored in technologies other than a relational database. This is important because a significant portion of legacy, ERP and CRM information is provided via non-database access.

The diversity of technologies and approaches that must be taken into account make EAI a daunting task. Integration solutions involving mainframe-based systems, such as CICS applications, pose a significant challenge because there are several ways to "get there from here," and managing the mix of technologies becomes a nightmare. For example, CICS applications can be accessed utilizing 3270 access, transactional access or message-based access over message-oriented middleware.

Key enabling technologies can be utilized to create integration points (see Fig. 2). JDBC is used to re-face database queries and tables as EJB objects. Transactional CICS systems can be accessed using IBM's External Call Interface (ECI), which allows communication via the commarea. JMS can be used to provide the underlying messaging interface. For applications that provide only user-level integration points, such as 3270-based applications, screen-scraping and packaging the elements on the screen provides the ability to re-face the screens as components.

Figure 2

Packaging database, legacy, CRM and ERP assets as EJBs provides the ability to capture essential constructs and reuse them. Using key enabling technologies to create integration points replaces chaotic point-to-point integrations with coordinated, interoperable connections.

Packaging database, legacy, CRM and ERP assets as EJBs provides the ability to capture essential constructs and reuse them regardless of the underlying technology. Once these EJB components have been developed, they can be reused as new features are added to the e-business application or as new applications and components are developed.

Connecting the EJBs together into new applications that use the capabilities of today's application server environments effectively will allow the rapid creation of new integrated solutions and composite applications. This will, in turn, allow new features to be added to the application while leaving the legacy or ERP system intact.

Combining point-to-point integration solutions with other middleware technologies, such as message or integration brokers, opens up new horizons in integration and provides a robust, scalable and extensible integration platform that provides message-based integration among multiple application systems. The power of this approach lies in replacing a potentially chaotic and disorganized set of point-to-point integrations with a coordinated set of interoperable connections which can be reused and serve multiple purposes.

In this integration architecture, the integration broker provides a single interface for accessing legacy, CRM or ERP assets, replacing the point integration solutions such as JDBC, ECI, JMS and MQSeries with a single API set (see Fig. 3). Adapters provided by the integration broker vendor allow these systems to plug into the integration architecture and EJB components transparently.

Figure 3

The integration broker provides a single interface for accessing legacy, CRM or ERP assets, leveraging XML as a standard message format. The point integration solutions—such as JDBC, ECI, JMS and MQSeries—are replaced by a single API set.

A significant advantage of this approach is the ability to leverage XML as a standard message format. A number of products available on the market today can be used to create Java classes from XML constructs, which eliminates the need to write Java code that utilizes XML parsers and the Document Object Model (DOM).

One such tool is the Breeze XML Studio from The Breeze Factor LLC in Encinitas, Calif., which allows developers to create a JavaBeans class graph that encapsulates XML parsing and validation and has methods that map directly to the XML data elements and attributes. At runtime, these JavaBeans are populated with the appropriate data from the XML document. The beans can then be packaged as an EJB, called EJB A, enabling the XML information to become an integral component of an integration architecture (see Fig. 3).

B2B integration brokers provide the ability to integrate processes and information external to an organization. They provide connectivity between supply chain partners, customers and exchanges with application components via data exchange using XML messaging (XML/HTTPS) (see Fig. 4). Combining the capabilities of these brokers with a tool like Breeze allows the creation of integration components that can become an integral part of the B2B integration architecture.

Figure 4

B2B integration brokers provide connectivity between supply chain partners, customers and exchanges with application components via data exchange, using XML messaging.

The true value of these integration platforms is a combination of all this into a composite integration platform. In Figure 4, EJB A and EJB B are responsible for providing the interface for a new B2B transaction, handling the receiving of the request and the sending of the response respectively.

In this architecture, EJB A receives an XML message from the B2B integration broker and parses it to a Java class hierarchy. In turn, EJB A utilizes a combination of point integration and integration broker approaches to access the back-end EIS systems that are required to participate in the transaction. When all the participating systems complete their processing, control is passed to EJB B, which creates the response message and sends it back to the B2B integration broker, which routes it to the appropriate recipient.

Concept Five Technologies has architected and implemented several of these integration platforms. This experience demonstrated that there is not an either/or approach to deciding how to architect integration platforms. The ultimate value of these platforms lies in packaging integration points in components and in the ability to assemble solutions rapidly with them.

Component integration frameworks provide maximum value
While packaging legacy, ERP and CRM functionality as reusable EJB components provides obvious benefits, the biggest bang for the buck for e-business integration and e-nablement comes when those components are melded into a component integration framework. By providing the architectural foundation for connecting the integration components, these frameworks provide an architected approach to creating new e-business processes and transactions in a rapid and well-defined manner.

One particular pattern that we have implemented successfully in component integration frameworks is an extension of the classic Model-View-Controller (MVC) pattern. The MVC design pattern divides an interactive application into three discrete functional components. The model component contains the core functionality and data; the view component provides information to the user; and the controller component ties the model and view together to create the new transaction or process. In this approach the interactive application is the transaction or business process initiator, which can be a servlet, a Java Server Page or another presentation layer component.

Figure 5 illustrates how the MVC pattern is cleanly implemented in an EJB-based component integration framework that utilizes a composite integration platform. The architecture illustrated in Figure 5 is an extension of the one depicted in Figure 4 where the labeled beans correspond to each other. In this case, EJB A is a session view bean that provides the "view" into the architected framework that holds the components of the B2B transaction together. EJB B is a session view bean that receives the response information for the transaction and passes it back to the B2B Integration Broker.

Figure 5

The MVC pattern is cleanly implemented in an EJB-based component integration framework that utilitzes a composite integration platform.

The model beans use a combination of point integration and integration broker solutions to componentize back-end processes and data. These model beans are required to be bean-managed entity beans because they are responsible for retrieving and saving their own state. Figure 5 illustrates that the entity model beans in this architecture are a set of screen object beans that encapsulate data in a 3270-based CICS app, a set of data object beans that use JDBC to access relational databases and an integration broker to access an ERP system, and a set of model beans that provide access to CICS transactions via ECI and JMS. The controller beans call methods on the model beans to provide transaction and process control that utilize the information in the model beans for integrated business processing.

The container-managed entity beans in the controller layer "tie" the model beans together to provide either process control (process bean) or transaction coordination (transaction bean). The process bean calls methods on model beans to provide process flow control and coordination for business processes. The transaction bean provides the transaction control for a B2B transaction that leverages information and processing stored in legacy business systems. Instead of calling the various model beans directly, an integration model bean is used to coordinate all of the legacy model beans with the XML Beans with information supplied from the XML for the transaction. Once again, these XML beans can be created and populated using a tool like Breeze.

The power of this approach is the ability to create new business transactions by connecting model beans using controller beans, which provide the overall control and coordination point. The model beans can be created once and used in a variety of business processes and transactions. The view beans provide a simple services-based interface for a particular set of related transactions or processes, which hides the potentially significant number of model beans required. Packaging all of this functionality as a set of EJBs in a framework provides true reuse in an architected integration environment.

A glimpse of the future
The next generation of the J2EE platform promises new riches as yet another way of creating an integration platform. J2EE 1.3 adds support for J2EE connector architecture, which defines a standard set of services that allow rapid and standard integration of new applications with virtually any back-end enterprise information system. These services are supplied as "plug-in" connectors—resource adapters that will be supplied by EIS and Java software application server vendors.

The J2EE connector architecture defines a standard architecture for connecting J2EE components to heterogeneous EISs, including ERP, mainframe systems, database systems and legacy apps not written in Java. By defining a set of scalable, secure and transactional mechanisms, the J2EE connector architecture enables the integration of EISs with components that run in application servers with enterprise applications.

EIS vendors provide a resource adapter that plugs into an application server environment, providing standard connectivity between its EIS, the application server and the enterprise app. If an application server vendor has extended its system to support the J2EE connector architecture, it is assured of seamless connectivity to multiple EISs. The big bang for the buck for vendors is that they only need to provide a single standard resource adapter, which has the capability to plug in to any application server that supports the J2EE connector architecture.

Multiple resource adapters (one resource adapter per type of EIS) can be plugged into an application server. This capability enables EJB and other J2EE components that are deployed in the application server to access the underlying EISs. The resource adapter is used by an application server or client to connect to an EIS. The resource adapter "plugs into" the application server and collaborates with it via a set of standard interfaces to provide underlying security and transaction support in a manner similar to EJB containers.

Several ERP vendors are getting a jump on the new architecture by releasing connectors that are compatible with popular application servers. Two examples are PeopleSoft and SAP. By using PeopleSoft's Component Interfaces, third-party systems can synchronously invoke PeopleSoft business logic via EJB. SAP validates third-party products for SAP's Business Technology that support development of business logic in Java and data transfer using XML.

Where do we go from here?
As industry pressure to implement e-business initiatives increases and other trends such as mergers and acquisitions accelerate, the need to integrate legacy systems with the new "e-conomy" will only increase. The need for architected composite integration platforms will also increase as the industry continues to mature and product vendors rush to keep pace and vie for IT dollars in a very competitive marketplace.

By beginning to architect these platforms and creating integration frameworks from packaged components, organizations will get a jump-start and be in a much better position to craft the next generation of B2B applications.