Enterprise Application Integration

White Paper

COPYRIGHT INFORMATION
Copyright Hughes Software Systems, 2003 All information included in this document is under a license agreement. This publication and its contents are proprietary to Hughes Software Systems. No part of this publication may be reproduced in any form or by any means without the written permission of Hughes Software Systems Prestige Opal, 146, Infantry Road, Bangalore 560001 India

TRADEMARKS
All the brand names and other products or services mentioned in this document are identified by the trademarks or service marks of their respective owners.

DISCLAIMER
The information in this document is subject to change without notice and should not be construed as commitment by Hughes Software Systems. Hughes Software Systems assumes no responsibility or makes no warranties for any errors that may appear in this document and disclaims any implied warranty of merchantability or fitness for a particular purpose.

CONTENTS

eAbstract ....................................................................................................................................................................................1 Enterprise Application Integration..........................................................................................................................................1 Java 2 Platform Enterprise Edition .........................................................................................................................................3 Java Messaging Service Overview ...........................................................................................................................................3 J2EE Connector Architecture Overview ..................................................................................................................................6 EJB Overview ...........................................................................................................................................................................9 Web Services Overview...........................................................................................................................................................13 Web Services Architecture......................................................................................................................................................14 Operations in Web Services....................................................................................................................................................15 eXtensible Markup Language (XML) Overview .....................................................................................................................16 Third Party Solutions ..............................................................................................................................................................19 TIBCO Messaging Solutions ..................................................................................................................................................19 Integration Scenario - Business Requirement .......................................................................................................................23 Integration Scenario Technical Solutions...........................................................................................................................26 Conclusion ................................................................................................................................................................................33

Enterprise Application Integration

eAbstract
In a fast-evolving technical scenario, integration know-how has undergone a major revolution. This has facilitated the provision of services such as Operation Support System (OSS) and Business Support System (BSS). OSS or BSS solutions involve multi-vendor products that interface together to provide the required functionality. The concept of a message bus or integration framework is to support the exchange of messages between the vendor components that connect to the bus. This is required to reduce the stove piping between various third party management functions or applications. This white paper provides insights on integration technologies such as J2EE (JMS, JCA and EJB), Web Services, XML and TIBCO messaging middleware (Rendezvous).

Enterprise Application Integration

Enterprise Application Integration can be defined as the combination of processes, software, standards, and hardware, to seamlessly integrate two or more enterprise systems, allowing them to operate as one. An enterprise may want to migrate to latest technology for its operations. However, it may continue with the existing set of applications. EAI devises ways to efficiently integrate the new applications to the old setup. Although EAI is often associated with integrating systems within a business entity, EAI may also refer to the integration of enterprise systems of disparate corporate entities (B2Bi) when the goal is to permit a single business transaction to occur across multiple systems.

Scope The white paper focuses on Enterprise Application Integration (EAI) and the related technology used for seamless integration of heterogeneous enterprise application systems. It presents: an in-depth study of the EAI architecture and the technology required for new-generation BSS Telecom Management Solutions, a study of available third party integration brokers that meet the messaging requirements. An example is TIBCO scope, advantages, and justification of various technologies such as J2EE, Web Services, XML. Also discussed are their features and third-party solutions. a real-time BSS case study that discusses integration of a billing system, order and work flow management system, mediation and provisioning system, and an inventory management system through an integration broker. Different solutions for this case study are also discussed.

History of EAI Enterprise applications, from as early as the 1960s through the late 1970s, were simple in design and functionality. They were developed largely in part to end repetitive tasks by replicating manual procedures on the computer. No thought whatsoever was given to the integration of corporate data. By the 1980s, several corporations were beginning to understand the value and necessity for application integration. Challenges arose, however, as many corporate IT staff members attempted to redesign already implemented applications to make them appear as if they were integrated. Examples include trying to perform operational transaction processing (associated with enterprise resource planning - ERP- system functionality) on systems designed for informational data processing (data warehousing functionality). With the prevalence of ERP applications in the 1990s, corporations felt the need to be able to leverage already existing applications and data

Enterprise Application Integration within the ERP system. This could only be done by introducing EAI. Other issues driving the EAI market include further proliferation of packaged applications, applications that addressed the potential problems of the Year 2000 (Y2K), and supply chain management/business-to-business (B2B) integration. Also, streamlined business processes, Web application integration, and overall technology advances involved EAI development. After Y2K, many in the industry have focused on migrating to new generations of network technologies. Today, however, service providers business and operational support capabilities are moving to the forefront of the strategic priority list. Service providers face a major challenge in designing and deploying an operations support environment that not only differentiates them in a highly competitive market, but also provides the flexibility and scalability for continuing to support change for the foreseeable future. The OSS solution integration market is driven by a growing number of new forces that are direct results of the rapid transformation within the telecommunications sector. The OSS solution integrator tries to address service provider issues and help them design and implement the optimum operational support systems and business process environments. logical objects that represent the execution of one or more business functions. The Message Services layer provides generic services that can assist the functioning of above layers. This includes services such as reformatting messages, routing, load balancing, alternate path switching, and message warehouse. This layer, together with the Transport Services layer is often referred to as a message broker. The Transport Services layer is the world of the basic middleware products. Message-oriented middleware is one of the key players there, but this layer also incorporates other middleware products such as object request brokers and transaction managers. This layer also provides several other supporting services such as audit, logging and security. From a development point of view, this also includes aspects of APIs, message formats, and templates.

Advantages of EAI In integrated solutions, data is shared between the different departments in organizations. It opens up opportunities for more focused and intelligent marketing, improved sales and cross-selling, as well as more sophisticated knowledge management and analysis of future trends within their own industry sectors. With the integration between a company and its suppliers, catalogs are always correct, stock levels known at all times and delivery requests can be processed immediately, because a direct link obviates the need for copies of data. Product expansion moves into new vertical sectors, and acquisitions can be achieved using phased integration of an organizations systems, by either linking directly to a similar integration solution, or by introducing each acquired system into the acquirers integration service. An integrated enterprise will have redefined their internal systems and processes so that they can be shared with the wider world. Security and manageability must obviously be incorporated to protect everyones interests, but once suppliers and customers can directly access

Building blocks of EAI Most EAI implementation have the following layers: Business Process Component Message Services Transport Services.

The Business Process layer is where the business modelling is done, where the flow of business processes and associated business rules are defined. The business layer defines the rules for the chaining and the interaction of components. The Component layer is the highest stack level that is under control of IT. This layer provides all the necessary building blocks that the business people can manipulate in the above layer. In a messagebased EAI approach, business components are

Enterprise Application Integration your systems, you can respond to their needs more cheaply and effectively. By externalizing internal systems, an organization will be far more effective at responding to changing market forces and able to re-use good processes and only reinvent the specific processes that need changing or creating. This will save time and money, bringing new products and services to the market faster, and allowing the organization to create and maintain true first-mover advantage, which is ever harder to achieve and retain. activation; request demultiplexing; framing and error handling. It also automates parameter marshalling and demarshalling; and operation dispatching. CORBA is language independent. EJB-to-CORBA communication is straightforward as the EJB specification includes a section on CORBA interoperability. TIBCO Software Inc. has a variety of EAI solutions such as Rendezvous. TIBCO Rendezvous is a message-oriented middleware. An evaluation of the afore-mentioned technology is presented in the following paras.

EAI Technology In the Market Many EAI technologies are available in the market. They are based on: Sun Micro Systems Java 2 Platform Enterprise Edition, (J2EE), Microsofts .NET, Common Object Request Broker Architecture (CORBA) and solutions from other third-party integration vendors such as TIBCO and Vitria.

Java 2 Platform Enterprise Edition

Java Messaging Service Overview
Java Messaging Service (JMS) APIs are Sun Micro Systems contribution to Message Oriented Middleware (MOM) architecture. Over the years, MOM systems have evolved in a proprietary way meaning, each messaging product has its own API, which creates vendor lock-in because the code is not portable to other messaging systems. This also complicates the job of developers, as they have to learn each messaging products APIs to integrate products from multiple vendors. Figure 1 shows a typical MOM architecture. The advantage of this architecture is that it supports asynchronous messaging. That means, even if the intended recipient is not up and running, the sender can convey the message to a queue and continue working.

J2EE provides a set of Java Messaging Service (JMS) APIs for message-based integration. It defines certain standards known as Java Connecting Architecture (JCA) for implementing Enterprise Application-specific resource adapters. Enterprise Java Beans (EJB) technology helps to easily implement business rules for integration. A J2EEcompliant application server plays the role of a message broker. CORBA is an open distributed object computing infrastructure that is being standardized by the Object Management Group (OMG). CORBA automates many common network programming tasks such as object registration, location, and
Application 1

Message Oriented Middleware (MOM)

Application 2

Figure 1: MOM Architecture

JMS eliminates many of the disadvantages of proprietary messaging products by setting up a common standard for MOM. It is a set of Java

interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprisemessaging product. In simpler terms, JMS has two parts:

Enterprise Application Integration (a) an API that the developer uses to implement applications to send and receive messages, (b) a Service Provider Interface (SPI) where socalled JMS drivers are plugged in. Sun published the first JMS specifications in August 1998. The latest one is JMS version 1.1. These days JMS is available with all J2EE-compliant application servers. With the release of the J2EE 1.3 platform, the JMS API is an integral part of the platform, and application developers can use messaging with components using J2EE APIs. Other than JMS there are a variety of products present in the market having MOM architecture. A few examples are TIBCO Rendezvous, IBM MQSeries, and Microsoft MSMQ. implementation of the J2EE platform at release 1.3 includes a JMS Provider. JMS Client- JMS clients are programs or components written in the Java programming language that produce and consume messages. Messages- Messages are objects that communicate information between JMS clients. Administered Objects- Administered Objects are pre-configured JMS objects created by an administrator for the use of clients. The two kinds of administered objects are Destinations and Connection Factories. Native Clients- Native Clients are programs that use a messaging products native client API instead of the JMS API. An application that was created before the JMS API became available, and was subsequently modified, is likely to include both JMS and native clients.

