This chapter includes the following sections:
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.
Using the local transport in multiple proxy service flows ensures support for the following capabilities:
Efficient and secure communication.
Propagation of transactions and transactional behavior.
Propagation of security context 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.
Local transport-based proxy services can only be invoked by other proxy services, not by other clients. The invocation is optimized by Oracle Service Bus. Local proxy services do not have a 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, which 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.
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 efficiently.
For information about configuring message handling for proxy services, see Section 4.3.4, "Proxy Service Message Handling Configuration Page."
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.
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.
When chaining local proxy services, SOAP faults in the $fault variable are not automatically propagated from one proxy service pipeline to another. Consider the following example:
Client > P1 > P2 > Business Service > Back-end Service, where P1 and P2 are proxy services.
If a SOAP fault occurs in the back-end service, it is propagated to the $fault variable in P2. However, the SOAP fault value in P2 is not automatically propagated to the $fault variable in P1 and is therefore not returned to the client.
To propagate the SOAP fault from one proxy to another:
In P2, add an error handler that contains a Reply with Failure action. See "Adding Reply Actions" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus. This returns the SOAP message with fault information contained in the $body.
In P1, transform the $body as necessary to return the desired SOAP error details to the client.
For more information on how Oracle Service Bus handles SOAP faults, see "Generating the Error Message, Reporting, and Replying" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
You can attach Oracle Web Services Manager (OWSM) service policies to local proxy services, which lets you apply specific security controls to messages arriving at each local proxy.
This section describes how OSB processes WS-Security at run time when a proxy service forwards messages with security headers to other proxy services, such as local proxies. Message forwarding occurs through actions such as route, service callout, and publish.
Proxy services do not perform outbound WS-Security processing when forwarding messages to other proxy services. The following figures illustrate this behavior, showing WS-Security configurations in different proxy-to-proxy scenarios. Use these scenarios to understand the behavior so that you can successfully use OWSM service policies on local proxy services that receive messages from other proxy services.
The following scenarios show a front-end proxy service forwarding messages to local proxies. However, the behavior described in this section also applies to proxy-to-proxy invocations regardless of transport type.
Figure 31-3 shows a client with a client policy sending a message to a front-end proxy that could have any of the following characteristics:
The front-end proxy could be active and contain an OWSM policy that performs inbound processing on all WS-Security headers in a request or only a subset of those headers. For example, it might process the authentication policy but not the message protection policy when the request contains both authentication and message protection headers. The proxy could also contain a non-security policy such as an OWSM log policy.
The front-end proxy could be passive and contain an OWSM policy.
The front-end proxy could contain no OWSM policy.
In each of these cases, the front-end proxy encounters at least one security header in the message. The proxy service passes this message without performing outbound WS-Security processing to the local proxies. The local proxies may or may not contain OWSM policies.
In Figure 31-3, Local Proxy 2 receives the message without throwing an exception, because the message contains the expected security headers. Even if the Front-end Proxy contained a policy that performed partial security processing (for example, authentication processing but no message protection processing), the forwarded message would still contain security headers.
Figure 31-4 shows a client with a client policy sending a message to a front-end proxy. The front-end proxy is active and contains an OWSM service policy that processes all WS-Security headers in the message. The inbound service policy is processed, which strips the message of its security headers. Because the front-end proxy is forwarding the message to other proxies, no outbound WS-Security processing is performed, and the message without security headers is forwarded to the local proxies. One local proxy contains an OWSM service policy that expects security headers, and an exception is thrown when the message arrives without those headers. The other local proxy contains an OWSM non-security policy where no enforcement occurs, so the message without security headers passes through successfully.
The behavior described in this section does not apply to proxy services that contain WLS 9 policies. When a proxy service forwards a message to another proxy service that contains a WLS 9 policy, the forwarding proxy performs outbound security processing. For more information on WLS 9 policies, see Chapter 51, "Using WS-Policy in Oracle Service Bus Proxy and Business Services."
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.