Upload
smruti2012
View
237
Download
0
Embed Size (px)
Citation preview
7/29/2019 Enterprise Application Integration Reference Manual
1/37
Enterprise Application Integration
White Paper
7/29/2019 Enterprise Application Integration Reference Manual
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.
7/29/2019 Enterprise Application Integration Reference Manual
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
7/29/2019 Enterprise Application Integration Reference Manual
4/37
Enterprise Application Integration
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
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
7/29/2019 Enterprise Application Integration Reference Manual
5/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
6/37
Enterprise Application Integration
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/29/2019 Enterprise Application Integration Reference Manual
7/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
8/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
9/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
10/37
Enterprise Application Integration
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.
7/29/2019 Enterprise Application Integration Reference Manual
11/37
Enterprise Application Integration
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.
7/29/2019 Enterprise Application Integration Reference Manual
12/37
Enterprise Application Integration
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.
7/29/2019 Enterprise Application Integration Reference Manual
13/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
14/37
Enterprise Application Integration
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.
7/29/2019 Enterprise Application Integration Reference Manual
15/37
Enterprise Application Integration
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.
7/29/2019 Enterprise Application Integration Reference Manual
16/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
17/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
18/37
Enterprise Application Integration
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.
7/29/2019 Enterprise Application Integration Reference Manual
19/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
20/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
21/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
22/37
Enterprise Application Integration
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.
7/29/2019 Enterprise Application Integration Reference Manual
23/37
Enterprise Application Integration
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,
7/29/2019 Enterprise Application Integration Reference Manual
24/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
25/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
26/37
Enterprise Application Integration
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,
7/29/2019 Enterprise Application Integration Reference Manual
27/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
28/37
Enterprise Application Integration
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
7/29/2019 Enterprise Application Integration Reference Manual
29/37
Enterprise Application Integration
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