JMS Architecture As per JMS specification, a JMS application consists of the following parts: JMS Provider- JMS Provider is a messaging system that implements JMS interfaces and provides administrative and control features. An

The predecessors of JMS supported either a Pointto-Point or Publish/Subscribe approach to messaging. JMS supports both. According to the specification, a stand-alone JMS provider may implement one or both approaches, but a J2EE Container/Application server must implement both. Figure 2 depicts the JMS objects necessary to provide JMS connectivity to a remote server.

Figure 2: JMS Architecture

Enterprise Application Integration JMS for Integration ConnectionFactory is an administered object used by a client to create a connection, which itself is an active connection to a JMS provider. Because of the authentication and communication setup processed when a connection is created (most clients will do all their messaging with only one), it is a relatively heavyweight JMS object. Destination encapsulates the identity of a message destination and contains provider-specific address and configuration information. Sessions are the JMS entities that support transactions and asynchronous message consumption. JMS specifications do not require client code be to be used for asynchronous message consumption. Also, the specifications do not require client code to be capable of handling multiple, concurrent messages. Instead, transaction multiplexing within a connection is demarcated and encapsulated within a Session. A Session is an atomic unit of work similar to a database transaction. It is very difficult to implement multithreaded transactions, and Sessions provide the throughput advantages of concurrency with the ease of single-threaded programming. MessageProducer and MessageConsumer objects are created by a Session object and are used for sending and receiving messages, respectively. To guarantee the delivery of a message, messages to and from the remote server object should be sent in persistent mode. The persistent mode instructs the JMS provider to log the message to stable storage as part of the client's send operation. This in turn ensures that the message will survive a JMS provider failure. Session, MessageProducer, and MessageConsumer JMS objects do not support concurrent use, while ConnectionFactory, Destination, and Connection objects do. After these objects and common facilities are in place, a client application has the basic JMS setup required to produce and consume messages. Integration here implies Enterprise Application Integration. The usual EAI scenario involves integrating 5 to 10 different enterprise applications. If some of these enterprises support message-based communication, JMS can be used to integrate those applications. JMS Drivers are required for each of these enterprise applications. The main purpose of these JMS Drivers is to marshal and un-marshal message data. These drivers are either customdeveloped by the integration vendor, or by some third-party vendors. Examples of such JMS drivers are TIBCO Enterprise for JMS and Spiritwaves JMS Driver. Here the application server (J2EE server that implements JMS) plays the role of a message broker. The following two components are used for integration with JMS. Message Driven Beans JMS Message

Message Driven Beans Enterprise Java Beans (EJB) are J2EE components deployed in an Application server. EJBs assist a developer to program without worrying about the transactions, connection pooling, thread safety or load balancing. Normally the workflow in the case of J2EE-based EAI is defined in EJBs. Therefore, there is nothing wrong in using an EJB to produce or synchronously receive messages. However, a problem arises with receiving asynchronous messages. In this case the programmer has to write code to register the receiving application as a listener for JMS messages. This requires a decent amount of coding. There are some more problems in this approach, which are out of scope of this document. To solve these kinds of problems SUN has come up with the concept of Message Driven Beans (MDB) as part of their EJB 2.0 specification. MDB is a special EJB component that can receive JMS messages from a message queue. As per specifications it is decoupled from any clients that sends message to it. JMS Message JMS has five message types, and while the type used depends on the requirements of the

Enterprise Application Integration application, most client implementations use either ObjectMessage or MapMessage.
1.

JMS in Integration While choosing JMS as the messaging solution, issues such as application server performance, data distribution, security, and error handling must be considered. Moreover, if there are many heterogeneous applications to be integrated, and no direct JMS drivers are available, the custom development of JMS drivers will prove costlier, especially in case of Legacy enterprise systems. Industry experts generally consider JMS usage for EAI only when absolutely necessary. In other words, if the analysis of the entire system or integration problem suggests benefits from caching, performance, and scalability from multiple JMS servers, JMS may be appropriate for that system. However, many simpler alternatives can provide the requisite layer of abstraction between client and server while taking advantage of HTTP and XML, and offering desired scalability and synchronous/asynchronous communication.

ObjectMessages are messages that contains a serializable Java object to inform programmers about the data type and field that they receive and set. MapMessages use a set of name-value pairs, where names are strings and values are Java primitives.

2.

Alternatively, JMS TextMessages may be more appropriate for XML-based messages, where JMS is used for the transport layer, but not for data definition. All JMS messages support the Acknowledge method for use. If a client uses automatic acknowledgment, calls to Acknowledge are ignored. JMS messages sent by a Session to a Destination must be received in the order in which they were sent. Therefore, their implementations must provide for the sequencing of incoming messages. Many messaging applications cannot tolerate dropped or duplicate messages, and require that every message be received only once. JMS messages are persistent by default. JMS specification discusses different kinds and degrees of reliability. A detailed discussion of these specifications is out of scope of this document. In simple words, the persistence is achieved by storing messages in a persistent storage. As per the specifications, the message producer can determine whether a persistent mode of delivery is required or not.

J2EE Connector Architecture Overview

Enterprise applications have to access functions and data associated with applications running on Enterprise Information System (EIS). Application servers extend their containers to applications and support connectivity to heterogeneous EISs. Enterprise tools and EAI vendors add value by providing tools and frameworks to simplify the EIS integration task. Bi-directional connectivity between enterprise applications is essential for enterprise application integration. The J2EE Connector Architecture (JCA) defines standard contracts, which allow bi-directional connectivity between EISs.

Application 1

Application 2

Application 3

EIS 1

EIS 2

EIS 3

Figure 3: Integration of EIS

Enterprise Application Integration

Though Java/J2EE-based application integration existed even before JCA, it was complex and problematic. This was because there was no standard for such integration. Even before the advent of J2EE standards, people used proprietary application servers for integration. EIS vendors generally do not support application servers. So, custom development of integration workflow is required. This implementation is complex and nonportable, and there are no common standards to implement so-called EIS-specific Connectors/Adapters. Figure 3 given above shows the complexity involved in integrating three EISs with three other applications. The EIS connectors are not shown here because it is understood that each EIS will have its own connecting mechanism above them. To solve this problem, Sun and its Java Community Process partners have proposed the JCA standard. JCA 1.0 is part of the Java 2 Enterprise Edition specification, version 1.3. Members of the expert group working on JCA include Sun, BEA, Fujitsu Ltd, IBM, Inprise (Borland), Motorola, Oracle, Rational Software, Sybase, TIBCO and Unisys.

IBM followed this thought process and came up with a framework called Common Connector Framework (CCF) architecture. Later, Sun took up this idea and came up with a connector architecture standard that they included as a necessary component of their J2EE architecture. The latest JCA specifications (1.5) is a part of J2EE 1.4 that is currently a beta release. The major difference in JCA 1.5, is the support for asynchronous communication. It supports many more features that ease the integration with EIS. Discussion on the all JCA features is not within the scope of this document. This discussion is based on JCA specifications 1.0. The main JCA components are: a set of APIs that define certain contracts for the container in which the connectors are deployed, contracts for the applications that use these APIs to connect to an EIS and their implementation

Figure 4 shows this architecture. The JCA specification says multiple resource adapters (one resource adapter per EIS type) are plugged into an application server. This capability enables application components deployed on the application server to access the underlying EISs. An application server and an EIS collaborate to keep all system-level mechanisms (transactions, security, and connection management) transparent from application components. As a result, an application component provider focuses on the development of business and presentation logic for its application components, and need not get involved in systemlevel issues related to EIS integration.

Connector Architecture A Connector is a set of related classes that lets an application access a resource such as data or another application, on a remote EIS. Typically, a connector accesses non-relational data and is used by developers to complement the other means of accessing data (such as RDBMS) using JDBC. A simple analogy is to think of these classes collectively as a pipeline that transmits data from a resource to the application when the application requests it. The behavior of a connector at runtime is similar to a transaction. The application requests data from the connector, and the connector gets the data from the resource and returns it to the application. If there are standards to define the application part of the connectors, it will be easy to integrate multiple systems, as system integrators will only have to deal with the interfaces prepared as per the standards. The EIS-specific implementation will be hidden from the developer. 7

System Contracts JCA adapters normally plug into a J2EE-compliant application server. To achieve a standard systemlevel plugability between application servers and EISs, the connector architecture defines a standard set of system-level contracts between an application server and EIS. Consider resource adapter as a system-level software driver that is used by the application server or application client to connect to an EIS. These contracts stipulate how an external system can access this EIS driver for integration.

Enterprise Application Integration There are three system contracts defined in the specification. They are related to Connection
J2EE Application Server

Management, Transaction Management, and Security.

Container Componenent Container

Application Client

Connection Manager System Contracts Resource Adapter Transaction Manager

Security Manager

Enterprise Information System

Figure 4: System Contracts

