Enterprise Application Integration Reference Manual

7/29/2019 Enterprise Application Integration Reference Manual

1/37

Enterprise Application Integration

White Paper


2/37

COPYRIGHT INFORMATION Copyr igh t Hugh es Soft w ar e Syst em s, 2003

All information included in this document is under a license agreement. This publication and its contents areproprietary to Hughes Software Systems. No part of this publication may be reproduced in any form or by anymeans without the written permission of

Hughes Software SystemsPrestige Opal,146, Infantry Road,Bangalore 560001India

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 ascommitment by Hughes Software Systems. Hughes Software Systems assumes no responsibility or makes nowarranties for any errors that may appear in this document and disclaims any implied warranty of merchantability

or fitness for a particular purpose.


3/37

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......................................................................................................................................................14Operations 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


4/37


1

eAbstract

In a fast-evolving technical scenario, integration

know-how has undergone a major revolution. Thishas facilitated the provision of services such asOperation Support System (OSS) and BusinessSupport System (BSS).

OSS or BSS solutions involve multi-vendor productsthat interface together to provide the requiredfunctionality.

The concept of a message bus or integrationframework is to support the exchange of messagesbetween the vendor components that connect to thebus. This is required to reduce the stove pipingbetween various third party management functions

or applications. This white paper provides insightson integration technologies such as J2EE (JMS, JCAand EJB), Web Services, XML and TIBCO messagingmiddleware (Rendezvous).

Scope

The white paper focuses on Enterprise ApplicationIntegration (EAI) and the related technology used

for seamless integration of heterogeneous enterpriseapplication systems.

It presents:

an in-depth study of the EAI architecture and thetechnology required for new-generation BSSTelecom 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-partysolutions.

a real-time BSS case study that discussesintegration of a billing system, order and workflow management system, mediation and

provisioning system, and an inventorymanagement system through an integration

broker. Different solutions for this case studyare also discussed.


Enterprise Application Integration can be defined as

the combination of processes, software, standards,and hardware, to seamlessly integrate two or moreenterprise systems, allowing them to operate asone. An enterprise may want to migrate to latesttechnology for its operations. However, it may

continue with the existing set of applications. EAIdevises ways to efficiently integrate the newapplications to the old setup.

Although EAI is often associated with integratingsystems within a business entity, EAI may also refer

to the integration of enterprise systems of disparatecorporate entities (B2Bi) when the goal is to permita single business transaction to occur acrossmultiple systems.

History of EAI

Enterprise applications, from as early as the 1960s

through the late 1970s, were simple in design andfunctionality. They were developed largely in part toend repetitive tasks by replicating manualprocedures on the computer. No thoughtwhatsoever was given to the integration ofcorporate data.

By the 1980s, several corporations were beginningto understand the value and necessity forapplication integration. Challenges arose, however,as many corporate IT staff members attempted toredesign already implemented applications to makethem appear as if they were integrated. Examplesinclude trying to perform operational transaction

processing (associated with enterprise resourceplanning - ERP- system functionality) on systemsdesigned for informational data processing (datawarehousing functionality).

With the prevalence of ERP applications in the1990s, corporations felt the need to be able toleverage already existing applications and data


5/37


2

within the ERP system. This could only be done byintroducing EAI. Other issues driving the EAI marketinclude further proliferation of packagedapplications, applications that addressed thepotential problems of the Year 2000 (Y2K), andsupply chain management/business-to-business

(B2B) integration. Also, streamlined businessprocesses, Web application integration, and overalltechnology advances involved EAI development.

After Y2K, many in the industry have focused onmigrating to new generations of networktechnologies. Today, however, service providersbusiness and operational support capabilities aremoving to the forefront of the strategic priority list.Service providers face a major challenge in

designing and deploying an operations supportenvironment that not only differentiates them in a

highly competitive market, but also provides theflexibility and scalability for continuing to supportchange for the foreseeable future. The OSS solutionintegration market is driven by a growing number ofnew forces that are direct results of the rapidtransformation within the telecommunications

sector. The OSS solution integrator tries to addressservice provider issues and help them design andimplement the optimum operational support systemsand business process environments.

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 businessmodelling is done, where the flow of businessprocesses 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 thenecessary building blocks that the business peoplecan manipulate in the above layer. In a message-based EAI approach, business components are

logical objects that represent the execution of one omore business functions.

The Message Services layer provides genericservices that can assist the functioning of above

layers. This includes services such as reformattingmessages, routing, load balancing, alternate pathswitching, and message warehouse. This layer,together with the Transport Services layer is oftenreferred to as a message broker.

The Transport Services layer is the world of the

basic middleware products. Message-orientedmiddleware is one of the key players there, but thislayer also incorporates other middleware productssuch as object request brokers and transactionmanagers. This layer also provides several other

supporting services such as audit, logging andsecurity. From a development point of view, this alsoincludes aspects of APIs, message formats, andtemplates.

Advantages of EAI

In integrated solutions, data is shared between the

different departments in organizations. It opens upopportunities for more focused and intelligentmarketing, improved sales and cross-selling, as well

as more sophisticated knowledge management andanalysis of future trends within their own industrysectors. With the integration between a companyand its suppliers, catalogs are always correct, stocklevels known at all times and delivery requests canbe processed immediately, because a direct linkobviates 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 eitherlinking directly to a similar integration solution, or by

introducing each acquired system into the acquirersintegration service. An integrated enterprise willhave redefined their internal systems and processesso that they can be shared with the wider world.

Security and manageability must obviously beincorporated to protect everyones interests, butonce suppliers and customers can directly access


6/37


3

your systems, you can respond to their needs morecheaply and effectively. By externalizing internalsystems, an organization will be far more effectiveat responding to changing market forces and able tore-use good processes and only reinvent the specificprocesses that need changing or creating. This will

save time and money, bringing new products andservices to the market faster, and allowing theorganization to create and maintain true first-mover

advantage, which is ever harder to achieve andretain.

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.

J2EE provides a set of Java Messaging Service (JMS)APIs for message-based integration. It definescertain standards known as Java ConnectingArchitecture (JCA) for implementing EnterpriseApplication-specific resource adapters. Enterprise

Java Beans (EJB) technology helps to easilyimplement business rules for integration. A J2EE-compliant application server plays the role of amessage broker.

CORBA is an open distributed object computinginfrastructure that is being standardized by the

Object Management Group (OMG). CORBAautomates many common network programmingtasks such as object registration, location, and

activation; request demultiplexing; framing and errorhandling. It also automates parameter marshallingand demarshalling; and operation dispatching.CORBA is language independent. EJB-to-CORBAcommunication is straightforward as the EJBspecification includes a section on CORBA

interoperability.TIBCO Software Inc. has a variety of EAI solutionssuch as Rendezvous. TIBCO Rendezvous is amessage-oriented middleware.

An evaluation of the afore-mentioned technology ispresented in the following paras.

Java 2 Platform Enterprise Edition

Java Messaging Service Overview

Java Messaging Service (JMS) APIs are Sun MicroSystems 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 notportable to other messaging systems. This also

complicates the job of developers, as they have tolearn each messaging products APIs to integrate

products from multiple vendors.

Figure 1 shows a typical MOM architecture. Theadvantage of this architecture is that it supportsasynchronous messaging. That means, even if the

intended recipient is not up and running, the sendercan convey the message to a queue and continueworking.

