APPENDIX 1 EAI TOOLS

Transcription

1 87 APPENDIX 1 EAI TOOLS A 1.1 WEBMETHODS COMPONENTS A 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 ports. A Developer services. The developer is the component through which we write our integration A few important built-in services are listed below pub.client:http: Issues an HTTP request that you specify and returns the HTTP response.

2 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 processor on the Integration Server. : Registers a service as a SOAP

3 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.

4 90 A 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 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.

5 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 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.

6 92 Fig. A 1.2 Territory Graph A 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:

7 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 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 JDBC Adapter Components The JDBC Adapter enables you to configure the following components:

8 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 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

9 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 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.

10 96 A 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.

11 97 APPENDIX 2 IMPLEMENTATION SCREENSHOTS A 2.1 Insurance Application Fig. A 2.1 Business service-getallpolicies

12 Fig. A 2.2 Dispatcher service 98

13 Fig. A 2.3 Adapter service 99

14 100 A 2.2 Software Organization Fig. A 2.4 Skill set document Fig. A 2.5 Password Changed document

15 Fig. A 2.6 Finance document 101

16 Fig. A 2.7 Adapter Connection 102

17 Fig. A 2.8 Finance Module 103

18 Fig. A 2.9 Finance Integration service 104

19 Fig. A 2.10 HR Integration service 105

20 Fig. A 2.11 inserthr Adapter service 106

21 Fig. A 2.12 Processing Salary Update 107

22 108 A 2.3 Vitria Screenshots Fig. A 2.13 newemployeeevent Fig A 2.14 Finance

23 Fig HR 109

24 110 APPENDIX 3 LIST OF PUBLICATIONS 1. Pavithra Murali and Thamarai Selvi (July 2005) Event-Driven Application Integration ISBN: 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)