Connection Management The Connection Management contract allows applications to connect to an EIS. Applications use a Connection Factory to access the connection instance, which the application component uses to connect to the underlying EIS. Connection pooling manages connections that are expensive to create and destroy. Connection pooling of expensive connections leads to better scalability and performance in an operational environment. The connection management contract provides support for connection pooling. This leads to a scalable application environment that can support a large number of clients requiring access to EISs. JCA specs 1.0 says the connection management contracts must be implemented in any JCA resource adapter. Transaction Management A Transaction Management contract between the transaction manager and an EIS supports transactional access to EIS resource managers. This contract enables an application server to use a transaction manager to manage transactions across multiple resource managers. This contract also supports transactions that are managed internal to an EIS resource manager without the necessity of involving an external transaction manager. As per the specification, the implementation of transaction

contract is optional and is only needed if the adapter has to support it. Security A Security contract enables secure access to an EIS. This contract provides support for a secure application environment that reduces security threats to the EIS and protects valuable information resources managed by the EIS. Again, this is also an optional contract.

Client API and Container - Component Contract Some components are deployed in the application server environment, which define the workflow, and are end users for the JCA resource adapter. The contracts between these components and the application server are called Container-Component contracts. The client API used by the application component for EIS access may be defined in terms of: The standard Common Client Interface (CCI) A client API specific to the type of a resource adapter and its underlying EIS. An example is JDBC for relational databases.

CCI defines a common client API for accessing EISs. The CCI is targeted towards EAI and enterprise tools vendors.

Enterprise Application Integration can be imported and loaded into an application server, which hosts those Server components. JCA for Integration JCA has a major role to play in J2EE-based integration. One side of the JCA adapter, which may be considered as part of the J2EE container (application server) is standardized. Therefore, anybody can access it without knowing the implementation details. The other side of the adapter implementation is EIS-specific and uses technologies such as JNI and CORBA. The proprietary APIs of the EIS are used to communicate with the EIS. For example, if the EIS is a legacy system, we have to live with the interface that the system exposes. EJB architecture provides an integrated application framework that dramatically simplifies the process of developing enterprise-class application systems. An EJB server automatically manages a number of tricky middleware services on behalf of the application components. EJB component-builders can concentrate on writing business logic rather than complex middleware. The results are that applications get developed more quickly and the code is of better quality. The EJB model supports a number of implicit services, including lifecycle, state management, security, transactions, and persistence. Lifecycle: Individual enterprise beans do not have to explicitly manage process allocation, thread management, object activation, or object destruction. The EJB container (application server) automatically manages the object lifecycle on behalf of the enterprise bean. State Management: Individual enterprise beans do not have to explicitly save or restore conversational object state between method calls. The EJB container automatically manages object state on behalf of the enterprise bean. Security: Individual enterprise beans do not have to explicitly authenticate users or check authorization levels. The EJB container automatically performs all security checking on behalf of the enterprise bean. Transactions: Individual enterprise beans do not have to explicitly specify transaction demarcation code to participate in distributed transactions. The EJB container can automatically manage the start, enrollment, commitment, and rollback of transactions on behalf of the enterprise bean. Persistence: Individual enterprise beans do not need to explicitly retrieve or store persistent object data from a database. The EJB container can automatically manage persistent data on behalf of the enterprise bean.

EJB Overview
Enterprise Java Beans (EJB) is a server-side component architecture that simplifies the process of building enterprise-class distributed component application in Java. The EJB component model logically extends the Java Beans component model. The Java Beans component model defines a standard mechanism to develop portable, reusable Java technology development components, such as widgets or controls. A Java Bean is a specialized Java class that can be added to an application development project and then manipulated by the Java technology Integrated Development Environment (IDE). Multiple beans can be combined and interrelated to build Java applets or applications or to create new, more comprehensive or specialized Java Beans components.

EJB Architecture The Enterprise Java Beans component model logically extends the Java Beans component model to support server components. Server components are reusable, prepackaged pieces of application functionality that are designed to run in an application server. They can be combined with other components to create customized application systems. Server components are similar to development components, but they are generally larger-grained and more complete than development components. EJB components are deployable, and

Enterprise Application Integration Portability Layer The Enterprise Java Beans model defines the relationship between an enterprise bean component and an enterprise bean container (application server). Enterprise Java Beans components do not require the use of any specific container system. A vendor can adapt any application server to support Enterprise Java Beans technology by adding support for services defined in the specification. The services define a contract between an enterprise bean and the container, effectively implementing a portability layer. Any enterprise bean can run in any application server that supports the Enterprise Java Beans contracts. 2. The stub marshals parameters into a form suitable for the network. 3. The stub goes over a network connection to the skeleton. 4. The skeleton unmarshals parameters into a form suitable for Java. 5. The skeleton calls the EJB object. 6. The EJB object performs needed middleware, such as connection pooling, transactions, security, and lifecycle services. 7. When the EJB object calls the enterprise bean instance and the bean does its work, each of the preceding steps must be repeated for the return trip home. Figure 5 illustrates the process.

EJB Call Workflow 1. The client calls a local stub.

Client Code Senlet , JSP etc 5.Return Result

EJB Server/ Container

1. Call method

2. Call Server API EJB Interface Remote Interface 3. Call a Bean

Transaction Service, Security Service, Persistence Service,etc

4. Method Return Enterprise Java Bean

Figure 5: EJB Call Workflow

EJB and Interoperability EJB has adopted RMI-IIOP as the standard protocol for on-the-wire interoperability. Other protocols are permitted, but IIOP (Internet Inter ORB Protocol) is required for conformant EJB implementations to inter-operate. EJB inherits a significant benefit from RMI-IIOP. In RMI-IIOP, the physical location of the remote object that the client invokes is masked from it. This feature spills over to EJB. The client code is

unaware of whether the EJB object it is using is located on a machine next door, or a machine across the Internet. It also means the EJB object could be located on the same Java VM as the client. This is called location transparency. By using IIOP, enterprise beans can interoperate with native language clients and servers. IIOP allows easy integration between CORBA systems and EJB systems. Enterprise beans can access CORBA servers, and CORBA clients can access enterprise

10

Enterprise Application Integration beans. Using a COM/CORBA Internetworking service, ActiveX clients can also access enterprise beans and enterprise beans can access COM servers. Potentially, there could also be a DCOM implementation of Enterprise Java Beans technology. Message Driven Bean A Message Driven bean is a special EJB component that can receive JMS messages. A message-driven bean consumes messages from queues or topics that are sent by any valid JMS client. A Message Driven bean is de-coupled from any client that sends messages to it. A client cannot access the message driven bean through a component interface. JMS is the API to send message to Message Driven Bean.

Types of Beans Enterprise Java Beans technology supports three different kinds of beans. Session Beans Entity Beans Message Driven Bean

EJB for Integration In a scenario that deals with a legacy system that is critical to the business process, we have two basic choices: 1. Rewrite that existing system using EJB components. This option is the cleanest solution, but it requires the most effort. It may also be infeasible. Legacy systems tend to be complex. Developers who understand the legacy system may be difficult to find, and the time-to-market needs of the organization may not permit a rewrite. Finally, the performance of existing systems that use native code may not be acceptable in the Java world. 2. Bridge into that existing system. This is the most straightforward solution. However, you will have to maintain the bridged solution, which uses two different technologies. If you decide to bridge into existing systems, it is recommended to wrap the legacy system with an EJB layer rather than accessing it directly (from Servlets or JSP), because this abstraction layer will enable you to replace the legacy system in the future, if the need arises. The EJB layer could be Session beans, Entity beans, Message-Driven beans or all three. The choice of EJB components depends on the nature of your existing system. The next challenge is to actually achieve the bridge to the existing system. This implies reckoning what is happening inside the EJB layer that enables it to talk to the existing system. There are a number of solutions for this approach. Some of them are discussed below.

Session Beans A Session bean is created by a client and in most cases exists only for the duration of a single client/server session. A Session Bean performs operations on behalf of the client, such as accessing a database or performing calculations. Session beans can be transactional, but (normally) they are not recoverable following a system crash. Session beans can be stateless, or they can maintain a conversational state across methods and transactions. The container (application server) manages the conversational state of a session bean if it needs to be evicted from memory. A session bean must manage its own persistent data. Entity Beans An Entity bean is an object representation of persistent data maintained in a permanent data store, such as a database. A primary key identifies each instance of an entity bean. Entity beans can be created either by inserting data directly into the database or by creating an object (using an object factory Create method). Entity beans are transactional and they are recoverable following a system crash. They can manage their own persistence or delegate persistence services to their container (application server). If it delegates persistence to the container, then the container automatically performs all data retrieval and storage operations on behalf of the bean.

11

Enterprise Application Integration difference between CORBA and EJB/J2EE is that CORBA is language-neutral, while EJB/J2EE is specific to Java. Although CORBA has this advantage over EJB/J2EE, it has very little industry momentum behind it and is more appropriate as a technology for performing integration with existing systems. You can bridge into code written in almost any language by calling that legacy system via CORBA APIs from within your EJB layer. This is highly appropriate for existing systems that are already CORBA-based. The disadvantage of CORBA integration is that it requires an out-of-process remote call, which slows performance. Also, it requires learning a whole new technology if the language is not known. Java Message Service (JMS) JMS along with Message Driven Beans enables you to bridge to existing systems using messageoriented middleware. Messages are sent to existing systems rather than invoking them directly through API calls. This is a bit slower, but it also is a loosely coupled paradigm that enables you to build complex messaging workflows. JMS is highly appropriate if the existing system already uses messaging. Figure 6 illustrates an integrated EAI with CORBA, EJB and JCA.