Message

Oriented

Middleware

(MOM)

Application 1 Application 2

Figure 1: MOM Architecture

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

interfaces and associated semantics that define howa JMS client accesses the facilities of an enterprise-messaging product. In simpler terms, JMS has twoparts:


7/37


4

(a) an API that the developer uses to implementapplications to send and receive messages,

(b) a Service Provider Interface (SPI) where so-called JMS drivers are plugged in.

Sun published the first JMS specifications in August1998. The latest one is JMS version 1.1. These days

JMS is available with all J2EE-compliant applicationservers. With the release of the J2EE 1.3 platform,the JMS API is an integral part of the platform, andapplication developers can use messaging withcomponents using J2EE APIs.

Other than JMS there are a variety of products

present in the market having MOM architecture. Afew examples are TIBCO Rendezvous, IBM

MQSeries, and Microsoft MSMQ.

JMS Architecture

As per JMS specification, a JMS application consistsof the following parts:

JMS Provi der - JMS Provider is a messagingsystem that implements JMS interfaces andprovides administrative and control features. An

implementation of the J2EE platform at release1.3 includes a JMS Provider.

JMS Client - JMS clients are programs orcomponents written in the Java programminglanguage 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 twokinds of administered objects are Destinationsand Connection Factories.

Native Client s- Native Clients are programsthat use a messaging products native client APIinstead of the JMS API. An application that was

created before the JMS API became available,and was subsequently modified, is likely toinclude both JMS and native clients.

The predecessors of JMS supported either a Point-to-Point or Publish/ Subscribe approach to

messaging. JMS supports both. According to thespecification, a stand-alone JMS provider mayimplement one or both approaches, but a J2EE

Container/Application server must implement both.Figure 2 depicts the JMS objects necessary toprovide JMS connectivity to a remote server.

Figure 2: JMS Architecture


8/37


5

ConnectionFactory is an administered object usedby a client to create a connection, which itself is anactive connection to a JMS provider. Because of theauthentication and communication setup processed

when a connection is created (most clients will do alltheir messaging with only one), it is a relativelyheavyweight JMS object. Destination encapsulatesthe identity of a message destination and containsprovider-specific address and configurationinformation.

Sessions are the JMS entities that supporttransactions and asynchronous messageconsumption. JMS specifications do not require clientcode be to be used for asynchronous messageconsumption. Also, the specifications do not require

client code to be capable of handling multiple,concurrent messages. Instead, transactionmultiplexing within a connection is demarcated andencapsulated within a Session. A Session is an

atomic unit of work similar to a databasetransaction. It is very difficult to implement

multithreaded transactions, and Sessions provide thethroughput advantages of concurrency with the easeof single-threaded programming.

MessageProducer and MessageConsumerobjects are created by a Session object and are used

for sending and receiving messages, respectively. Toguarantee the delivery of a message, messages toand from the remote server object should be sent in

persistent mode. The persistent mode instructs theJMS provider to log the message to stable storageas part of the client's send operation. This in turnensures that the message will survive a JMS providerfailure.

Session, MessageProducer, and MessageConsumer

JMS objects do not support concurrent use, whileConnectionFactory, Destination, and Connection

objects do. After these objects and common facilitiesare in place, a client application has the basic JMSsetup required to produce and consume messages.

JMS for Integration

Integration here implies Enterprise ApplicationIntegration. The usual EAI scenario involvesintegrating 5 to 10 different enterprise applications.If some of these enterprises support message-basedcommunication, JMS can be used to integrate those

applications. JMS Driv ers are required for each ofthese enterprise applications. The main purpose ofthese JMS Drivers is to marshal and un-marshalmessage data. These drivers are either custom-

developed by the integration vendor, or by somethird-party vendors. Examples of such JMS drivers

are TIBCO Enterprise for JMS and Spiritwaves JMSDriver. Here the application server (J2EE server thatimplements JMS) plays the role of a message

broker. The following two components are used forintegration with JMS.

Message Driven Beans

JMS Message

Message Dri ven Beans

Enterprise Java Beans (EJB) are J2EE componentsdeployed in an Application server. EJBs assist adeveloper to program without worrying about thetransactions, connection pooling, thread safety or

load balancing. Normally the workflow in the case ofJ2EE-based EAI is defined in EJBs. Therefore, thereis nothing wrong in using an EJB to produce or

synchronously receive messages.

However, a problem arises with receivingasynchronous messages. In this case theprogrammer has to write code to register thereceiving application as a listener for JMS messages.

This requires a decent amount of coding. There aresome 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 ofMessage Dri ven Beans(MDB) as part of their EJB 2.0 specification. MDB isa special EJB component that can receive JMS

messages from a message queue. As per

specifications it is decoupled from any clients thatsends message to it.

JMS Message

JMS has five message types, and while the typeused depends on the requirements of the


9/37


6

application, most client implementations use eitherObjectMessage or MapMessage.

1. ObjectMessages are messages that contains aserializable Java object to inform programmersabout the data type and field that they receiveand set.

2. MapMessages use a set of name-value pairs,where names are strings and values are Javaprimitives.

Alternatively, JMS TextMessages may be moreappropriate for XML-based messages, where JMS is

used for the transport layer, but not for datadefinition.

All JMS messages support the Acknowledge

method for use. If a client uses automaticacknowledgment, calls to Acknowledge are ignored.JMS messages sent by a Session to a Destination

must be received in the order in which they weresent. Therefore, their implementations must providefor the sequencing of incoming messages. Manymessaging applications cannot tolerate dropped orduplicate messages, and require that every messagebe received only once. JMS messages are persistentby default. JMS specification discusses differentkinds and degrees of reliability. A detailed discussionof these specifications is out of scope of thisdocument. In simple words, the persistence isachieved by storing messages in a persistentstorage. As per the specifications, the messageproducer can determine whether a persistent modeof delivery is required or not.

JMS in Integration

While choosing JMS as the messaging solution,issues such as application server performance, datadistribution, security, and error handling must beconsidered. Moreover, if there are manyheterogeneous applications to be integrated, and no

direct JMS drivers are available, the customdevelopment 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 JMSservers, JMS may be appropriate for that system.

However, many simpler alternatives can provide therequisite layer of abstraction between client andserver while taking advantage of HTTP and XML,

and offering desired scalability andsynchronous/asynchronous communication.

J2EE Connector Architecture Overview

Enterprise applications have to access functions anddata associated with applications running on

Enterprise Information System (EIS). Applicationservers extend their containers to applications and

support connectivity to heterogeneous EISs.

Enterprise tools and EAI vendors add value byproviding tools and frameworks to simplify the EIS

integration task. Bi-directional connectivity betweenenterprise applications is essential for enterpriseapplication integration. The J2EE Connector

Architecture (JCA) defines standard contracts, whichallow bi-directional connectivity between EISs.

Application 1 Application 2 Application 3

EIS 1 EIS 2 EIS 3

Figure 3: Integration of EIS


10/37


7

Though Java/J2EE-based application integrationexisted even before JCA, it was complex andproblematic. This was because there was no

standard for such integration. Even before theadvent of J2EE standards, people used proprietaryapplication servers for integration. EIS vendorsgenerally do not support application servers. So,custom development of integration workflow isrequired. This implementation is complex and non-portable, and there are no common standards toimplement so-called EIS-specificConnectors/Adapters. Figure 3 given above showsthe complexity involved in integrating three EISswith three other applications. The EIS connectors

