Copyright © Cloud Software Group, Inc. All Rights Reserved

Chapter 1 Introduction : Adapter Services

Adapter Services
Adapters are responsible for making information from different applications available to other applications across an enterprise. To do so, an adapter is configured to provide one or more services.
General Adapter Services
This section lists four kinds of services that can be found in most of TIBCO adapter products. Not all adapters provide all these services and some adapters may provide services not listed here. See Adapter Services for information about services available on TIBCO ActiveMatrix Adapter for IBM i.
Publication Service
An adapter publication service recognizes when business events happen in a vendor application, and asynchronously sends out the event data in real-time to interested systems in the TIBCO environment.
For example, an adapter can publish an event each time a new customer account is added to an application. Other applications that receive the event can then update their records just as the original application did.
Subscription Service
An adapter subscription service asynchronously acts, such as updating business objects or invoking native APIs, on a vendor application. The adapter service listens to external business events, which trigger the appropriate action.
Referring to the previous example, an adapter subscription service can listen for customer record creation events (happening in an application and published to the TIBCO infrastructure) and update another application.
Request-Response Service
In addition to asynchronously publishing and subscribing to events, an adapter can be used for synchronously retrieving data from or executing transactions within a vendor application. After the action is performed in the vendor application, the adapter service sends a response back to the requester with either the results of the action or a confirmation that the action occurred. This entire process is called request-response, and it is useful for actions such as adding or deleting business objects.
For example, an adapter receives a request message from the TIBCO infrastructure and sends it to an application. The adapter gets a response from the application and returns it.
Request-Response Invocation Service
An adapter request-response invocation service is similar to the request-response service, except that the roles are reversed. The vendor application is now the requester or initiator of the service, instead of the provider of the service. The adapter service acts as a proxy, giving the vendor application the ability to invoke synchronously functionality on an external system.
For example, the adapter sending a request message from application Y to application X. After it processes the message, it is returned to the adapter, which sends the response back to application Y.
Adapter Services Summary
Table 1 summarizes the services introduced in this section.
Choosing an Adapter Service
A business integration scenario drives the choice of one adapter service or another. This section provides a simple flow chart that helps you to choose the service to use.
Consider the following environment that involves application X, an adapter, and another application:
Figure 2 A Business Integration Scenario
 
In this scenario, data is exchanged between the application X and another application. The other application could be a customer management system, such as PeopleSoft, or another TIBCO application, such as TIBCO ActiveMatrix BusinessWorks.
To choose the adapter service to use, start by finding out where the scenario begins or what triggers it.
For example, when a new customer account is created in application X, must the account information be propagated through the adapter to the other application? Or does a batch business process in TIBCO ActiveMatrix BusinessWorks need information from application X to generate a report?
This question is the starting point of the decision chart provided in Figure 3.
 
Figure 3 Choosing an Adapter Service
Working through the decision chart, if the business process is the creation of a customer record in application X and if many other applications need to be updated when the event occurs, but no acknowledgements are required, the publication service should be used.

Copyright © Cloud Software Group, Inc. All Rights Reserved