Proprietary Bridges You can buy an off-the-shelf bridge that connects to a specific legacy system, perhaps an EJB-COM bridge or a container-provided API. The disadvantage of these proprietary bridges is a loss of portability, as there is no guarantee that this code will run in other J2EE-compliant servers. The Java Native Interface (JNI) JNI enables Java to bridge into native code such as C/C++ code. The advantage of JNI is that it is faster than the other approaches. The disadvantages are that it cannot connect to any system such as a Legacy system. The existing system has to run inprocess and JNI is platform-specific. Therefore, if the code has to run on multiple platforms, the testing and maintenance effort gets multiplied as well. CORBA CORBA is an older middleware technology that competes with EJB as it has its own component architecture. Also, it underlies EJB as some J2EE servers are old CORBA products wearing a new hat. The big

12

Enterprise Application Integration

Client Applications

Business Partner or Other Systems

Applets Applications, CORBA Clients

iMac

Web Technology Services

IIOP Firewall

Servlets

JSPs

J2EE Server

EJBs

JCA

JMS

SQL

Proprietary Protocol Existing System. ERP System

Web Services Technology Business Partner or Other Systems

Back End Systems

MessageBased System

Databases

Figure 6: An integrated EAI System

Web Services Web services (essentially XML/HTTP) provide an attractive approach to integrating to existing systems. Youcan use XML to represent the data sent to existing systems. HTTP is your transport and it allows you to navigate firewalls easily. This is a nonintrusive approach because any system that is Internet-enabled can use Web services without requiring a separate communications infrastructure, such as CORBA or JMS. The disadvantage of Web services is that the XML parsing overhead may slow the processing.

Web Services Overview

Web Services are the next stage of evolution for ebusiness. They view everything as a service that can be dynamically discovered and orchestrated using messaging on the network. Enterprises can dynamically sell their services to others by publishing their Web Services. The key to reaching this new horizon is a common program-to-program communication model, built on existing and emerging standards such as HTTP, Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI). Web Services allow applications to be integrated more rapidly, easily and less expensively than ever before. Integration occurs at a higher level in the protocol stack, based on messages centered more on service semantics and less on network protocol

JCA JCA is a specification that enables you to acquire drivers that connect with existing systems and plug them into the J2EE server to connect to a legacy system. You can connect to any existing system for which drivers exist. You can write your own driver if no driver exists. One such example is a proprietary internal system built in-house.

13

Enterprise Application Integration semantics, thus enabling loose integration of business function across the Web between, and within enterprises. They provide a unifying programming model so that application integration inside and outside the enterprise can be done with a common approach, leveraging a common infrastructure. The integration and application of Web Services can be done in an incremental manner, using existing languages and platforms and by adopting existing legacy applications. Moreover, Web Services compliment J2EE, CORBA, and other standards for integration with more tightly-coupled distributed and non-distributed applications. Web Services are a technology for deploying and providing access to business functions over the web. WSDL: Used to describe a web service SOAP: Used to call a web service (XML/HTTP) (eb)XML: Used to conduct complex business conversations and flow on the top of SOAP

The Web Services Model

Web Services Architecture

Web Services are functions published over the web. The following technologies are used to access these functions from remote applications: UDDI: Used to lookup a web service

The Web Services architecture is based on the interactions between three roles: service provider, service registry, and service requestor. The interactions involve Publish, Find and Bind operations. The service provider defines a service description for the Web service and publishes it to a service requestor or service registry. The service requestor uses a find operation to retrieve the service description locally, or from the service registry, and uses the service description to bind with the service provider and invoke or interact with the web service implementation. Figure 7 illustrates these operations, the components that provide them, and their interactions.

2.Service Discovery

Services Registry

1.Publish

Service Requestor 3.Service Invocation

Service Provider

Figure 7: Web Services Model

Components in Web Services Service Provider: From a business perspective, this is the owner of the service. From an architecture perspective, this is the platform that hosts access to the service.

Service Requestor: From a business perspective, this is the business that requires certain functions to be satisfied. From architectural perspective, this is the application that is looking for and invoking or initiating an interaction with a service. Service Registry: This is a searchable registry of service descriptions where service providers publish

14

Enterprise Application Integration their service descriptions. Service requestors find services and obtain binding information for services. systems use proprietary implementations, often because of the lack of open standards at the time of development. However, the business processes these earlier-generation proprietary applications support will continue to be necessary in the future. This can be credited to the significant investments that have been made into these e-business applications. These legacy applications are more complex than you may expect in the first place. For example, a Value Added Tax (VAT) calculation - similar to sales tax calculation in the US - becomes much more complex if it supports trade situations around the globe with all the different conditions that have to be handled. To enable legacy applications to participate in dynamic e-business, we have to apply Web Service technologies, which will allow the services to be defined so as to hide some of the complexity of the legacy application interface. Once the applications have been technically adapted, the business processes are likely to evolve to a more automated business process with reduced human intervention. The concept of Web services, together with the Service Oriented Architecture (SOA) approach, creates an opportunity for legacy applications to be made available for the Web. Here, we will show how a conceptual architecture can be applied to many of today's legacy applications running on mainframes and other servers. This includes applications under the control of mainframe transactions managers, that is, the Customer Information Control System Transaction Server (CICSTS) or Information Management System (IMS). The next figure shows the structure of this architecture.

Operations in Web Services

For an application to take advantage of Web Services, three behaviors must take place: publication of service descriptions, lookup or finding of service descriptions and binding or invoking of services based on the services description. These behaviors can occur singly or iteratively. Publish: To be accessible, a service description has to be published so that the service requestor can find it. Find: In the Find operation, the service requestor retrieves a service description directly, or queries the service registry for the type of service required. Bind: In the Bind operation, the service requestor invokes or initiates an interaction with the service at runtime using binding details in the service description to locate, contact and invoke the service.

Web Services for Integration The Web Services Architecture (WSA) is an ideal technology to incorporate enterprise legacy applications into this new area. This is the next step in creating a Web-based interface that interacts with an enterprise application in order to enable program-to-program communication. This implies doing the same business in a more automated fashion and with a more efficient approach. As the beginnings of e-commerce, many applications have been developed to support the growing demand of online shopping systems. Many of the

15

Enterprise Application Integration

UDDI Registry Service Discovery Publish Integration Broker

Service Requestor

Web Server

SOAP Router

Web Service

Adapter Lagacy System

Application Server

System 1

System 2

System 3

Figure 8: Information Management System

single point of failure that ensures this level of availability. Web Services Advantages The advantages of a Web Service are listed below. It can make proven production level applications available as Web services. This allows for rapid deployment of stable Web services to customers of a Web service provider. The high investment in large legacy applications is preserved for users of the Web service, while still available unchanged as a server application on the mainframe host. It can leverage the advantages of running mainframe-based applications for Web users, such as:

Continuous Operation: Mainframes can allow for scheduled system outages for software or hardware upgrades without any interruption to applications running on the cluster. Additional systems can be brought in without any interruption to the operation.

eXtensible Markup Language (XML) Overview

XML is an open and flexible standard for storing and exchanging information between enterprise applications and between businesses. Applications have always been able to store situation-specific data in file artifacts to be substituted and called upon for action as the user or the process demands. Over the years there have been significant improvements in compression, computing languages and application functionality. Vendors have implemented ever-more complex formats. The lack of interoperability between file formats has been the bane of enterprises since the advent of the second application ever written. The problem is that

High Scalability: The number of potential users for a Web service often cannot be determined when the service is started. A mainframe such as the zSeries Parallel Sysplex cluster-based service is dynamically managed by the Workload Manager (WLM) and can scale to a very high degree. High Availability: Web services must be accessible for Business-to-Consumer (B2C) and Business-to-Business (B2B) users with 99.99% availability at 24x7x365. A mainframe cluster can be set up with no

16

Enterprise Application Integration of getting the right context, and not just getting the correct data elements. For example, a customer record in a typical file or relational database record might look like the following one: Separated from the data logic, this file only contains 71 characters, but we can easily confuse first name with last name, city with streets, and telephone with fax numbers. Efficiency in the past was more important than interoperability. With XML, the context or meaning of the data is stored along with the data. Though it takes more characters to convey the same, the resulting output is clearer and more comprehensible. The receiving application can no longer be confused about the details of the individual.

Figure 10: XML file with context included

Data Exchange Without Complicated Contraptions XML provides a generalized mechanism for representing and structuring data. It is in fact a meta-language, which implies that it can be used to define any set of constructs and therefore is inherently extensible. As a result, XML provides a mechanism for dealing with the formatting of information for display as Web pages as HTML does. Also it provides a flexible framework for representing the structured data associated with databases and application systems. Therefore, any data structure can be rendered as an XML document. In its earliest applications, XML provided a more powerful HTML for interfacing structured data with Web-based applications. Today it has also emerged as a powerful and flexible vehicle for storing, manipulating and exchanging data of all types across systems and technologies. Defining Data Structure and Meaning The power of XML lies in its ability to represent the data itself - and to define its structure and meaning. XML relies on extensible tags to describe data structures and formats. Using XML, an organization can specify a vocabulary of data elements in, say, a customer processing application, such as the customer's name, street address, city/state/zip, phone number and customer number. Different applications can then identify that data, interpret its attributes and use it appropriately. The meaning is derived from agreement on a specific XML schema or Document Type Definition (DTD) in earlier XML specifications. A schema describes the vocabulary and the syntax of a specific

Figure 9: Non-XML file with no context