are not shown here because it is understood thateach EIS will have its own connecting mechanism

above them.

To solve this problem, Sun and its Java CommunityProcess partners have proposed the JCA standard.JCA 1.0 is part of the Java 2 Enterprise Edition

specification, version 1.3. Members of the expertgroup working on JCA include Sun, BEA, Fujitsu Ltd,IBM, Inprise (Borland), Motorola, Oracle, Rational

Software, Sybase, TIBCO and Unisys.

Connector Architecture

AConnector is a set of related classes that lets anapplication access a resource such as data oranother application, on a remote EIS. Typically, aconnector accesses non-relational data and is usedby developers to complement the other means ofaccessing data (such as RDBMS) using JDBC. Asimple analogy is to think of these classescollectively as a pipeline that transmits data from aresource to the application when the applicationrequests it. The behavior of a connector at runtimeis similar to a transaction. The application requests

data from the connector, and the connector gets thedata from the resource and returns it to theapplication.

If there are standards to define the application partof the connectors, it will be easy to integratemultiple systems, as system integrators will only

have to deal with the interfaces prepared as per thestandards. The EIS-specific implementation will behidden from the developer.

IBM followed this thought process and came up witha framework called Common Connector Framework(CCF) architecture. Later, Sun took up this idea and

came up with a connector architecture standard thatthey included as a necessary component of theirJ2EE 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 forasynchronous communication. It supports manymore features that ease the integration with EIS.Discussion on the all JCA features is not within thescope of this document. This discussion is based onJCA 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 resourceadapters (one resource adapter per EIS type) areplugged into an application server. This capabilityenables application components deployed on theapplication server to access the underlying EISs. Anapplication server and an EIS collaborate to keep allsystem-level mechanisms (transactions, security,and connection management) transparent fromapplication components. As a result, an applicationcomponent provider focuses on the development ofbusiness and presentation logic for its applicationcomponents, and need not get involved in system-level issues related to EIS integration.

System Contracts

JCA adapters normally plug into a J2EE-compliant

application server. To achieve a standard system-level plugability between application servers andEISs, the connector architecture defines a standardset of system-level contracts between an applicationserver and EIS. Consider resource adapter as asystem-level software driver that is used by theapplication server or application client to connect to

an EIS. These contracts stipulate how an externalsystem can access this EIS driver for integration.


11/37


8

There are three system contracts defined in thespecification. They are related to Connection

Management, Transaction Management, andSecurity.

ConnectionManager

Transaction

Manager

Security Manager

Application Client

Resource Adapter

Enterprise Information

System

Container

Componenent

Container

System Contracts

J2EE Application Server

Figure 4: System Contracts

Connection Management

The Connection Management contract allows

applications to connect to an EIS. Applications use aConnection Factory to access the connectioninstance, which the application component uses toconnect to the underlying EIS. Connection poolingmanages connections that are expensive to createand destroy. Connection pooling of expensiveconnections leads to better scalability and

performance in an operational environment. Theconnection management contract provides supportfor connection pooling. This leads to a scalableapplication environment that can support a large

number of clients requiring access to EISs. JCAspecs 1.0 says the connection managementcontracts must be implemented in any JCA resource

adapter.

Transaction Management

A Transaction Management contract between the

transaction manager and an EIS supportstransactional access to EIS resource managers. Thiscontract enables an application server to use atransaction manager to manage transactions acrossmultiple resource managers. This contract also

supports transactions that are managed internal toan EIS resource manager without the necessity ofinvolving an external transaction manager. As per

the specification, the implementation of transaction

contract is optional and is only needed if the adapterhas to support it.

Security

A Security contract enables secure access to an EIS.This contract provides support for a secureapplication environment that reduces securitythreats to the EIS and protects valuable informationresources managed by the EIS. Again, this is also anoptional contract.

Client API and Container - Component Contract

Some components are deployed in the applicationserver environment, which define the workflow, and

are end users for the JCA resource adapter. Thecontracts between these components and theapplication server are called Container-Componentcontracts. The client API used by the applicationcomponent for EIS access may be defined in termsof:

The standard Common Client Interface (CCI)

A client API specific to the type of a resourceadapter and its underlying EIS. An example isJDBC for relational databases.

CCI defines a common client API for accessing EISs.

The CCI is targeted towards EAI and enterprise toolsvendors.


12/37


9

JCA for Integration

JCA has a major role to play in J2EE-based

integration. One side of the JCA adapter, which maybe considered as part of the J2EE container

(application server) is standardized. Therefore,anybody can access it without knowing theimplementation details. The other side of the

adapter implementation is EIS-specific and usestechnologies such as JNI and CORBA. Theproprietary APIs of the EIS are used to communicatewith the EIS. For example, if the EIS is a legacysystem, we have to live with the interface that thesystem exposes.

EJB Overview

Enterprise Java Beans (EJB) is a server-side

component architecture that simplifies the processof building enterprise-class distributed component

application in Java. The EJB component modellogically extends the Java Beans component model.The Java Beans component model defines a

standard mechanism to develop portable, reusableJava technology development components, such aswidgets or controls. A Java Bean is a specializedJava class that can be added to an application

development project and then manipulated by theJava technology Integrated DevelopmentEnvironment (IDE). Multiple beans can be combinedand interrelated to build Java applets or applicationsor to create new, more comprehensive or specializedJava Beans components.

EJB Architecture

The Enterprise Java Beans component modellogically extends the Java Beans component model

to support server components. Server componentsare reusable, prepackaged pieces of application

functionality that are designed to run in anapplication server. They can be combined with othercomponents to create customized applicationsystems. Server components are similar todevelopment components, but they are generally

larger-grained and more complete than developmentcomponents. EJB components are deployable, and

can be imported and loaded into an applicationserver, which hosts those Server components.

EJB architecture provides an integrated applicationframework that dramatically simplifies the process of

developing enterprise-class application systems. AnEJB server automatically manages a number oftricky middleware services on behalf of theapplication components. EJB component-builderscan concentrate on writing business logic ratherthan complex middleware. The results are thatapplications get developed more quickly and thecode is of better quality.

The EJB model supports a number of implicitservices, 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 objectdestruction. The EJB container (applicationserver) automatically manages the objectlifecycle on behalf of the enterprise bean.

Stat e Management : Individual enterprise

beans do not have to explicitly save or restoreconversational object state between method

calls. The EJB container automatically managesobject state on behalf of the enterprise bean.

Security: Individual enterprise beans do nothave to explicitly authenticate users or checkauthorization levels. The EJB containerautomatically performs all security checking onbehalf of the enterprise bean.

Transactions: Individual enterprise beans do

not have to explicitly specify transactiondemarcation code to participate in distributedtransactions. The EJB container canautomatically manage the start, enrollment,commitment, and rollback of transactions onbehalf of the enterprise bean.

Persistence: Individual enterprise beans do not

need to explicitly retrieve or store persistentobject data from a database. The EJB containercan automatically manage persistent data on

behalf of the enterprise bean.


13/37


10

Portability Layer

The Enterprise Java Beans model defines therelationship between an enterprise bean componentand an enterprise bean container (applicationserver). Enterprise Java Beans components do notrequire the use of any specific container system. A

vendor can adapt any application server to supportEnterprise Java Beans technology by adding supportfor services defined in the specification. The servicesdefine a contract between an enterprise bean and

