At the most basic level, a TIBCO Adapter receives data available from a source application or sends data to a target application.
This is based on a service architecture. Services are abstractions that describe how adapters work together with other applications.
An adapter generally supports publish/subscribe and request/response interaction modes. The following table summarizes the adapter interaction modes and adapter services introduced in this section.
Publish/Subscribe Interactions
Publish/subscribe interactions are driven by events, such as the arrival of data or a timer signaling that a specified interval has expired.
The following services are available for publish/subscribe interactions.
Publication Service:-
Publication Service recognizes when business events happen in a vendor application, and asynchronously publishes the event data in real time to interested systems in the TIBCO environment.
For example, a “Publication Service” service can publish an event each time a new customer account is added to application X, as shown in the following figure.
Other applications that receive the event can then update their records just as the original application did.
Subscription Service:-
Subscription Service gets information about business events from the TIBCO environment, and asynchronously writes the information into a target application.
Referring to the previous example, a “Subscription Service” service can subscribe to events that indicate the creation of a new customer and then enter the customer information into target application Y, as shown in the following figure.
Request/Response Interactions :-
In addition to asynchronously publishing and subscribing to events, an adapter
can synchronously retrieve data from or execute transactions within a vendor
application.
Demand-driven computing suits distributed applications that require
point-to-point messages, that is, a request and a response. In request/response
interactions, a data provider coordinates closely with a data consumer. A provider
does not send data until a consumer requests it. The consumer listens until it
receives the reply, and then stops listening (unless it expects further installments
of information). This is useful for actions such as adding or deleting business
objects.
The following services are available for request/response interactions:
• Request-Response Invocation Service
• Request-Response Service
Request/response is the default invocation protocol for both Request-Response
Invocation Service and Request-Response Service, but you can also use both
services asynchronously when the invocation protocol is one way. Not all
adapters support the one way protocol, but for those that do, the implementation
of the protocol is consistent.
Request-Response Invocation Service :-
Request-Response Invocation Service acts as a proxy, giving the vendor application
the ability to invoke services on TIBCO infrastructure. TIBCO infrastructure may
perform a series of steps to complete the request, including invoking services on
other applications through TIBCO infrastructure and other adapters.
For example, a Request-Response Invocation Service service sends a request
message from the vendor application X to another application Y through TIBCO
infrastructure. After application Y processes the message, it returns the result to
TIBCO infrastructure. Then the adapter receives the response and sends it back to
application X, as shown in the following figure.
Request/reply is the default invocation protocol for Request-Response Invocation
Service, but it can also be used asynchronously where the invocation protocol is
one way. Not all adapters support this, but the implementation is consistent
across all adapters that support the one way protocol.
Request-Response Service :-
Request-Response Service is similar to Request-Response Invocation Service, except
that the roles are reversed. The vendor application is now the provider of the
service, instead of the requester or initiator of the service.
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.
Referring to the previous example, a Request-Response Service service sends a
request message from TIBCO infrastructure to application Y. The adapter gets a
response from application Y and returns it to TIBCO infrastructure, which then
sends the response to application X, as shown in the following figure.
Hari's Technical Space 
You must be logged in to post a comment.