Figure 9 depicts a typical non-XML file that has no context. A look at this file, shows that XML is considerably more verbose than the no-context example above. The file grew to 307 characters, which implies a 450% increase. This may seem inordinate when compared to the industry priorities two decades ago, but in todays information economy, processing power, compression technologies and bandwidth are all plentiful, inexpensive and high performance. The expensive resource is now human resource. Today, the increase in automatic interoperability is worth more than message efficiency. XML for Integration EAI as explained before is the integration of data, applications and processes across multiple functions and companies. It requires both an infrastructure for integrating applications and a standards-based mechanism for creating portable data. For an increasing number of companies, that mechanism is XML. Figure 10 depicts a typical XML file that has an integrated context.

17

Enterprise Application Integration type of XML document; it provides a distinct definition of a set of tags appropriate to a specific application area. However, just as with a language vocabulary, it also implies agreement on the meaning that should be associated with the tags. For example, in a payments system, it should be agreed that <Total> represents a monetary amount in a particular currency. the application programming effort and in its seamless integration with XML. XML promises to achieve for structured information what HTML achieved for text and graphics on the Web. First, XML is rapidly emerging as the preferred data integration backbone both within and across organizations and industries. Second, XML, in conjunction with HTTP, provides for customized delivery of information to the browser, a prerequisite for compelling customer-oriented applications. XML also eliminates the need for custom adapters when integrating packaged applications. In fact, when coupled with HTTP, XML becomes a ubiquitous middleware solution that lends itself to the loosely coupled style of integration required by B2B solutions. In addition, XML is increasingly being supported by other message transports, such as MQSeries. Major application vendors, including SAP, Oracle and Siebel, are adding XML-based application program interfaces to their application suites and that a third-party market for XML-based adapters for popular applications is rapidly emerging. Figure 11 depicts an XML-based application.

Data Transformation and Manipulation The power of XML is complemented by its eXtensible Stylesheet Language (XSL). More specifically, eXtensible Stylesheet Language Transformations (XSLT) provides a standards-based data transformation capability and is the ideal vehicle for the data manipulation requirements of EAI. Data transformation is a critical component of EAI, as it allows data from one application to be transformed for use in another application. The classic transformation problem occurs, for example, when one application requires age as input data, while another can only supply date of birth .Getting from date of birth to age requires not only the resolution of different meanings and different data formats but perhaps some computation as well. The advantages of employing XSLT for transformation lie in the clear separation of transformation rules from

Web Application

XML Mesage

xxxx xx xxxxx

XML Message

XML Formatted SQL Queries

xxxx xxxx xxxxx

xxxx xxx xx

Message Broker Accounting

Database

Figure 11: XML-based application

18

Enterprise Application Integration New World of Vocabularies XML has shown great promise in defining XML vocabularies for particular industries. These vocabularies define a set of elements and describe where they go in the document structure. Both the automobile industry and the health-care industry are prominent players in the new world of XML vocabularies. Examples of such vocabularies are Extensible Business Reporting Language (XBRL) and Electronic Business extensible Markup Language (ebXML). Such vocabularies can define industry-specific information interchange and even transformation characteristics. As a result, within a given industry data-exchange solutions can be used. This includes metadata and behavior. Here lies the future of information exchange: the ability to leverage existing best-practice integration solutions in the same way packaged applications have been leveraged. communications including publish/subscribe, request/reply, broadcast, multicast, and Pragmatic General Multicast (PGM). TIBCO solutions offer a range of options for quality of service including reliable, guaranteed, certified, transactional, and encrypted. They support the distribution of information over both local and wide area networks. TIBCO family consists of many products. Some of them are TIBCO Rendezvous, TIBCO Repository, TIBCO Message Broker, and TIBCO Adapters. Each component has a role to play in a typical integration scenario. This whitepaper discusses the prime member of the TIBCO family - TIB/Rendezvous in detail. Detailed discussions of other TIBCO products are out of scope of this document. TIBCO Rendezvous TIBCO has a number of solutions for messaging. The important ones are TIBCO Rendezvous and TIBCO Enterprise for JMS. TIBCO Rendezvous is the messaging system that is the foundation of TIBCO ActiveEnterprise, TIBCOs line of e-business infrastructure products. Rendezvous has a wide customer base and is rapidly emerging as a standard for enabling the mission-critical real-time messaging required for robust e-business infrastructures. TIB/Rendezvous software makes it easy to create distributed applications that exchange data across a network. TIB/ Rendezvous software supports many hardware and software platforms, so programs running on many different kinds of computers on a network can communicate seamlessly. From the programmers perspective, the TIB/Rendezvous software suite includes two main components: TIB/Rendezvous programming language interface (API) and TIB/Rendezvous daemon (rvd).

Third Party Solutions

TIBCO Messaging Solutions
The foundation of business integration is the movement of information between distributed systems. There are many ways of doing this, including application-specific APIs and RPCs, technologies such as COM and CORBA. More recent standards include J2EE and Web Services. TIBCO Software Inc. is an integration vendor that provides comprehensive support for all of these technologies. TIBCO provides messaging solutions based on their patented distributed architecture, server-and queue-based architectures and Java. This complete set of solutions enables virtually every conceivable type of synchronous and asynchronous

Figure 12 details the TIBCO architecture.

19

Enterprise Application Integration

A
Program TIB/Rendezvous API

B
Program TIB/Rendezvous API

C
Program TIB/Rendezvous API

TIB/Rendezvous Daemon

TIB/Rendezvous Daemon

Computer 1 Network

Com puter 2

Figure 12: TIBCO Rendezvous Architecture

Rendezvous (TIB/RV) supports both point-to-point messaging as well as multicast messaging. TIB/RV programs uses subject-based addressing to communicate with each other. Subject-based addressing technology helps messages reach their destinations without involving programmers in the details of network addresses, protocols, hardware and operating system differences, ports and sockets. Subject-based addressing conventions define a simple, uniform name space for messages and their destinations. Each TIB/RV message bears a subject name, which simultaneously specifies a delivery mode and the destination of the message. If the subject name is inbox then it will be a point-to-point message. Else, the message will be a multicast message. Communication between programs is also anonymous. The consumers need not know where or how data is produced and producers need not know where data is consumed nor how is it used. Producers and consumers only have to verify that: data items are labelled with the same set of subject names and the actual data is in a form that both can manipulate and interpret

processes, and the shifting of responsibilities among a collection of producer processes. Architecture As already said TIB/RV have two main components from programmers point of view. Each system, which is a part of messaging architecture, will have a Rendezvous daemon. The daemon is a background process that supports all Rendezvous communications. Distributed processes depend on it for reliable and efficient network communication. All information that travels between processes passes through a Rendezvous daemon as it enters a host computer or exits a sending process. The application programs will use the Rendezvous programming language interface (API) to communicate with the TIB/RV daemon, which is the message bus. As shown in the following figure if computer 1 and computer 2 have to communicate with each other using TIBCO Rendezvous, then each system should have a daemon running on them. The interface between the daemon and the respective applications on each system will be the Rendezvous APIs. The main functionality of the Rendezvous daemon are given below. A Rendezvous daemon: transmits outbound messages from program processes to the network,

Anonymous communication decouples data consumers from data producers. Consumers are insulated from most changes in data producing software, including the replacement of producer

20

Enterprise Application Integration delivers inbound messages from the network to program processes, filters subject-addressed messages, shields programs from operating system idiosyncrasies, such as low-level sockets. with a different inbound message. Each time the callback function runs, it receives an inbound message as an argument. The callback function must process the message in an appropriate application-specific fashion. The software mechanism for sending and delivering messages is called a transport. A transport defines the delivery scope-that is, the set of possible destinations for the messages it sends. Programs use transport objects to send messages and listen for messages. A transport determines three aspects of message delivery: Delivery scope-the potential range of its messages Delivery mechanism-the path (including software, hardware and network aspects) that its messages travel Delivery protocol-the ways in which programs cooperate and share information concerning message delivery

Message Structure Rendezvous messages carry data among program threads or processes. Messages contain selfdescribing data fields. Programs can always manipulate message fields, send messages and receive messages. Each field will have certain components such as: data, type of the data like integer or string, the size, which represents the number of bytes that the data occupies, name - subject name or the field name, identifier - an optional integer that uniquely identifies a field within a message and count - the number of elements in an array data type.

Rendezvous software uses this descriptive information between sender and listener to automatically convert messages between the local data format and Rendezvous wire format. Rendezvous wire format is a universal format that is independent of hardware, operating system, and programming language architectures. The universal wire format provides a common language to connect diverse programs. Rendezvous software encourages an event-driven programming paradigm. Program callback functions respond to asynchronous events, such as an inbound message or a timer event. The arrival of an inbound message is an important event for most Rendezvous programs. It is also an instructive exemplar of an asynchronous event. The receiving program cannot know in advance when a particular message might arrive in the queue. To receive messages, programs create listener events, define callback functions to process the inbound messages, and dispatch events in a loop. While a program is listening for messages, the event driver queues the listener event each time a message arrives with a matching subject name. Each appearance of the event in the queue leads to a separate invocation of its callback function. At any moment in time, an event queue can contain several references to the same listener event object-each reference paired

Various types of transport object combine these aspects to yield different qualities of service-for example, intra-process delivery, and network delivery, reliable delivery, certified delivery, and distributed queue delivery. Reliability and Certified Message Delivery Standard multicast and broadcast protocols are not reliable and are unable to detect lost messages. Under normal conditions, Rendezvous reliable multicast protocols ensure that all operational hosts either receive each multicast message or detect the loss of a message. Reliable delivery compensates for brief network failures. The receiving Rendezvous daemon detects missing packets and requests that the sending daemon retransmit them. The sending daemon stores outbound messages for a limited period of time (60 seconds), so it can retransmit the information upon request. It discards old messages after the time period elapses, and cannot retransmit after that time. The Rendezvous daemon does not guarantee delivery to components that fail and do not recover for periods exceeding 60 seconds. Although Rendezvous communications are highly reliable, some programs require even stronger assurances of delivery. Certified delivery features offer greater certainty of delivery-even in situations where processes and their network connections are