the container, effectively implementing a portabilitylayer. Any enterprise bean can run in any application

server that supports the Enterprise Java Beanscontracts.

EJB Call Workflow

1. The client calls a local stub.

2. The stub marshals parameters into a formsuitable for the network.

3. The stub goes over a network connection to theskeleton.

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 beaninstance and the bean does its work, each of the

preceding steps must be repeated for the returntrip home.

Figure 5 illustrates the process.

Enterprise Java

Bean

Client Code

Senlet , JSP etc

EJB

Interface

Transaction Service,

Security Service,

Persistence Service,etc

1. Call method

Remote Interface

5.Return Result

3. Call a Bean

4. Method

Return

2. Call Server

API

EJB Server/ Container

Figure 5: EJB Call Workflow

EJB and InteroperabilityEJB has adopted RMI-IIOP as the standard protocol

for on-the-wire interoperability. Other protocols arepermitted, but IIOP (Internet Inter ORB Protocol) is

required for conformant EJB implementations tointer-operate. EJB inherits a significant benefit fromRMI-IIOP. In RMI-IIOP, the physical location of the

remote object that the client invokes is masked fromit. This feature spills over to EJB. The client code is

unaware of whether the EJB object it is using islocated on a machine next door, or a machineacross 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 interoperatewith native language clients and servers. IIOP allowseasy integration between CORBA systems and EJBsystems. Enterprise beans can access CORBAservers, and CORBA clients can access enterprise


14/37


11

beans. Using a COM/CORBA Internetworkingservice, ActiveX clients can also access enterprisebeans and enterprise beans can access COMservers. Potentially, there could also be a DCOMimplementation of Enterprise Java Beanstechnology.

Types of Beans

Enterprise Java Beans technology supports threedifferent kinds of beans.

Session Beans Entity Beans Message Driven Bean

Session Beans

A Session bean is created by a client and in mostcases exists only for the duration of a singleclient/server session. A Session Bean performsoperations on behalf of the client, such as accessinga database or performing calculations. Sessionbeans can be transactional, but (normally) they arenot recoverable following a system crash. Sessionbeans can be stateless, or they can maintain aconversational state across methods andtransactions. 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.

Enti ty Beans

An Entity bean is an object representation ofpersistent data maintained in a permanent datastore, such as a database. A primary key identifieseach instance of an entity bean. Entity beans can becreated either by inserting data directly into thedatabase or by creating an object (using an objectfactory Create method). Entity beans aretransactional and they are recoverable following a

system crash. They can manage their ownpersistence or delegate persistence services to theircontainer (application server). If it delegatespersistence to the container, then the containerautomatically performs all data retrieval and storage

operations on behalf of the bean.

Message Dri ven Bean

A Message Driven bean is a special EJB componentthat can receive JMS messages. A message-drivenbean consumes messages from queues or topicsthat are sent by any valid JMS client. A MessageDriven bean is de-coupled from any client that sends

messages to it. A client cannot access the messagedriven bean through a component interface. JMS isthe API to send message to Message Driven Bean.

EJB for Integration

In a scenario that deals with a legacy system that iscritical to the business process, we have two basic

choices:

1. Rewrite that existing system using EJB

components. This option is the cleanestsolution, but it requires the most effort. Itmay also be infeasible. Legacy systems tend

to be complex. Developers who understandthe legacy system may be difficult to find,and the time-to-market needs of theorganization may not permit a rewrite.Finally, the performance of existing systems

that use native code may not be acceptablein the Java world.

2. Bridge into that existing system. This is themost 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 isrecommended to wrap the legacy system with an

EJB layer rather than accessing it directly (fromServlets or JSP), because this abstraction layer willenable you to replace the legacy system in the

future, if the need arises. The EJB layer could beSession beans, Entity beans, Message-Driven beansor all three. The choice of EJB components dependson the nature of your existing system.

The next challenge is to actually achieve the bridgeto the existing system. This implies reckoning what

is happening inside the EJB layer that enables it totalk to the existing system.

There are a number of solutions for this approach.Some of them are discussed below.


15/37


12

Proprietary Bridges

You can buy an off-the-shelf bridge that connects toa specific legacy system, perhaps an EJB-COMbridge or a container-provided API. The

disadvantage of these proprietary bridges is a loss ofportability, as there is no guarantee that this codewill run in other J2EE-compliant servers.

The Java Native I nt erface (JNI )

JNI enables Java to bridge into native code such asC/C++ code. The advantage of JNI is that it is faster

than the other approaches. The disadvantages arethat it cannot connect to any system such as a

Legacy system. The existing system has to run in-process and JNI is platform-specific. Therefore, if

the code has to run on multiple platforms, thetesting and maintenance effort gets multiplied aswell.

CORBA

CORBA is an older middleware technology thatcompetes with EJB as it has its own component

architecture.

Also, it underlies EJB as some J2EE servers are oldCORBA products wearing a new hat. The big

difference between CORBA and EJB/J2EE is thatCORBA is language-neutral, while EJB/J2EE isspecific to Java. Although CORBA has this advantageover EJB/J2EE, it has very little industry momentumbehind it and is more appropriate as a technologyfor performing integration with existing systems.

You can bridge into code written in almost anylanguage by calling that legacy system via CORBAAPIs from within your EJB layer. This is highly

appropriate for existing systems that are alreadyCORBA-based. The disadvantage of CORBAintegration is that it requires an out-of-process

remote call, which slows performance. Also, itrequires learning a whole new technology if thelanguage is not known.

Java Message Serv ice ( JMS)

JMS along with Message Driven Beans enables youto bridge to existing systems using message-oriented middleware. Messages are sent to existingsystems rather than invoking them directly through

API calls. This is a bit slower, but it also is a looselycoupled paradigm that enables you to build complexmessaging workflows. JMS is highly appropriate if

the existing system already uses messaging.

Figure 6 illustrates an integrated EAI with CORBA,

EJB and JCA.


16/37


13

Apple ts Applications,

CORBA Clients

Servlets

JCA

Business Partner

or Other Systems

Business Partner orOther Systems

JSPs

EJBs

Message-Based

SystemDatabases

Existing

System.

ERP System

Client Applications

Web TechnologyServices Firewall

IIOP

J2EEServer

JMS SQL Proprietary Protocol Web Services Technology

Back End Systems

iMac

Figure 6: An integrated EAI System

Web Services

Web services (essentially XML/HTTP) provide anattractive approach to integrating to existingsystems. Youcan use XML to represent the data sentto existing systems. HTTP is your transport and itallows you to navigate firewalls easily. This is anonintrusive approach because any system that isInternet-enabled can use Web services withoutrequiring a separate communications infrastructure,

such as CORBA or JMS. The disadvantage of Webservices is that the XML parsing overhead may slowthe processing.

JCA

JCA is a specification that enables you to acquiredrivers that connect with existing systems and plug

them into the J2EE server to connect to a legacysystem. You can connect to any existing system forwhich drivers exist. You can write your own driver ifno driver exists. One such example is a proprietaryinternal system built in-house.

Web Services Overview

Web Services are the next stage of evolution for e-business. They view everything as a service that canbe dynamically discovered and orchestrated using

messaging on the network. Enterprises candynamically sell their services to others bypublishing their Web Services. The key to reaching

