31 Local Transport

This chapter provides information about the Oracle Service Bus local transport. It includes the following topics:

31.1 Introduction

Commonly, service bus architectures include complex message flows in which messages are routed through multiple proxy services that are organized into larger multiple proxy service flows. Individual proxy services in these multiple proxy service scenarios route, publish, or call out to the next proxy service in the flow.

The reason for a multiple proxy services design is to support modularity and compartmentalization of the various components of the end-to-end message flow.

The individual proxy services in a multiple proxy service flows need to:

  • Communicate efficiently and securely.

  • Allow transactions and transactional behavior to be propagated

  • Allow security context to be propagated so that the identity can be propagated end-to-end. The security context propagation also allows the client of the first proxy service in a multiple service flow to be authorized by the proxy services that are subsequently invoked in the flow—thus supporting fine-grained access control generic headers in the local transport.

  • Using the local transport for proxy services ensures support for these capabilities.

31.2 Features and Characteristics of Local Transport Proxy Services

Local transport-based proxy services can only be invoked by other proxy service, not by other clients. The invocation is optimized by Oracle Service Bus. Local proxy services do not have an URI. However, there are no constraints on the service and interface types supported by local transport proxy services. The one exception is that SAML is only supported in a pass through scenario.

If the quality of service (QoS) for an invoking proxy service is defined as Exactly Once, the transaction of that service is propagated to the local transport proxy service.

In other words, the invoked local transport proxy service inherits the transactional behavior of the invoking proxy service. A proxy service can authenticate at the transport level or the message level. If it is enabled, the effective client is the message-level authenticated client. If the message-level authenticated client is not enabled, then the transport-level authenticated client is the effective client (if that is enabled). If neither the message-level nor the transport-level authenticated client is enabled, the anonymous client becomes the effective client.

When a proxy service invokes a local transport proxy service, the effective client of the invoking proxy service becomes the transport-level client of the invoked local proxy service. A local transport proxy service can authorize this client for access with an access control policy. In this way, it is possible to propagate the client of the first proxy service to all the subsequent proxy services in the overall end-to-end message flow.

Local transport proxy services support user-defined transport headers. Consider a scenario in which a proxy service uses the HTTP transport; it routes to a local proxy service and the HTTP proxy service passes headers to the local proxy service using the Transport Header action. In this scenario, if the HTTP proxy service received the Content-Type header, this header is available as a user header in the local transport and is therefore accessible through the standard user header, instead of as a typed transport header.

You can invoke a local transport proxy service from the Oracle Service Bus test browser. Metrics are collected for a local transport proxy service in the same way as they are any other service.

31.3 Message Handling for Local Transport Proxy Services

You can specify message handling options for local transport proxy services.

Specifically, you can enable local transport proxy services to decode and parse inbound messages in MTOM/XOP format and to send responses using the MTOM/XOP format, when appropriate. SOAP Message Transmission Optimization Mechanism (MTOM) is a method of sending binary data to and from Web services. MTOM uses XML-binary Optimized Packaging (XOP) to transfer the binary data.

Similarly, when local transport proxy services are chained through an HTTP transport proxy service, the local transport proxy services inherit the setting of whether attachments are paged to disk and processed in a streaming fashion (without buffering the attachment contents in memory).

That is if an outer HTTP transport proxy service is configured to page attachments to disk, the chained local transport proxy services also process attachments in this fashion. This enables the proxy service to process large attachments robustly and efficiently.

For information about configuring message handling for proxy services, see Section 4.3.4, "Proxy Service Message Handling Configuration Page."

31.4 Usage of Local Transport Proxy Services

A common scenario that can be supported using local transport proxy services is one in which a proxy service needs to be invoked using different transports. This can be achieved by putting a set of front-end proxy services (one service per transport) in front of a local transport proxy service in the path of the message flow.

These front-end proxy services simply route messages to the local transport proxy service. The following figure illustrates this scenario.

Figure 31-1 Using Local Transport to Implement Convergence

Description of Figure 31-1 follows
Description of "Figure 31-1 Using Local Transport to Implement Convergence "

Another common scenario is one in which an Any SOAP or XML type proxy service acts as a front-end to different enterprise systems. This front-end proxy service can receive messages in a variety of formats and uses a technique common to all these messages (for example, a WS-Addressing SOAP header) to route the messages to an appropriate local transport proxy service.

In this scenario, the front-end proxy service is acting as a generic router with little knowledge of the enterprise systems or the message formats and semantics. To further abstract the knowledge of the routing rules at design time, the front-end proxy service can use dynamic routing to route messages to the local transport proxy services. For an example of how dynamic routing is used in the proxy services, see "Using Dynamic Routing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

Each of the local transport proxy services to which messages are routed from the front-end service in turn acts as a front-end proxy service for a specific business service. The local transport proxy services are aware of the message format required by the business services to which they route.

In this scenario, these local transport proxy services act as functional proxy services. The roles of a functional proxy services are to enforce access control for invoking a particular business service, and to perform any transformation of the messages required to invoke the target business service correctly. The following figure illustrates this scenario.

Figure 31-2 Using Local Transport to Access Multiple Business Services

Description of Figure 31-2 follows
Description of "Figure 31-2 Using Local Transport to Access Multiple Business Services"

31.5 Limitations

The limitations of the local transport are:

  • You can invoke the proxy service using the local transport only from another proxy service.

  • The proxy services using the local transport cannot be published to the UDDI.

  • A local transport proxy service cannot process inbound WS-Security SAML tokens.