21

Enterprise Application Integration unstable. Certified message delivery is achieved using a CM transport object. Advantages of TIB/Rendezvous TIBCO Rendezvous uses a distributed architecture to eliminate bottlenecks and single points of failure. Applications can select from several qualities of service including reliable, certified and transactional, as appropriate for each interaction. Messaging can be request/reply or publish/subscribe, synchronous or asynchronous, locally delivered or sent via WAN or the Internet. Rendezvous messages are selfdescribing and platform independent, with a userextensible type system that provides support for data formats such as XML. Also it is available on platforms ranging from desktop PCs running Windows to mainframes running OS/ 390. See our Web site for specific details. Rendezvous APIs are available in Java, C, C++, Perl and COM. Such a wide range of APIs will ease the job of a system integrator. But the main disadvantage is for additional features customer has to pay more and get additional components. Rendezvous Routing Daemon TIBCO Rendezvous daemon delivers messages to programs on computers within a single network. Delivering messages beyond network boundaries requires additional software component-Rendezvous routing daemons. Routing daemons efficiently connect Rendezvous programs on separate IP networks, so that messages flow between them as if on a single network. Communicating programs remain decoupled from inter-network addresses and other details. The routing daemons forward Rendezvous messages between networks. When routing daemons are present, Rendezvous programs on one network can listen for subject names and receive messages from other networks transparently- neither the sending nor the receiving programs require any code changes. Administrators retain control over the subject names that can flow in or out of each network. Routing daemon software uses a routing table to define connections to local networks, and to other routing daemons. While routing, hardware specifies its local networks primarily in terms of network interfaces, routing daemon software specifies each local network as a pair combining network and UDP or PGM service. UDP or PGM services effectively divide the physical network into separate logical networks-even though they use the same hardware. Moreover the routing daemon can provide all the functionality of a Rendezvous daemon in the system it resides. TIBCO Rendezvous TX This is an add-on product to TIB/RV that extends Rendezvous messaging product, adding two qualities of service enhancements: atomic transactions and guaranteed message delivery

Transactions work well to synchronize operations within a localized environment. For example, when the transaction remains within the control of one process, and involves resources within a local network. However, when long distances intervene or communications are unreliable, synchronization becomes difficult. To overcome this difficulty, Rendezvous TX combines two complementary technologies-transactions and messages. In many applications, when synchrony is not achieved, you can substitute guaranteed messages in place of absolute synchrony. TX messages decouple components with respect to time and space, without sacrificing certainty. The message will eventually arrive at its destination, and the receiver will take appropriate and effective action in response. For example, program A uses a transaction to synchronize several database operations with a message send operation. At a distant site, program B uses a transaction to synchronize the receipt of that message with several operations involving a different database. Although A and B cannot synchronize their database operations with one another, their operations are linked by the message, which is guaranteed to arrive. In a programmatic manner the Rendezvous TX APIs will reside above the Rendezvous APIs and the program will interact with TX APIs. TIBCO Rendezvous Data Security This is another add-on component for TIBCO Rendezvous that implements a secure communications protocol for Rendezvous applications. The data security component consists of two components: APIs that resides top of Rendezvous APIs in a program Access Control List Daemon that sits in a centralized server Host

Data Security software features a compact API that hides most cryptographic details from application

22

Enterprise Application Integration programmers. Programmers focus on application domain issues, while the security officer determines cryptographic requirements and user privileges. Programs can secure (encrypt) and clear (decrypt) TIB/Rendezvous data messages. Programs can also do these operations implicitly, by sending and receiving messages through a secure transport. This feature speeds migration of existing TIB/Rendezvous (Release 6.6 or later) programs to use Data Security functionality. Data Security software automatically attends to all cryptographic computations, including verification of digital signatures and identity certificates. The Access Control List Daemon (rvacld) is a server process that distributes security information to user programs. The security officer controls the security architecture and all security decisions through a database attached to this central server. TIBCO Repository TIBCO Repository stores configuration data and metadata, but is not a general-purpose data store. TIB/Repository shares common information among different ActiveEnterprise components, thus providing customers with a unified view of their enterprise. It also stores private configuration data so that a single instance's configuration can be accessed from anywhere within the network. TIB/Repository lets the user to create and manage repositories. To add or change repository content, the TIB/Adapter Administrator tool has to be used. A repository instance is a named collection of data, usually metadata and configuration data that is persistently stored. A repository instance is called a local repository instance when it is stored on the local file system and directly accessed by the client. A repository instance is called a remote repository instance when it is managed by a repository server and accessed by a client using TIB/Rendezvous. Repository clients are applications that use the TIB/Repository client library to manage repository instance data. A client can manage local or remote repository instances. Examples of applications that use the TIB/Repository client library to become TIB/Repository clients are TIB/Adapter SDK adapters, TIB/MessageBroker, TIB/Adapter Administrator and TIB/IntegrationManager. Clients access repositories locally or remotely. A local repository is always a file that is accessed directly. A remote repository requires a repository server that manages repository instances. The server uses TIB/Rendezvous software to communicate with remote clients. A repository network consists of a repository server and remote client(s) that can communicate with it using TIB/Rendezvous messaging. For a client and server to be part of the same repository network, they must have the same TIB/Rendezvous transport configuration of service, network, and daemon. TIBCO Message Broker TIB/MessageBroker is a sophisticated transformation, routing and rules-processing system. Designed to simplify the process of sending and receiving messages across disparate distributed applications, TIB/MessageBroker makes the differences among enterprise applications transparent by mapping, transforming, validating and routing data according to defined rules. TIB/MessageBroker is integrated into the TIBCO ActiveEnterprise real-time enterprise application integration platform. Using TIB/MessageBroker, messages can be transformed where input and output messages use different transport protocols and different wire formats. Messages can be routed based on message content resulting in tightly integrated content-based routing functionality. The central component in TIB/MessageBroker is the MessageBroker Engine, which supports standard objects known as plugins that connect to a transport to get and send messages. Predefined plugins are available for TIBCO transports such as TIB/Rendezvous, persistent stores such as file or database, and Internet transports such as HTTP, FTP, POP and SMTP. In addition, a large set of predefined functions is available. Because the predefined plugins and functions are built using the TIB/MessageBroker Java API, custom plugins and functions can be easily created and made available in TIB/MessageBroker.

Integration Scenario - Business Requirement

The Business requirement is to provide a unified approach to the customer to handle all their application security requirements necessitated by the OSS/BSS system. This necessitates designing, developing and managing the entire OSS/BSS system. The system encompasses implementing technology solutions to all business processes including Marketing, Sales, Service Provisioning,

23

Enterprise Application Integration Customer Care, Billing, Service Assurance and analysis using Data Warehousing and Data Mining. The end user of the solution is a leading Telecom Service provider and is in the business of providing broadband services, fixed line, and Mobile telephony service. Business Solution The solution includes integration of innovative processes and technologies within the solution and to present a single sign on to the entire set of heterogeneous applications used for Billing and Customer Care, Service provisioning, Service assurance, Order Management and Decision Support System The solution provides integration of the following systems e) f) a) b) c) d) Billing and Customer Care System Order and workflow management System ( Wisor) Line Plant management System (A Network Inventory elements management system) Service Provisioning and Service Assurance System (HSS BMS-SPP) Network Elements (MSC, HLR) Decisions Support System (HSS DSS solution, Informix Data mining solution). Figure 13 illustrates an integration model in a business scenario.

LP & M BCC OMW Administrator Administrator Administrator 1

Customer Service Representative DSS User HTTP

Network Element

Mediation Line Plant Order Billing and and Management and Inventory Customer Provisioning and Workflow Management Care 6 2 3 5 7 4 7 3 5 4 2 6

Decision Support System

Database Database

Integration Broker
Business Rules

Figure 13: Integration Model

The integration flow between various systems can be understood in the following steps: 1. A customer walks in and his demographic profile and service details are first captured by the CSR using the Billing and Customer Care system clients.

2. The Billing and Customer Care system updates its database with the details and notifies the Order management and workflow management system about the new customer for further processing. 3. The workflow management system creates an order for the new subscriber updates its database with the subscriber details and notifies

24

Enterprise Application Integration the Line plant management system for further processing. 4. The Line plant management system check its inventory, and network capacity and service assurance capabilities and executes the order and notifies back to the work flow management system about its completion. In addition to this, the Line Plant system captures the entire external plant network of Client on a digital map of the city, facilitating the management of the network to be visualized on a desktop by the authorities concerned. 5. The Order and workflow management system receives the message of the completion order from the Line plant updates its databases and send the details to the Billing System 6. The Billing systems receives the request from the Work flow management system updates the data in it to the database and send service provisioning messages to the Service provisioning and Assurance system (Mediation) 7. The Mediation system send a provisioning messages to the NEs elements based on the customer numbering profiles and based on the response from the NE sends back the positive/negative messages to the Billing system. 8. The billing system records the message in the database and sends a response back to the Workflow management system indication the completion of the whole process. 9. The Billing System also notifies the CSR about the completion of the completed order. 10. From time to time historical data are transferred from the billing system / Work flow management system and Line Plant management system to the Decisions support systems for data mining and reporting Table 1 describes the billing process.