this new horizon is a common program-to-programcommunication model, built on existing andemerging standards such as HTTP, Extensible

Markup Language (XML), Simple Object AccessProtocol (SOAP), Web Services Description

Language (WSDL) and Universal Description,Discovery and Integration (UDDI).

Web Services allow applications to be integratedmore rapidly, easily and less expensively than ever

before. Integration occurs at a higher level in theprotocol stack, based on messages centered moreon service semantics and less on network protocol


17/37


14

semantics, thus enabling loose integration ofbusiness function across the Web between, andwithin enterprises. They provide a unifyingprogramming model so that application integrationinside and outside the enterprise can be done with acommon approach, leveraging a common

infrastructure. The integration and application ofWeb Services can be done in an incrementalmanner, using existing languages and platforms and

by adopting existing legacy applications. Moreover,Web Services compliment J2EE, CORBA, and otherstandards for integration with more tightly-coupled

distributed and non-distributed applications. WebServices are a technology for deploying andproviding access to business functions over the web.

Web Services Architecture

Web Services are functions published over the web.The following technologies are used to access thesefunctions from remote applications:

UDDI: Used to lookup a web service

WSDL: Used to describe a web service

SOAP: Used to call a web service(XML/HTTP)

(eb)XML: Used to conduct complex businessconversations and flow on the top of SOAP

The Web Services Model

The Web Services architecture is based on theinteractions between three roles: service provider,service registry, and service requestor. The

interactions involve Publish, Find and Bindoperations. The service provider defines a servicedescription for the Web service and publishes it to a

service requestor or service registry. The servicerequestor uses a find operation to retrieve the

service description locally, or from the serviceregistry, and uses the service description to bindwith the service provider and invoke or interact with

the web service implementation. Figure 7 illustratesthese operations, the components that providethem, and their interactions.

Services Registry

Service Requestor Service Provider

2.Service Discovery

3.Service Invocation

1.Publish

Figure 7: Web Services Model

Components in Web Services

Service Provider : From a business perspective,this is the owner of the service. From anarchitecture perspective, this is the platform thathosts 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 isthe application that is looking for and invoking orinitiating an interaction with a service.

Service Registry : This is a searchable registry ofservice descriptions where service providers publish


18/37


15

their service descriptions. Service requestors findservices and obtain binding information for services.

Operations in Web Services

For an application to take advantage of WebServices, three behaviors must take place:publication of service descriptions, lookup or findingof service descriptions and binding or invoking of

services based on the services description. Thesebehaviors can occur singly or iteratively.

Publish: To be accessible, a service description has

to be published so that the service requestor canfind it.

Find: In the Find operation, the service requestor

retrieves a service description directly, or queries theservice registry for the type of service required.

Bind: In the Bind operation, the service requestorinvokes or initiates an interaction with the service atruntime using binding details in the servicedescription to locate, contact and invoke the service.

Web Services for Integration

The Web Services Architecture (WSA) is an idealtechnology to incorporate enterprise legacy

applications into this new area. This is the next stepin creating a Web-based interface that interacts withan enterprise application in order to enableprogram-to-program communication. This impliesdoing the same business in a more automatedfashion and with a more efficient approach.

As the beginnings of e-commerce, many applicationshave been developed to support the growingdemand of online shopping systems. Many of the

systems use proprietary implementations, oftenbecause of the lack of open standards at the time ofdevelopment. However, the business processesthese earlier-generation proprietary applicationssupport will continue to be necessary in the future.This can be credited to the significant investments

that have been made into these e-businessapplications.

These legacy applications are more complex thanyou may expect in the first place. For example, aValue Added Tax (VAT) calculation - similar to salestax calculation in the US - becomes much morecomplex if it supports trade situations around theglobe with all the different conditions that have tobe handled.

To enable legacy applications to participate indynamic e-business, we have to apply Web Servicetechnologies, which will allow the services to bedefined so as to hide some of the complexity of thelegacy application interface. Once the applicationshave been technically adapted, the business

processes are likely to evolve to a more automatedbusiness process with reduced human intervention.

The concept of Web services, together with theService Oriented Architecture (SOA) approach,creates an opportunity for legacy applications to bemade available for the Web. Here, we will show howa conceptual architecture can be applied to many oftoday's legacy applications running on mainframesand other servers. This includes applications under

the control of mainframe transactions managers,that is, the Customer Information Control SystemTransaction Server (CICSTS) or Information

Management System (IMS). The next figure showsthe structure of this architecture.


19/37


16

Web

Server

SOAP

Router

System 3System 2

Adapter

UDDI Registry

Publish

Integration Broker

Service Discovery

Service

Requestor

Application Server

WebService

Lagacy

System

System 1

Figure 8: Information Management System

Web Services Advantages

The advantages of a Web Service are listed below.

It can make proven production level applicationsavailable as Web services. This allows for rapid

deployment of stable Web services to customersof a Web service provider. The high investment in large legacy applications

is preserved for users of the Web service, whilestill 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:

High Scalabilit y: The number of potentialusers for a Web service often cannot bedetermined when the service is started. Amainframe such as the zSeries Parallel

Sysplex cluster-based service is dynamicallymanaged by the Workload Manager (WLM)and can scale to a very high degree.

High Availability: Web services must beaccessible for Business-to-Consumer(B2C) and Business-t o-Business (B2B)

users with 99.99% availability at 24x7x365.A mainframe cluster can be set up with no

single point of failure that ensures this levelof availability.

Conti nuous Operation: Mainframes canallow for scheduled system outages forsoftware or hardware upgrades without anyinterruption to applications running on thecluster. 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 andexchanging information between enterpriseapplications and between businesses. Applicationshave 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 significantimprovements in compression, computing languagesand application functionality. Vendors haveimplemented ever-more complex formats.

The lack of interoperability between file formats hasbeen the bane of enterprises since the advent of thesecond application ever written. The problem is that


20/37


17

of getting the right context, and not just getting thecorrect data elements.

For example, a customer record in a typical file orrelational database record might look like thefollowing one:

Separated from the data logic, this file only contains71 characters, but we can easily confuse first namewith last name, city with streets, and telephone withfax numbers. Efficiency in the past was moreimportant than interoperability.

With XML, the context or meaning of the data isstored along with the data. Though it takes morecharacters to convey the same, the resulting outputis clearer and more comprehensible. The receivingapplication can no longer be confused about thedetails of the individual.

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 isconsiderably more verbose than the no-contextexample above. The file grew to 307 characters,which implies a 450% increase. This may seeminordinate when compared to the industry prioritiestwo decades ago, but in todays informationeconomy, processing power, compression

technologies and bandwidth are all plentiful,inexpensive and high performance. The expensiveresource is now human resource. Today, theincrease 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 functionsand companies. It requires both an infrastructure forintegrating applications and a standards-basedmechanism for creating portable data. For an

increasing number of companies, that mechanism isXML. Figure 10 depicts a typical XML file that has anintegrated context.

Figure 10: XML file with context included

Data Exchange Without ComplicatedContraptions

XML provides a generalized mechanism forrepresenting and structuring data. It is in fact ameta-language, which implies that it can be used to

define any set of constructs and therefore isinherently extensible. As a result, XML provides amechanism for dealing with the formatting of

information for display as Web pages as HTML does.Also it provides a flexible framework for representingthe structured data associated with databases andapplication systems. Therefore, any data structurecan be rendered as an XML document.In its earliest applications, XML provided a more

