|
|
AquaLogic Service Bus (ALSB) can leverage WebLogic Integration (WLI) as a service end point. WLI business processes and composite applications can act as business services (service providers) or as service clients (service consumers). The JPD transport allows ALSB to natively invoke WLI business processes (JPD) using RMI synchronously. Note that the JPD transport can invoke only WLI business process and cannot invoke any Java Web services.
The JPD transport provides access to WLI processes along with support for both transaction and security context propagation from ALSB to WLI. Although ALSB does not manage conversions, an external client can interact with conversational WLI processes using the JPD transport as long as the client is conversational aware. That is, the client must be either a JPD client or a web service conversational client and must have support for generating and understanding conversational headers. For more information, see “About Conversation Management” in Calling Business Processes in Guide to Building Business Processes.
The JPD transport is an outbound transport and can be used to invoke only external services. This implies that you can configure the JPD transport only with business services. There is no support for inbound transport and so this transport cannot be configured for ALSB proxy services.
JPD or web service (WS) clients can send a request message to an ALSB proxy service, which after processing forwards the message to the WLI business process using the ALSB business service configured with JPD transport. For more information, see Typical Scenario.
You can configure WLI as a service client by importing the service client WSDL from ALSB into WLI, generating a Service Control, and adding a node in the business process to invoke the service. You can expose WLI to ALSB by generating the WSDL file from the existing business process and registering with ALSB as a business service.
A business process is a collection of interrelated tasks associated with a specific organizational requirement. WLI Business Process Management (BPM) allows users to model and execute business processes that span multiple internal systems, external resources, and users. From the BPM perspective, the enterprise is a set of business services that are accessed through controls and can be orchestrated to model a business process. WLI supports synchronous and asynchronous communications and stateless and stateful processes.
Business processes can expose their functionality to clients in several ways, including through WSDL files.
This section describes the key features that are supported by the JPD transport.
The JPD transport supports the following service types:
The incoming message should be in compliance with the WLI business process semantics. For WSDL and SOAP-based business services, the request should be a SOAP message that can be understood by a WLI business process. For an XML-based business service, the XML should be a self-contained document with a method name and parameters serialized to XML along with the namespace.
| Note: | JPD transport provides support for SOAP 1.1 and limited support for SOAP 1.2. |
JPD transport does not support:
@ WSSecurityCallback and @ WSSecurityService annotations in a WLI business process file (JPD) when the business process is invoked through the JPD transport. If required, you may enable WS security on the ALSB proxy service that is used to invoke the business process. You need not enable WS security on the JPD business service.
The Quality of Service (QoS) can be Best-Effort or Exactly-Once and can be configured in the message flow.
For messages sent over RMI, the security and transaction context may be propagated from the client to ALSB. Security context is propagated to the remote WLI end point. The transaction can be propagated based on QoS settings and value of the Propagate-Transaction option set while configuring a business service to use the JPD transport. Propagating the security context from ALSB to WLI may require enabling domain trust between domains. Domain trust is required when ALSB and WLI are on different domains. Domain trust is not required when credentials specified in a service account are used for invoking the WLI business service.
While configuring a business service to use the JPD transport, you can set the Propagate-Transaction option to specify if an existing transaction in ALSB can be propagated to the WLI business process or not. The propagation of the transaction depends on the QoS parameters as listed below:
Best-Effort and:Propagate-Transaction option is not set, the call to the business process in not made in a transaction. Propagate-Transaction option is set, the call to the business process in not made in a transaction. Propagate-Transaction option is not set, the original transaction is suspended before calling the business process. Propagate-Transaction option is set, the original transaction is suspended before calling the business process.Exactly-Once and:Propagate-Transaction option is not set, the call to the business process in not made in a transaction. Propagate-Transaction option is set, the call to the business process in not made in a transaction and the business process runs its own transaction.Propagate-Transaction option is not set, the original transaction is suspended before calling the business process.Propagate-Transaction option is set, the call to the business process is made in the original transaction.
A typical scenario where the JPD transport can be used is as follows:
| Note: | Ensure that the incoming requests are compliant with the JPD semantics. That is, the file format of the WSDL, SOAP, or XML file should be as expected by the business process JPD file. |
An SLSB-named proxy dispatcher bean is registered on the WLI server and is used to handle requests from the JPD proxies. The JPD transport forwards the messages received by the business service to the SLSB, which in turn invokes the WLI business process.
Figure 1 shows a typical scenario where you can use the JPD transport.
Before you configure a business service, you may need to do any or all of the following tasks based on your requirements:
The system service account specifies the user credentials for the invocation of the WLI stateless session bean that the JPD transport uses to send incoming messages. If no service account is specified, the inbound request subject is used. If there is no inbound request subject, an anonymous subject is used.
The process service account specifies the user credentials for the invocation of the JPD. If no service account is specified, the inbound request subject is used. If there is no inbound request subject, an anonymous subject is used.
For more information, see Service Accounts in Using the AquaLogic Service Bus Console.
When you create a business service, you can associate it with a JNDI provider. For more information, see Adding JNDI Providers in Using the AquaLogic Service Bus Console and Configuring Business Services to use the JPD Transport.
| Note: | When a JNDI provider is not specified during the business service configuration, the default context is used. This implies that the service and the ALSB server are located on the same machine. When the call is co-located, serialization is skipped during service invocation. |
IIOP(S), T3(S), and HTTP(S) transport protocols can be used by the JNDI provider. The preferred communication protocol from ALSB to a WLS domain is T3 or T3S. If messages need to go through a firewall, you can use HTTP tunneling by using an HTTP provider url in the context and by enabling HTTP tunneling on the WLS server.
It is the responsibility of the administrator to ensure that the protocol supported by the JNDI provider is on the remote ALSB server.
If the JNDI provider is configured with a user name and password, IIOP and IIOPS protocols are not supported when WLI and ALSB are co-located on the same machine.
Because the JPD transport is an outbound transport, it can only be configured for a business service. When you create a business service from the ALSB Console, select WSDL, Any XML, or Any SOAP as the service type in the General Configuration page.
| Note: | Ensure that the incoming requests are compliant with the JPD semantics. That is, the file format of the WSDL, SOAP, or XML file should be as expected by the business process JPD file. |
Select the transport protocol as jpd in the Transport Configuration page. For information about:
With ALSB throttling, you can limit the amount of throughput to business services to support policy enforcement and prevent overloading of those services. For more information, see Throttling in ALSB in AquaLogic Service Bus Operations Guide.
Any JPD client that needs to receive callbacks needs to send the callback location (URL) as part of the initial request. This callback location specifies that the client is waiting to receive callbacks from the business process at the specified URL. To support callbacks in ALSB, you need to configure two message flows — one for request processing and the other for callback processing.
To use the JPD transport for invoking an asynchronous business process with callbacks through ALSB, you need to configure a callback proxy service. You can specify the location of the callback proxy service during the JPD business service configuration. Because callbacks are only supported over JMS, the callback proxy service must be configured over JMS. WLI sends the callback response and the initial callback location URL to the JMS queue associated with the callback proxy service as a JMS transport header BEA_WLI_Target_Callback_Location. You can use the $inbound message context variable to retrieve the initial callback location (sent using the JPD client request) and configure the business service to send the callback to the actual JPD callback client.
You can configure the JPD transport-based business services to handle application errors by specifying whether or not to retry business service end point URIs when application errors occur. See “Retry Application Errors” in Creating and Configuring Business Services - Transport Configuration page in Using the AquaLogic Service Bus Console.
An application error occurs when a JPD transport-based business service receives a SOAP fault as a response and the BEA-380001 error code is generated. If an error handler is configured for the response message flow, the error is handled according to the service configuration. Otherwise, the error is propagated back to the proxy service end point.
| Note: | When a response timeout or sequence timeout occurs for a request to a business service, the ALSB server tries to send the message to the next URI in the end point URI list based on the load-balancing algorithm. This behavior does not depend on the Retry Application Errors option. |
The JPD transport is not bound to any specific protocol and all the invocations happen over RMI. Therefore, there are no protocol-specific headers required by the JPD transport. You can pass any custom request headers as name-value pairs. JPD transport defines two headers that may be used by WLI to process a message. The transport headers are shown in Table 1:
|