Table 1: Billing System Process

Step 1

Source Customer Service Representative

Destination Billing and Customer Care (BCC)

Description A customer walks in to the CSR and places an Order. CSR Client will contact the BCC to place the order BCC will pass on the order to Order Management System Order Management System will push the details to the Line plant inventory management system to check the status of network availability and for Number provisioning. Line Plant Inventory Management system will update the Order Management system about the status of the availability.. If the Order can be serviced immediately, the Order management System will convey a positive message to BCC. Else it will send back a status. In case of a positive message from Order Management, the

2 3

Billing and Customer Care Order Management and Work flow

Order Management and Work flow Line Plant and Inventory Management

Line Plant and Inventory Management

Order Management and Work flow

Order Management and Work flow

Billing and Customer Care

Billing and Customer Care

Mediation and Provisioning

25

Enterprise Application Integration

Step

Source

Destination

Description BCC will ask the Mediation and Provisioning System to provide the network elements required for the service.

Mediation and Provisioning

Billing and Customer Care

Mediation and Provisioning system will notify the BCC about the status after sending a provisioning message to network elements. The BCC will convey the CSR about the result of the order placed, which will be finally conveyed to the end customer.

Billing and Customer Care

Customer Service Representative

Benefits to the Customer The total solution offers a single security umbrella enforcing a centralized application security policy across the entire portal through single sign on feature. This implies a heavy reduction of administration costs to the customer. The customer can achieve high amount of cost saving as the necessity of increased help desk personnel is removed. The productivity of every end user is enhanced through single sign on, as the amount of time taken to log into each application is saved. This also removes the associated login problems to each application. The centralized user-provisioning feature results in reduction of manual intervention for updating user profile in each application. The automatic bidirectional synchronization of user profile updates enable the administrators and the organization to maintain data integrity as well as achieve high amount of cost saving through reduced administration activities. This also results in operational efficiency at different levels of the organization. Finally, the customer achieves an extended Unified security model for all the existing and future applications and value-added services.

Integration Scenario Technical Solutions

This section of white paper discusses the different solutions for the integration case study explained above. All the integration solutions are based on the Message Oriented Middleware (MOM) architecture. In the first two solutions the MOM is JMS and in the 3rd one it is TIBCO based solution. Solution 1 In this solution architecture the MOM is JMS (Java Messaging Service) based and the Billing and Customer Care (BCC) component used is Geneva. A small description of the Systems involved in this integration scenario is provided. Billing and Customer Care - Geneva In this integration case study the end customer or the CSR contacts directly to the BCC. Here the BCC component is Geneva. The Convergys Geneva software is a real-time, transaction-based, product that can rate and bill for any servicewhatever the delivery network is. By focusing on the customer account across any combination of services, Geneva software provides true convergent billing. Geneva is an open system that provides public interfaces to its functionality to allow communication with external systems. Geneva provides different types of APIs depending upon the complexities of integration required. At the lowest level, Geneva provides a fully documented public schema. This provides read only access to all Geneva tables for reporting

26

Enterprise Application Integration and analysis. The Geneva data model is extremely generalized and normalized. Consequently, in addition, a large number of higher-level views are also provided, making reporting and data extract even easier. At the middle level, Geneva provides a comprehensive set of Oracle SQL-stored procedures. Any Oracle enabled application can update Geneva directly in a controlled fashion, without the need for language specific wrappers. Geneva stored procedure APIs provide access to complex data structures in a controlled and easily understood way. Access to Oracle stored procedures is available from customer care packages and all modern development languages through JDBC, ODBC, BDE and Oracle interfaces. Geneva also supports a file-based interface. Any files that are passed to Geneva from outside must be presented in a formal way, which allows them to be registered into the managed environment. For this Geneva defines file formats for importing and exporting files, a protocol for file import and export and a proprietary mechanism for importing and exporting files. Geneva transfers files in groups. Each group of files is transferred as a single unit and the transfer of the files either entirely succeeds or entirely fails and has to be done again. A control file that lists all of the files to be transferred manages this process. The Geneva file-based interface is used to import event files, bills and bill data, bill insert files and a number of other high-volume Geneva entities. Order Management and Workflow Wisor Wisor Telecom is a provider for next generation OSS, Gateways and Testing Tools for communications services supporting order procurement, service inventory management and cost containment for Enterprise customers and Communications Carriers. Wisor Service Management Solution (SMS) enables consistent order processing using user-defined templates and process automation. Enterprises can manage and control service by ensuring accurate ordering and monitoring of service delivery across the entire order fulfillment lifecycle. SMS provides a comprehensive, corporate-wide service inventory of telecommunication services by suppliers, locations, and organizations. Wisor SMS Enterprise Edition is comprised of four major subsystems; Purchase Order Manager (POM), Procurement Process Manager (PPM), Service Inventory Management (SIM) and Business-to-Business interconnection Gateway subsystem referred to as the XML Gateway. Together, these components provide a comprehensive, and highly robust solution for enterprise telecommunications procurement needs. Wisor SMS provides a common published XML interface. Wisor can handle electronic ordering on trading partners using XML based EDI interface. Line Plant Inventory Management There is not much information is available about a Line plant Inventory Management system. For understanding purpose it is assumed that the system considered (Manipal Infodesk www.infodeskmanipal.com/) provides a file-based interface to the inventory data.
Mediation and Provisioning (HSS BMS-SPP)

BMS-SPP is a systematic software comprehension and mediation tool, which provides a mediation layer between various Network Elements (NEs) and their end users. BMS-SPP automates the service provisioning process. This helps network operators to efficiently manage and optimize the available resources for maximum throughput while minimizing the downtime. BMS-SPP can be rapidly integrated with an existing network set-up. The increasing complexity in networks requires the interchange and interplay of diverse networking technologies from multiple vendors to achieve enterprise-wide connectivity. It has been recognized that advanced network management technologies will be needed to further enhance and sustain the growth potential of networks. BMS-SPP performs processes that involve information conversion, translation and higher order protocol networking, which is included in the SPSM Module. BMS-SPP also performs processes that involve data handling, which is included in the CDR Collection Module. HSS BMS-SPP support the file based interfaces for external integration with other components. Provisional requests will be dumped into the mediation system as files. CDR collection is also file based. The latest release of BMS SPP scheduled for April-2003 will be supporting a telnet-based interface for provisioning purpose. The other possibility is about providing C/C++ interfaces so that seamless integration is possible with heterogeneous applications. JMS-based Integration solution In case of JMS based MOM architecture there is an application that sends and receives java messages. These messages are Java objects having a basic

27

Enterprise Application Integration format, simple but highly flexible. Java message objects help to create messages that match formats used by non-JMS applications on heterogeneous platforms. A JMS has three parts - header, properties and a body. The properties and body are optional. The integration bus in this solution architecture will be a J2EE compliant application server such as Bea Weblogic or JBOSS. This Application server will provide all the security and transactional support such as connection handling. As shown in Figure 14, each component/system that has to be integrated with another system using JMS must have a JMS driver. A JMS drive is a java program that helps this system to send and receive JMS messages. This JMS driver could be Enterprise Java Beans residing in the application server. As we are integrating heterogeneous enterprise systems, we need a common language to talk with each other. This language format is decided by the JMS message structure. Therefore, there must be a language translator for each system in the integration architecture. Here the data transferring module comes into the picture. As shown in the figure each system connected to the integration bus (Application server) should have a corresponding data transfer module. This also will be a set of Java classes has to be implemented by the system integrator. The prime job of these classes will be creating JMS messages from the proprietary data formats and converting JMS messages to the proprietary data formats. These classes normally reside in the application server itself. The third important component is an enterprise system specific adapter that does the direct interaction with the enterprise system. These adapters could be custom developed or the plug in components. A Java Connector Architecture (JCA) comes here.

Provisioning HSS BMSSPP

Customer Care Geneva

Workflow Wisor

Inventory Management

File Based Interface

Billing System Adapter Java API Object Marshalling & Unmarshalling JMS Driver Sends / Receives

Order Management Adaprer XML- Based APIs XML Data marshalling & Demarshalling JMS Driver Sends/ Receives

Line Plant & Inventory Adapter File-Based Interface File Reader & Writer Object Marshelling and Unmarshelling JMS Driver Sends/ Receives

JAVA Message Queues Or Topic ( Message BLB for Objects)

Integration Broker - J2EE Application Server Figure 14: JMS-Based Integration Scenario 1

In this specific case study, the integration bus connects three enterprise systems namely the Billing

28