powerful HTML for interfacing structured data withWeb-based applications. Today it has also emergedas a powerful and flexible vehicle for storing,manipulating and exchanging data of all typesacross 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 datastructures and formats. Using XML, an organizationcan specify a vocabulary of data elements in, say, a

customer processing application, such as thecustomer's name, street address, city/state/zip,phone number and customer number. Differentapplications can then identify that data, interpret itsattributes and use it appropriately.

The meaning is derived from agreement on aspecific XML schema or Document Type Definition(DTD) in earlier XML specifications. A schemadescribes the vocabulary and the syntax of a specific


21/37


18

type of XML document; it provides a distinctdefinition of a set of tags appropriate to a specificapplication area. However, just as with a languagevocabulary, it also implies agreement on themeaning that should be associated with the tags.For example, in a payments system, it should be

agreed that represents a monetary amountin a particular currency.

Data Transformation and Manipulation

The power of XML is complemented by itseXtensible Styl esheet Language (XSL) . Morespecifically, eXtensible Stylesheet LanguageTransformations (XSLT) provides a standards-baseddata transformation capability and is the ideal

vehicle for the data manipulation requirements of

EAI. Data transformation is a critical component ofEAI, as it allows data from one application to betransformed for use in another application. Theclassic transformation problem occurs, for example,when one application requires age as input data,while another can only supply date of birth .Gettingfrom date of birth to age requires not only theresolution of different meanings and different dataformats but perhaps some computation as well. Theadvantages of employing XSLT for transformation lie

in the clear separation of transformation rules from

the application programming effort and in itsseamless integration with XML.

XML promises to achieve for structured informationwhat HTML achieved for text and graphics on the

Web. First, XML is rapidly emerging as the preferreddata integration backbone both within and acrossorganizations and industries. Second, XML, inconjunction with HTTP, provides for customizeddelivery of information to the browser, a prerequisitefor compelling customer-oriented applications.

XML also eliminates the need for custom adapterswhen integrating packaged applications. In fact,when coupled with HTTP, XML becomes a ubiquitousmiddleware solution that lends itself to the looselycoupled style of integration required by B2B

solutions. In addition, XML is increasingly beingsupported by other message transports, such asMQSeries. Major application vendors, including SAP,Oracle and Siebel, are adding XML-based applicationprogram interfaces to their application suites andthat a third-party market for XML-based adapters for

popular applications is rapidly emerging.

Figure 11 depicts an XML-based application.

Web Application

Message Broker

xxxx

xx

xxxxx

xxxx

xxx

xx

Accounting

xxxx

xxxx

xxxxx

Database

XML

Message

XML

MesageXML

Formatted

SQL Queries

Figure 11: XML-based application


22/37


19

New World of Vocabularies

XML has shown great promise in defining XMLvocabularies for particular industries. Thesevocabularies define a set of elements and describewhere they go in the document structure. Both theautomobile industry and the health-care industry are

prominent players in the new world of XMLvocabularies. Examples of such vocabularies areExtensible Business Reporting Language(XBRL) and Electronic Business extensibleMarkup Language (ebXML) .

Such vocabularies can define industry-specific

information interchange and even transformationcharacteristics. As a result, within a given industrydata-exchange solutions can be used. This includes

metadata and behavior.

Here lies the future of information exchange: the

ability to leverage existing best-practice integrationsolutions in the same way packaged applications

have been leveraged.

Third Party Solutions

TIBCO Messaging Solutions

The foundation of business integration is themovement 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 recentstandards include J2EE and Web Services.

TIBCO Software Inc. is an integration vendor thatprovides comprehensive support for all of thesetechnologies. TIBCO provides messaging solutionsbased on their patented distributed architecture,server-and queue-based architectures and Java. Thiscomplete set of solutions enables virtually every

conceivable type of synchronous and asynchronous

communications including publish/subscribe,request/reply, broadcast, multicast, and Pragmatic

General Mul ti cast ( PGM) .

TIBCO solutions offer a range of options for qualityof service including reliable, guaranteed, certified,transactional, and encrypted. They support the

distribution of information over both local and widearea networks. TIBCO family consists of manyproducts. Some of them are TIBCO Rendezvous,TIBCO Repository, TIBCO Message Brok er, andTIBCO Adapters. Each component has a role to

play in a typical integration scenario.

This whitepaper discusses the prime member of theTIBCO family - TIB/Rendezvous in detail. Detaileddiscussions of other TIBCO products are out ofscope of this document.

TIBCO Rendezvous

TIBCO has a number of solutions for messaging.The important ones are TIBCO Rendezvous andTIBCO Enterprise for JMS. TIBCO Rendezvous is themessaging system that is the foundation of TIBCOActiveEnterprise, TIBCOs line of e-businessinfrastructure products. Rendezvous has a widecustomer base and is rapidly emerging as a standardfor enabling the mission-critical real-time messagingrequired for robust e-business infrastructures.

TIB/Rendezvous software makes it easy to createdistributed applications that exchange data across anetwork. TIB/ Rendezvous software supports many

hardware and software platforms, so programsrunning on many different kinds of computers on anetwork can communicate seamlessly. From the

programmers perspective, the TIB/Rendezvoussoftware suite includes two main components:

TIB/Rendezvous programming languageinterface (API) and

TIB/Rendezvous daemon (rvd).

Figure 12 details the TIBCO architecture.


23/37


20

AProgram

TIB/Rendezvous

API

BProgram

TIB/Rendezvous

AP I

CProgram

TIB/Rendezvous

AP I

TIB/Rendezvous

Daemon

TIB/Rendezvous

Daemon

Computer 1 Computer 2

Network

Figure 12: TIBCO Rendezvous Architecture

Rendezvous (TIB/RV) supports both point-to-pointmessaging as well as multicast messaging. TIB/RV

programs uses subject-based addressing tocommunicate with each other. Subject-based

addressing technology helps messages reach theirdestinations without involving programmers in thedetails of network addresses, protocols, hardware

and operating system differences, ports and sockets.Subject-based addressing conventions define asimple, uniform name space for messages and theirdestinations. Each TIB/RV message bears a subjectname, which simultaneously specifies a deliverymode and the destination of the message. If thesubject name is inbox then it will be a point-to-pointmessage. Else, the message will be a multicastmessage. Communication between programs is alsoanonymous. The consumers need not know whereor 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 ofsubject names and

the actual data is in a form that both canmanipulate and interpret

Anonymous communication decouples dataconsumers from data producers. Consumers are

insulated from most changes in data producingsoftware, including the replacement of producer

processes, and the shifting of responsibilities among

a collection of producer processes.

Architecture

As already said TIB/RV have two main componentsfrom programmers point of view. Each system,

which is a part of messaging architecture, will havea Rendezvous daemon. The daemon is a

background process that supports all Rendezvouscommunications. Distributed processes depend on itfor reliable and efficient network communication. Allinformation that travels between processes passes

through a Rendezvous daemon as it enters a hostcomputer or exits a sending process. The applicationprograms will use the Rendezvous programminglanguage interface (API) to communicate with theTIB/RV daemon, which is the message bus. Asshown in the following figure if computer 1 andcomputer 2 have to communicate with each otherusing TIBCO Rendezvous, then each system shouldhave a daemon running on them. The interfacebetween the daemon and the respective applicationson each system will be the Rendezvous APIs.

