Copyright © TIBCO Software Inc. All Rights Reserved

Design Concepts

This section provides further details on the operational features of TIBCO API Exchange Gateway.

The core engine contains the following main sub-components:

•	Facade  The facade provides the interfacefor the gateway to receive requests for a given API with a given binding (for example, REST over HTTP or SOAP over JMS).

•	Router  The router receives requests from the facade and routes them to the appropriate target service handler.

•	Target  The target component calls the appropriate external service to execute the request.

Facade Service

A facade service is any application service or API that the gateway offers. Typically the service is an intermediary to one (or more) target services outside the gateway.

A facade service may also be known as a proxy service or virtual service, especially if the interface of the facade and target services are the same. The gateway facilitates a loose coupling between the facade and target service by managing interfaces, policies and configuration information for either the facade service or target service.

Policies applied to a facade service are enforced by the gateway and include decryption, validation, throttling, and authorization.

Target Service

A target service is an external endpoint that the gateway may call during processing of a request. Policies applied to a target service are enforced by the gateway and include encryption, credential mapping, throttling, and load balancing.

Figure 4 Facade Service and Target Services

Message Processing Life Cycle

The gateway core engine uses a staged event-driven architecture. Request and response messages are processed internally as events with processing steps determined dynamically by the engine based on applicable policies.

Mappings and Transformations

TIBCO API Exchange Gateway provides message transformations using mappings. Combined with throttling, this allows you to implement business agreements as enforceable policies.

TIBCO API Exchange Gateway provides transformation of request and response messages at the following four points:

•	Facade to Router  After the request has been received by the facade request handler and before it is been passed to the router.

•	Router to Target  After the request has been routed but before it is passed to the service endpoint handler.

•	Target to Router  After the response has been received from the target handler and before it is passed to the router.

•	Router to Facade request handler  After the response has been routed from the router to the facade request handler and before the response is sent back to the original requestor.

Additionally, facade request and response transformations can be overridden on a partner specific basis.

For more information on mappings and transformations, see the “Mappings and Transformations” section in Chapter 5, “Transaction Pipeline Processing,” in the TIBCO API Exchange Gateway User’s Guide.

Throttle Policies

Using throttle policies, you can enforce usage or other limits, and define the maximum number of requests that are handled by a facade or target operation in a defined time interval. You must define the maximum count and the time interval for a throttle.

Throttles define a condition for a type and metric (entity). API Exchange Gateway checks the condition for an incoming request before processing the request. For example, you can define a condition to allow only 5 client requests within 10 seconds to the backend service for a partner request.

There are two main categories of throttles:

•	Facade throttles  Support service level agreements with consumers, for example, Partner and Partner plus Operations.

•	Target throttles   Support service level agreements with providers, and are applied on the Target Service operation.

Throttle Types

There are four kinds of throttles:

•

Rate  The rate throttle is a simple throttle that allows the requests to pass-through until a limit is reached for a time interval. The rate throttle is always increased on the request. A throttle may be incremented by a count of requests, size of a payload or it can be based on content; for example, a throttle can be based on order totals.

•	Quota  The quota throttle is similar to the rate throttle, but it uses a much larger count over much longer intervals (such as days). The quota throttles are increased on the request. For a quota throttle, you must define throttle interval (in hour) and throttle max count.

•

High Water Mark  (concurrent requestor) High Water Mark throttle is similar to the Rate Throttle, but this throttle also decrements the count after the passed-on requests are completed and the response is ready to return to the requestor. This means that the High Water Mark throttles are increased on the request and decreased on the response. You must define a throttle max count for a high water mark throttle.

•	Error  Error Throttles act as a Rate Throttle in logic, but this throttle counts the error responses, as opposed to the requests. The throttle count of an error throttle is increased on the error responses.

Routing

Routing allows the directing of requests to specific target services based on operation, partner, version or message content or operation.

Message Exchange Patterns

A message exchange pattern (MEP) defines the sequence and cardinality of messages sent between the provider and the consumer for an interaction. MEPs contain both normal and fault messages. The gateway supports several different styles of message exchange as well as the ability to mediate between them.

The service gateway supports the following patterns:

•	Request/Acknowledge (One-Way)  A consumer sends a message to a provider that provides a status response. This is also known as Fire and Forgot, and In-Only.

•	Synchronous Request-Response (Sync)   A consumer sends a message to a provider with expectation of response over the same client connection. The provider sends a response message or fault and the consumer responds with a status.

•	Asynchronous Request-Response (Async)   A consumer sends a message to a provider with expectation of a callback of a response. The provider acknowledges the request. The provider then sends a response message or fault and the consumer responds with a status.

•	Consume Message  A provider sends a message to a consumer.

The service gateway supports different MEPs between (1) the facade consumer and the facade service and (2) between the target consumer and the target service.

Orchestration

TIBCO API Exchange Gateway provides the following orchestration models:

•	Parallel Orchestration (also called Enumeration)

With parallel orchestration, a single inbound request is split into a set of multiple outbound sub-requests. Each sub-request may be routed differently to various service endpoints. After processing and receiving the responses for each sub-requests, all responses are recombined into a single response message for the original inbound request.

•	Sequential Orchestration

Using sequential orchestration, you can access multiple target endpoints by making a number of sequential calls to fulfill or authorize a request. With sequential orchestration, there is a primary outbound target invocation, preceded by one or more secondary target invocations.

Sequential orchestration might use the associative and responses cache features to accelerate the processing of subsequent requests, which helps minimize the load on back-end systems.

Partners

Using TIBCO API Exchange Gateway, you can define partners and partner groups and specify processing for them. You can configure the following:

•	Information that identifies a partner.

•	A partner group that the partner belongs to.

•	The throttle chain that is applied to any requests sent by a partner in that group.

Caching

Caching improves performance and reduces the load on back-end systems.

TIBCO API Exchange Gateway includes a distributed cache based on the in-memory data grid TIBCO® ActiveSpaces.

The association cache is generally used to cache service responses to improve response time and resilience and to reduce load on target services. The cache is also often used to store common reference data used to enrich a response such as to look up account information from a device identifier.

Copyright © TIBCO Software Inc. All Rights Reserved