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 server’s

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 fields—standard 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

BusinessWare’s 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 application-

specific 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 Service-

Oriented 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 Service-

Oriented Application Integration” – Journal Anna University (Submitted)