The main functionality of the Rendezvous daemonare given below. A Rendezvous daemon:

transmits outbound messages from programprocesses to the network,


24/37


21

delivers inbound messages from the

network to program processes,

filters subject-addressed messages,

shields programs from operating systemidiosyncrasies, such as low-level sockets.

Message Structure

Rendezvous messages carry data among programthreads or processes. Messages contain self-describing data fields. Programs can alwaysmanipulate message fields, send messages and

receive messages. Each field will have certaincomponents 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 descriptiveinformation between sender and listener toautomatically convert messages between the local

data format and Rendezvous wire format.Rendezvous wire format is a universal format that isindependent of hardware, operating system, andprogramming language architectures. The universal

wire format provides a common language to connectdiverse programs.

Rendezvous software encourages an event-drivenprogramming paradigm. Program callback functionsrespond to asynchronous events, such as aninbound message or a timer event. The arrival of aninbound message is an important event for mostRendezvous programs. It is also an instructiveexemplar of an asynchronous event. The receivingprogram cannot know in advance when a particularmessage might arrive in the queue. To receivemessages, programs create listener events, define

callback functions to process the inbound messages,and dispatch events in a loop. While a program islistening for messages, the event driver queues the

listener event each time a message arrives with amatching subject name. Each appearance of the

event in the queue leads to a separate invocation ofits callback function. At any moment in time, anevent queue can contain several references to the

same listener event object-each reference paired

with a different inbound message. Each time thecallback function runs, it receives an inboundmessage as an argument. The callback functionmust process the message in an appropriateapplication-specific fashion.

The software mechanism for sending and delivering

messages is called a transport. A transport definesthe delivery scope-that is, the set of possibledestinations for the messages it sends. Programsuse transport objects to send messages and listenfor messages. A transport determines three aspects

of message delivery:

Delivery scope-the potential range of its

messages

Delivery mechanism-the path (includingsoftware, hardware and network aspects)

that its messages travel

Delivery protocol-the ways in whichprograms cooperate and share informationconcerning message delivery

Various types of transport object combine theseaspects to yield different qualities of service-forexample, intra-process delivery, and networkdelivery, reliable delivery, certified delivery, anddistributed 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 reliablemulticast protocols ensure that all operational hosts

either receive each multicast message or detect theloss of a message. Reliable delivery compensates forbrief network failures. The receiving Rendezvousdaemon detects missing packets and requests thatthe sending daemon retransmit them. The sendingdaemon stores outbound messages for a limitedperiod of time (60 seconds), so it can retransmit theinformation upon request. It discards old messagesafter the time period elapses, and cannot retransmitafter that time.

The Rendezvous daemon does not guarantee

delivery to components that fail and do not recoverfor periods exceeding 60 seconds. AlthoughRendezvous communications are highly reliable,some programs require even stronger assurances ofdelivery. Certified delivery features offer greater

certainty of delivery-even in situations whereprocesses and their network connections are


25/37


22

unstable. Certified message delivery is achievedusing a CM transport object.

Advantages of TIB/Rendezvous

TIBCO Rendezvous uses a distributed architecture toeliminate bottlenecks and single points of failure.

Applications can select from several qualities ofservice including reliable, certified and transactional,as appropriate for each interaction. Messaging can

be request/reply or publish/subscribe, synchronousor asynchronous, locally delivered or sent via WANor the Internet. Rendezvous messages are self-describing and platform independent, with a user-extensible type system that provides support fordata formats such as XML. Also it is available on

platforms ranging from desktop PCs runningWindows to mainframes running OS/ 390. See ourWeb site for specific details. Rendezvous APIs are

available in Java, C, C++, Perl and COM. Such awide range of APIs will ease the job of a system

integrator. But the main disadvantage is foradditional features customer has to pay more andget additional components.

Rendezvous Routing Daemon

TIBCO Rendezvous daemon delivers messages toprograms on computers within a single network.Delivering messages beyond network boundariesrequires additional software component-Rendezvousrouting daemons. Routing daemons efficiently

connect Rendezvous programs on separate IPnetworks, so that messages flow between them as ifon a single network. Communicating programsremain decoupled from inter-network addresses and

other details. The routing daemons forwardRendezvous messages between networks. Whenrouting daemons are present, Rendezvous programs

on one network can listen for subject names andreceive messages from other networkstransparently- neither the sending nor the receivingprograms require any code changes. Administratorsretain 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 localnetworks, and to other routing daemons. Whilerouting, hardware specifies its local networksprimarily in terms of network interfaces, routingdaemon software specifies each local network as a

pair combining network and UDP or PGM service.UDP or PGM services effectively divide the physicalnetwork into separate logical networks-even thoughthey use the same hardware. Moreover the routing

daemon can provide all the functionality of aRendezvous daemon in the system it resides.

TIBCO Rendezvous TX

This is an add-on product to TIB/RV that extendsRendezvous messaging product, adding two qualities

of service enhancements:

atomic transactions and guaranteed message delivery

Transactions work well to synchronize operationswithin a localized environment. For example, whenthe transaction remains within the control of oneprocess, and involves resources within a localnetwork. However, when long distances intervene orcommunications are unreliable, synchronizationbecomes difficult. To overcome this difficulty,Rendezvous TX combines two complementary

technologies-transactions and messages. In manyapplications, when synchrony is not achieved, youcan substitute guaranteed messages in place of

absolute synchrony. TX messages decouplecomponents with respect to time and space, withoutsacrificing certainty. The message will eventually

arrive at its destination, and the receiver will takeappropriate and effective action in response. For

example, program A uses a transaction tosynchronize several database operations with amessage send operation. At a distant site, programB uses a transaction to synchronize the receipt ofthat message with several operations involving a

different database. Although A and B cannotsynchronize their database operations with oneanother, their operations are linked by the message,which is guaranteed to arrive. In a programmaticmanner the Rendezvous TX APIs will reside abovethe Rendezvous APIs and the program will interactwith TX APIs.

TIBCO Rendezvous Data Security

This is another add-on component for TIBCORendezvous that implements a securecommunications protocol for Rendezvous

applications. The data security component consistsof two components:

APIs that resides top of Rendezvous APIs in aprogram

Access Control List Daemon that sits in acentralized server Host

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


26/37


23

programmers. Programmers focus on applicationdomain issues, while the security officer determinescryptographic requirements and user privileges.Programs can secure (encrypt) and clear (decrypt)TIB/Rendezvous data messages. Programs can alsodo these operations implicitly, by sending and

receiving messages through a secure transport. Thisfeature speeds migration of existing TIB/Rendezvous(Release 6.6 or later) programs to use Data Security

functionality. Data Security software automaticallyattends to all cryptographic computations, includingverification of digital signatures and identity

certificates. The Access Control List Daemon (rvacld)is a server process that distributes securityinformation to user programs. The security officercontrols the security architecture and all securitydecisions through a database attached to this

central server.

TIBCO Repository

TIBCO Repository stores configuration data andmetadata, but is not a general-purpose data store.TIB/Repository shares common information among

different ActiveEnterprise components, thusproviding customers with a unified view of theirenterprise. It also stores private configuration dataso that a single instance's configuration can beaccessed from anywhere within the network.TIB/Repository lets the user to create and managerepositories. 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 ispersistently stored. A repository instance is called alocal repository instance when it is stored on thelocal file system and directly accessed by the client.A repository instance is called a remote repository