Enterprise Application Integration and Customer Care, Order Management, and the Line plant Inventory System. Geneva provides Java and C++ API to access its stored procedures. As given in the picture an adapter for Geneva that is custom-developed has three components: 1. JMS Driver that is the messaging application 2. Data marshalling and un marshalling classes 3. Classes that interact with Geneva database using Java APIs provided by Geneva Geneva database is Oracle and the integration is done on the database. Communication between the Geneva system and the database is out of scope of this document. It is assumed that the changes in the database will be communicated to the integration broker using some triggers. Wisor Order Management System has got open XML APIs. So for integration purpose there will be three different components namely: 1. A JMS driver that has to be custom-developed 2. Java classes that creates messages from XML and converts messages to XML 3. JAVA XML API for interacting with the Wisor system. It can be JCA based) All these components have to be custom-developed as per the requirements. As per the understanding we are having the Line plant and Inventory management system exposes file-based API. To integrate this system using JMS integration broker, mainly 4 components are required: 1. A JMS driver for sending and receiving messages 2. Java classes for data transfer between message format and the proprietary data format 3. Java classes for creating files in the appropriate format and for reading from files created by the Line plant Inventory system. 4. An adapter that does the file importing and exporting with the Line Plant Inventory system. This can be JCA-based. All these four components must be customdeveloped by the system integrator. For better understanding we will discuss steps 2 and 3 of the work flow table here. In step 2 Billing and Customer Care passes the order to the Order management system after getting the requirements from the end customer. After the Order is placed in the Geneva database it sends some triggers to the data base clients. The adapter to the billing system identifies this trigger and create an Order message for the Order management system and send it to a JMS queue. The Order Management system, which is listening to messages for it, gets this message through its JMS driver and adapter. As shown in step 3 it pushes the details to the Line plant inventory management system. For this a message sends in XML format. The customdeveloped java classes will capture this with the help of adapter and construct a java message for the Line plant Inventory system. This message is sent to the Line plant inventory management system which is again a message listener in the Application servers JMS environment. The corresponding driver interprets the message and sends it finally in a file format to the Line plant Inventory management system using the adapter. The other steps can also be explained in similar manner. Integration between the billing system and the mediation and provisioning system is not through the Integration broker for this case study. Therefore, it is not discussed here. It will be a file-based interaction-using FTP. Solution 2 This solution architecture is also JMS-based MOM. The difference here is that the billing and customer care solution used is Portal Infranet. Rest of the components are the same. Therefore, here we will discuss how Geneva is replaced in the aforementioned solution architecture with minimum effort. A brief description of Portal Infranet is also provided. Portal Infranet Billing and Customer Care Solution Infranet is a customer management and billing system for IP and telecommunications service providers. Infranet integrates seamlessly with your services to provide customer registration, service provisioning, and authentication and authorization. It also provides features such as customer activity tracking, billing, account management, and data collection and reporting. Infranet manages all the external and internal activities by creating and storing events. Therefore, we can consider Infranet as an event-based system. External applications can

29

Enterprise Application Integration communicate with Infranet system managers using a rich set of client APIs exposed by the system. Infranet API that can be used by external applications to interact with the system is called PCM API. C, C++, JAVA and COM API are available. Using System APIs ( C API) provided by infranet it is possible to customize some of the core engine functionality. But Geneva does not have this feature. Applications do not have to interact with database as shown in the case of Geneva. The database interaction is the responsibility of the Intranet system. JMS-based Integration solution As shown in Figure 15 Geneva is replaced with Portal Infranet. Three components specific to infranet are required for integrating Infranet to other heterogeneous systems using JMS. Some examples of such systems are Wisor Order management system and the Line plant Inventory Management system. 1. A JMS driver to send and receive JMS messages to the message queue. It resides in a J2EE compliant application server. 2. A set of java classes that transfer data from JMS messages to the format that Infranet understands. This format is called storable classes. 3. An Infranet-specific adapter that does the actual interaction with Infranet. This can be JCA-based. All these components have to be custom-developed. HSS has already developed a prototype for JCAbased Infranet adapter. As explained for sending a message to the Order management system through the integration broker (Application Server), the Infranet billing system sends the message to its adapter. The adapter receives this message and converts it into JMS message format using a set of custom-developed classes. Finally this message is put into a queue in the application server. The Order management system receives the message from the queue and processes it as explained in the previous session. The advantage of this kind of architecture is the loosely coupling of the systems involved. Changing the billing system from Geneva to Portal Infranet does not affect the implementation of integration architecture for other systems involved. Custom development of a JMS driver is not a complex task. Communication between the billing system and the HSS BMS-SPP mediation system is file-based and must be done again for the new billing system, Infranet.

30

Enterprise Application Integration

Billing and Customer Care Infranet

Order Management & Workflow Wisor

Line Plant & Inventory Management

File Based Interface

Billing System Adapter Infranet API Object Marshalling & Unmarshalling JMS Driver Sends / Receives

Order Management Adapter XML Based APIs XML Data marshalling & Demarshalling JMS Driver Sends/ Receives

Line Plant & Inventory Adapter File Based Interface File Reader & Writer Object Marshelling and Unmarshelling JMS Driver Sends/ Receives

JAVA Message Queues Or Topic ( Message BLB for Objects)

Integration Broker - J2EE Application Server

Figure 15: JMS-Based Integration Scenario 2

Solution 3 This third solution for the above-described business integration case study is based on TIBCO Rendezvous MOM. TIBCO has a business integration platform called ActiveEnterprise, in which Rendezvous is the message broker. ActiveEnterprise enables the integration of applications using a simple configuration GUI instead of by hard-coding connections. In addition to packaged adapters for most leading applications and information sources, ActiveEnterprise includes a software development kit that lets companies create adapters for legacy and custom applications and information sources. As shown in the following figure, three components that have to be integrated are Portal Infranet (BCC), Wisor (Order Management and Workflow) and Lineplant and Inventory Management system.

The TIBCO Rendezvous (TIB/RV) is the message bus as shown in Figure 16. The message format will be proprietary for TIBCO. For integrating using TIB/RV each system requires a TIBCO adapter that is provided by TIBCO or is custom-developed using the SDK provided by TIBCO. These enterprise application specific adapters convert the necessary data between the TIBCO format and the enterprise application format. The adapters use TIB/RV API to send the data across Rendezvous. In the real sense the Rendezvous message bus is a daemon and a set of APIs. Each system that takes part in this communication has a Rendezvous daemon running on it. This daemon is responsible for sending and receiving data from another TIBCO-based system. For a better illustration lets take a case from the workflow. In step 2 of the work flow the Billing system places the order to the order management system. To implement this case using TIBCO, the Infranet uses TIBCO Adapter for Infranet to send the message. The Adapter translates the Infranet storage class definitions to TIBCOs proprietary

31

Enterprise Application Integration message format and sends it across the network using Rendezvous API. This is either a point-to-point messaging or multi-casting. The Rendezvous daemon corresponds to the Order management system (Wisor), identifies this message and converts this message to the Wisors XML format using the

TIBCO Adapter for Wisor. The other steps in the workflow can be explained similarly. The communication between the billing system and HSS BMS-SPP is file-based and not through the integration broker.

Mediation & Provisioning HSS BMS-SPP

Billing and Customer Care Infranet

Order Management & Workflow Wisor

Line Plant & Inventory Management

File Based Interface

TIBCO Adapter for BCC

TIBCO Adapter For Wisor

TIBCO Adapter For Line Plant & Inventory

TIBCO Message BUS( Active Enterprise and Re Rendezvous)

Figure 16: JMS-Based Integration Scenario 3

The disadvantage of the TIBCO-based methodology is that for each component that has to be integrated, a proprietary TIBCO adapter is required. This increases the total cost of the solution. The advantage is the easiness of integration. Most of the adapters are ready-to-use and involve almost zero coding effort. Technical Requirements JMS-Based Solutions The major requirement for the JMS-based solutions discussed above is a J2EE compliant application server such as IBM web sphere or BEA weblogic or JBOSS. The vendor who gives the application server decides the hardware specifications of the system

that will host the application server. It could be a Windows 2000 server having 512 MB RAM minimum or a Solaris System or a Linux System. Most of the Application Servers comes with a web server also. From software point of view the main requirement is Sun Micro Systems Java Development Kit (J2SE) and the J2EE for development. These two things are freely available in the Internet. The Adapters for each Enterprise system must be custom-developed. For this people with expertise in each EIS domain as well as programming skills in C/C++/JAVA/Pro*C are needed. To implement JMS driver for each system expertise in J2EE domain and JAVA programming knowledge in required.

32

Enterprise Application Integration Technical Requirements TIBCO-Based Solution In case of TIBCO Rendezvous-based solution, the major requirement is the TIBCO adapters for each Enterprise Information System. These adapters run normally in another system in which Rendezvous daemon is also running. These systems can be Windows-based or Solaris-based. Additional systems are required to run the TIBCO Rendezvous Data Security Module and the Rendezvous routing daemon. Domain expertise is a must and skilled manpower is also needed for programming. This information is purely theoretical due to the lack of hands on expertise on TIBCO products.

Conclusion
This white paper provides a basic overview of EAI and the related technologies. Table 2 presents a comparative analysis of the different technologies that have been discussed in this white paper.

Table 2: Comparative Analysis of EAI technology

Technology J2EE

Components EJB JMS JCA

Features Messagebased integration Singlelanguage platform

Advantages Cost Effective Less time to market Proven technology for server side implementation Multi - vendor support Integrating hetrogenous systems over HTTP and other transport protocols. Strong Industry support Easy to implement Minimum time to market Less coding compared to other technologies

Drawbacks Specifications are new. May take some more time to get the full faith from customer

Web Services

UDDI WSDL SOAP XML TIBCO Rendezvou s TIBCO Repoditory TIBCO Message Broker TIBCO Adapters

ServiceOriented Architecture

Very new in the market. Security and transactions are not reached in a matured state Very high cost

Complete set of solutions

Third-Party solution (TIBCO)

After evaluating various technologies, it can be concluded that the J2EE-based EAI is the most suitable integration solution for most of the cases. J2EE based integration is cost effective and works on any hardware and operating systm with a compliant Java VM and a compliant set of required paltform services(EJB container, JMS service etc). Since J2EE Supports interconnection with CORBA33

based and Web Service-based applications it is comparatively easy to integrate diverse application systems using J2EE. Also development time is less in Java-based implementations compared to proprietary programming languages such as C/C++. Performance wise also Java is much stable and considered as a server side language in these days rather than a mere client interface language.

Enterprise Application Integration

34