87

APPENDIX 1
EAI TOOLS
A 1.1 WEBMETHODS COMPONENTS
A 1.1.1 Integration Server

The Integration Server Administrator is the utility we use to accomplish

administrative tasks. It is used to monitor server activity, examine log
information, add users, enable/disable services, and adjust the servers
performance features. The Integration Server provides an environment for the
orderly, efficient, and secure, execution of services. It decodes client requests,
identifies the requested services, invokes the services, passes data to them in the
expected format, encodes the output produced by the services, and returns output
to the clients. Additionally, the server authenticates clients, verifies that they are
authorized to execute the requested service, maintains audit-trail logs, and
promotes throughput-using facilities such as service result caching. The
Integration Server listens for client requests on one or more ports. The server
supports HTTP, HTTPS, FTP, and email ports.

A 1.1.2 Developer
The developer is the component through which we write our integration
services.

A few important built-in services are listed below

pub.client:http: Issues an HTTP request that you specify and returns the HTTP
response.

88

pub.date:getCurrentDate: Returns the current date as a Date object.

pub.db:execSQL: Executes the specified SQL statement.

pub.flow:debugLog : Writes a message to the server log.

pub.flow:getLastError: Obtains detailed information about the last exception

that was trapped within a flow.

pub.list:appendToDocumentList : Adds documents to a document list.

pub.publish:publish : Publishes a document locally or to the Broker.

pub.publish:publishAndWait : Broadcasts a request for a document from any

client subscribed to a specific document type. The service waits for the reply or
indicates that the pub.publish:waitForReply service should retrieve the reply later.

pub.publish:reply : Delivers a reply document to the requesting client.

pub.publish:waitForReply: Retrieves the reply for an asynchronous request. If a

reply is not available, the Integration Server continues to wait for the document
until

the

time

specified

in

the

waitTime

parameter

of

the

pub.publish:deliverAndWait or pub.publish:publishAndWait service elapses.

pub.soap.processor:registerProcessor : Registers a service as a SOAP

processor on the Integration Server.

89

pub.soap.utils:addBodyEntry : Inserts an entry into the body element of a

SOAP message.

pub.soap.utils:createSoapData : Creates an empty SOAP object.

pub.soap.utils:getBody : Retrieves the body from a SOAP message as a single

node object.

pub.string:concat : Concatenates two strings.

pub.xml:documentToXMLString : Converts a document (IData object) to an

XML string.

pub.xml:loadXMLNode : Retrieves an XML document via HTTP or HTTPS,

parses it, and produces an XML node.

pub.xml:queryXMLNode : Queries an XML node.

pub.xml:xmlNodeToDocument : Converts an XML node to a document (an

IData object).

pub.xml:xmlStringToXMLNode : Converts an XML document (represented as

a String, byte[ ], or InputStream) to an XML node.

90

A 1.1.3 Brokers

The Broker Server mediates requests to and from network information

resources. Client applications publish and subscribe to information in the form of
documents. The Broker Server manages the flow of documents among clients,
Brokers, and various applications. It automatically routes, queues, and filters
documents. A Broker is where the client programs connect, where document
types are stored, and where client queues and subscriptions are monitored and
stored. Client groups provide a method for setting important properties for a
group of Broker clients. Broker Administrator uses the browser on the local
machine and the Integration Server, which can be anywhere in the network, to
connect to a Broker Server.

A 1.1.3.1 Territories

The Broker-to-Broker feature allows communication among two or more

Brokers. This Broker-to-Broker communication allows applications and adapters
to be spread around your company and still communicate with each other. When
using the Broker-to-Broker feature, Brokers join a territory. All Brokers in a
territory share the same document types and client groups. This shared view of
data and semantics makes communication between client applications possible.
Each Broker communicates directly with every other Broker in its territory, as
shown in the following diagram. This direct connection ensures the fastest
communication between Brokers.

91

Fig. A 1.1 Territory

In the diagram above, the application Client 1 can communicate not only
with Client 2 on the same Broker, but also with Clients 3 and 4 on Broker D.

A 1.1.3.2 Gateways

A territory gateway is a connection between two territories, allowing the

transfer of documents between the territories. One broker in each territory is
designated to communicate with a companion broker in the other territory. Each
of the two Brokers, referred to as gateway Brokers, belongs to its own territory,
but can share document types with its companion Broker across the gateway. By
controlling publish and subscribe permissions and security across the gateway, it
is possible to create a firewall between territories.

92

Fig. A 1.2 Territory Graph

A 1.1.4 Trading Networks

A trading network is a set of organizations that have agreed to exchange

business documents. Participants might include strategic partners, buyers,
suppliers, and marketplaces. Examples of typical business documents are
purchase orders, order statuses, purchase order acknowledgements, invoices, as
well as other domain-specific business documents. The organizations in your
network are referred to as trading partners (partners). A trading partner can be
any system, within or outside your enterprise that produces or consumes business
documents. Trading Networks saves the information that it collects about partners
in profiles. A profile is made up of fields. To define the information that you
want to collect about your partners, you set up profile fields. There are two types
of profile fieldsstandard fields and extended fields:

93

Standard fields are webMethods-defined fields that incorporate the majority of

the information that you will want to collect about a partner.

Extended fields are fields that you define to extend the standard profile that
webMethods provides out-of-the-box. If you want to collect additional
information about your partners that is not covered by the standard fields, you can
define extended fields.

A Trading Partner Agreement (TPA) in Trading Networks is a set of

parameters that you can use to govern how documents are exchanged between
two trading partners. To use a TPA, both partners in the agreement must have
existing profiles in Trading Networks. Trading Networks uses the profiles to
ensure that the partners are valid for that Trading Networks system.
A 1.1.5 JDBC Adapter

The webMethods JDBC Adapter is an add-on to the webMethods

Integration Platform that enables you to exchange data with relational databases
through the use of a JDBC driver. The JDBC Adapter provides a set of user
interfaces, services, and templates that enable you to create integrations with
databases using a JDBC driver. The adapter is provided as a single package that
must be installed on the webMethods Integration Server.

A 1.1.5.1 JDBC Adapter Components

The JDBC Adapter enables you to configure the following components:

94

Adapter connections: Enable the Integration Server to connect to database

systems at run time. You must configure an adapter connection before you can
configure adapter services or adapter notifications.

Adapter services: Enable the Integration Server to initiate and perform database
operations on a database. For example, an adapter service could enable a trading
partner to query your inventory database to determine whether a particular item is
currently in stock. You configure adapter services using adapter services
templates, which are provided with the JDBC Adapter.

Adapter notifications: Monitor a database and notify the Integration Server

when an action (not initiated by the Integration Server) has occurred on a
particular database table. For example, an adapter notification could notify the
Integration Server when an update operation was performed on a particular
database table.

A 1.2 VITRIA BUSINESSWARE

BusinessWare components are organized into three product categories:

Communicator, Connectors, and Automator. Components within a given product
category interoperate to implement the basic eBusiness solution functions.

A 1.2.1 Communicator

Communicator handles communication within BusinessWare, and together

with the Connector, lets customers, partners, enterprise systems, and
BusinessWares own internal components exchange messages and information

95

using a common interface. Messages are exchanged through the Communicator in

the form of events. An event is a BusinessWare entity that indicates when
something has happened in the real world. Events not only carry the message that
something has happened, but also carry any data associated with that occurrence.

A 1.2.2 Connectors

Connectors are the system integration components of BusinessWare.

Connectors move data between systems
Connectors can do the following:

Subscribe to events on a channel, transform or translate the message

carried by the event into a format used by your enterprise system, and
relay that message to the enterprise system
Acquire messages in an application-specific format from your enterprise
system, transform or translate the message into a BusinessWare event
interface, and publish that event onto a Communicator channel
Subscribe to events on a channel, transform or translate the message
carried by the event into a format used by your business partner, and relay
that message over the Internet to your business partner
Acquire messages from another business over the internet, transform or
translate the message into a BusinessWare event interface, and publish that
event onto a Communicator channel.
Acquire data in an application-specific format from your enterprise
system, transform or translate that data into a secondary applicationspecific format, and relay that data to a file.

96

A 1.2.3 Automator

Automator refers to the set of BusinessWare components that support and

execute business process management. Automator executes business processes
and workflow by automatically managing information across enterprise business
systems, customers, and partners.

97

APPENDIX 2

IMPLEMENTATION SCREENSHOTS

A 2.1 Insurance Application

Fig. A 2.1 Business service-getAllPolicies

98

Fig. A 2.2 Dispatcher service

99

Fig. A 2.3 Adapter service

100

A 2.2 Software Organization

Fig. A 2.4 Skill set document

Fig. A 2.5 Password Changed document

101

Fig. A 2.6 Finance document

102

Fig. A 2.7 Adapter Connection

103

Fig. A 2.8 Finance Module

104

Fig. A 2.9 Finance Integration service

105

Fig. A 2.10 HR Integration service

106

Fig. A 2.11 insertHR Adapter service

107

Fig. A 2.12 Processing Salary Update

108

A 2.3 Vitria Screenshots

Fig. A 2.13 newEmployeeEvent

Fig A 2.14 Finance

109

Fig. 2.15 HR

110

APPENDIX 3

LIST OF PUBLICATIONS

1. Pavithra Murali and Thamarai Selvi (July 2005) Event-Driven

Application Integration
http://www.information-quarterly.org/cistm2005proc/pdfs/18.pdf ISBN:
0-9729562-8-X. Presented at CISTM (Conference on Information
Science Technology and Management)

2. Thamarai Selvi and Pavithra Murali (May 2005) Event-Driven ServiceOriented Application Integration IEEE Conference Poster Presentation.

3. Pavithra Murali (Nov 2005) Event-Driven Service-Oriented Architecture

for Enterprise Application Integration Congregation2006 (Submitted)

4. Thamarai Selvi and Pavithra Murali (Dec 2005) Event-Driven ServiceOriented Application Integration Journal Anna University (Submitted)