instance when it is managed by a repository serverand accessed by a client using TIB/Rendezvous.Repository clients are applications that use theTIB/Repository client library to manage repositoryinstance data. A client can manage local or remote

repository instances. Examples of applications that

use the TIB/Repository client library to becomeTIB/Repository clients are TIB/Adapter SDK

adapters, TIB/MessageBroker, TIB/AdapterAdministrator and TIB/IntegrationManager. Clientsaccess repositories locally or remotely. A localrepository is always a file that is accessed directly. Aremote repository requires a repository server that

manages repository instances. The server usesTIB/Rendezvous software to communicate with

remote clients. A repository network consists of arepository server and remote client(s) that cancommunicate with it using TIB/Rendezvousmessaging. For a client and server to be part of thesame repository network, they must have the sameTIB/Rendezvous transport configuration of service,

network, and daemon.

TIBCO Message Broker

TIB/MessageBroker is a sophisticatedtransformation, routing and rules-processing systemDesigned to simplify the process of sending andreceiving messages across disparate distributedapplications, TIB/MessageBroker makes thedifferences among enterprise applications

transparent by mapping, transforming, validatingand routing data according to defined rules.TIB/MessageBroker is integrated into the TIBCO

ActiveEnterprise real-time enterprise applicationintegration platform. Using TIB/MessageBroker,

messages can be transformed where input andoutput messages use different transport protocolsand different wire formats. Messages can be routed

based on message content resulting in tightlyintegrated content-based routing functionality. Thecentral component in TIB/MessageBroker is theMessageBroker Engine, which supports standardobjects known as plugins that connect to a transport

to get and send messages. Predefined plugins areavailable for TIBCO transports such asTIB/Rendezvous, persistent stores such as file or

database, and Internet transports such as HTTP,FTP, POP and SMTP. In addition, a large set ofpredefined functions is available. Because thepredefined plugins and functions are built using theTIB/MessageBroker Java API, custom plugins andfunctions can be easily created and made available

in TIB/MessageBroker.

Integration Scenario - BusinessRequirement

The Business requirement is to provide a unifiedapproach to the customer to handle all theirapplication security requirements necessitated bythe OSS/ BSS system . This necessitates designing,

developing and managing the entire OSS/BSSsystem. The system encompasses implementingtechnology solutions to all business processes

including Marketing, Sales, Service Provisioning,


27/37


24

Customer Care, Billing, Service Assurance andanalysis using Data Warehousing and Data Mining.

The end user of the solution is a leading TelecomService provider and is in the business of providingbroadband services, fixed line, and Mobile telephonyservice.

Business Solution

The solution includes integration of innovative

processes and technologies within the solution andto present a single sign on to the entire set of

heterogeneous applications used for Billing andCustomer Care, Service provisioning, Serviceassurance, Order Management and Decision SupportSystem

The solution provides integration of the following

systems -

a) Billing and Customer Care System

b) Order and workflow management System (Wisor)

c) Line Plant management System (A NetworkInventory elements management system)

d) Service Provisioning and Service AssuranceSystem (HSS BMS-SPP)

e) Network Elements (MSC, HLR)

f) Decisions Support System (HSS DSS solution,

Informix Data mining solution).

Figure 13 illustrates an integration model in a

business scenario.

OMW Administrator

Network

Element

LP & M

Administrator

BCC

Administrator

Customer Service

RepresentativeDSS User

Mediation

andProvisioning

Order

Managementand Workflow

Line Plant

and InventoryManagement

Billing and

CustomerCare

HTTP

1

Decision

Support

System

Database

Database

Integration Broker

Business Rules

7 45 23 6

6 7342 5

8

Figure 13: Integration Model

The integration flow between various systems canbe understood in the following steps:

1. A customer walks in and his demographic profileand service details are first captured by the CSRusing the Billing and Customer Care systemclients.

2. The Billing and Customer Care system updatesits database with the details and notifies theOrder management and workflow managementsystem about the new customer for furtherprocessing.

3. The workflow management system creates anorder for the new subscriber updates its

database with the subscriber details and notifies


28/37


25

the Line plant management system for furtherprocessing.

4. The Line plant management system check itsinventory, and network capacity and serviceassurance capabilities and executes the orderand notifies back to the work flow management

system about its completion. In addition to this,the Line Plant system captures the entireexternal plant network of Client on a digital mapof the city, facilitating the management of thenetwork to be visualized on a desktop by the

authorities concerned.

5. The Order and workflow management systemreceives the message of the completion orderfrom the Line plant updates its databases andsend the details to the Billing System

6. The Billing systems receives the request from

the Work flow management system updates thedata in it to the database and send serviceprovisioning messages to the Serviceprovisioning and Assurance system (Mediation)

7. The Mediation system send a provisioningmessages to the NEs elements based on thecustomer numbering profiles and based on theresponse from the NE sends back thepositive/negative messages to the Billingsystem.

8. The billing system records the message in thedatabase and sends a response back to theWorkflow management system indication thecompletion of the whole process.

9. The Billing System also notifies the CSR aboutthe completion of the completed order.

10.From time to time historical data are transferredfrom the billing system / Work flowmanagement system and Line Plantmanagement system to the Decisions supportsystems for data mining and reporting

Table 1 describes the billing process.

Table 1: Billing System Process

Step Source Dest inat ion Descr ipt ion

1 Customer Service Representative Billing and CustomerCare (BCC)

A customer walks in to the CSRand places an Order. CSR Client

will contact the BCC to place theorder

2 Billing and Customer Care Order Managementand Work flow

BCC will pass on the order toOrder Management System

3 Order Management and Work flow Line Plant andInventoryManagement

Order Management System willpush the details to the Line plantinventory management system tocheck the status of networkavailability and for Numberprovisioning.

4 Line Plant and Inventory Management Order Management

and Work flow

Line Plant Inventory

Management system will updatethe Order Management systemabout the status of the

availability..

5 Order Management and Work flow Billing and CustomerCare

If the Order can be servicedimmediately, the Order

management System will conveya positive message to BCC. Elseit will send back a status.

6 Billing and Customer Care Mediation andProvisioning

In case of a positive messagefrom Order Management, the


29/37


26

Step Source Dest inat ion Descr ipt ion

BCC will ask the Mediation andProvisioning System to provide

the network elements requiredfor the service.

7 Mediation and Provisioning Billing and CustomerCare

Mediation and Provisioningsystem will notify the BCC aboutthe status after sending aprovisioning message to networkelements.

8 Billing and Customer Care Customer ServiceRepresentative

The BCC will convey the CSRabout the result of the orderplaced, which will be finally

conveyed to the end customer.

Benefits to the Customer

The total solution offers a single security umbrellaenforcing a centralized application security policyacross the entire portal through single sign onfeature. This implies a heavy reduction of

administration costs to the customer. The customercan achieve high amount of cost saving as thenecessity of increased help desk personnel isremoved.

The productivity of every end user is enhancedthrough single sign on, as the amount of time takento log into each application is saved. This alsoremoves the associated login problems to eachapplication.

The centralized user-provisioning feature results inreduction of manual intervention for updating userprofile in each application. The automatic bi-directional synchronization of user profile updatesenable the administrators and the organization tomaintain data int

Documents

Enterprise Application Integration Reference Manual