Service Broker Control Run-Time Considerations
This section outlines some of the run-time issues you must consider when you are invoking a Service Broker control in your business process.
The topics covered in this section are:
Run-Time Rules for Service Broker Controls in Stateless and Stateful Business Processes
The number of transactions contained in a business process determines whether the process is stateless or stateful. For more information, see Building Stateless and Stateful Processes. This section covers some of the run-time issues you should consider when using a Service Broker control in stateless and stateful business processes.
The following rules govern the run-time operation of Service Broker controls in stateless and stateful business processes:
- In a stateless business process, the parent process makes a Simple Object Access Protocol (SOAP) or a non-SOAP invocation on the subprocess. The SOAP invocation is a generic process and the invocation is not simply the method called. In fact, a Web Services Description Language (WSDL) operation is what is actually invoked. For a non-SOAP invocation, the Service Broker control can make FORM-POST and FORM-GET requests. For more information on the supported message formats, see Supported Message Formats.
- In a stateless business process, a WSDL file is used to communicate interface information between the parent process and the subprocess. For more information on WSDL files, see WSDL Files: Web Service Descriptions.
- In a stateful business process, the subprocess selected depends on the method specified by the Service Broker control. A new process instance is created based on the method specified by the Service Broker control and a new conversation ID is assigned to the process instance. You can specify the conversation ID. If you don't specify a conversation ID, the instance automatically generates its own conversation ID. For more information on conversations, see Designing Conversational Web Services.
- In a stateful business process, once a call is invoked and a converstaion ID generated, any further continue methods that are invoked, interact with the original conversation ID. You need to specify a new start method to invoke an interaction with a new conversation ID.
Run-Time Rules for Service Broker Controls in Synchronous and Asynchronous Business Processes
Business processes can have both synchronous or asynchronous request methods. For more information, see Building Synchronous and Asynchronous Business Processes. This section covers some of the run-time issues you should consider when using a Service Broker control in synchronous and asynchronous business processes.
The following rules govern the run-time operation of Service Broker controls in synchronous and asynchronous business processes:
- In a synchronous business process, the Service Broker control allows a business process (or Web service) to invoke and receive callbacks from another service using one of several protocols. The most commonly used protocol is SOAP over HTTP. The target subprocess must expose the particular binding in the WSDL interface that corresponds to the protocol the client is using.
- In a synchronous business process, the transaction contexts are not propagated over the Service Broker control calls because the transport used is HTTP or JMS.
- In a synchronous business process, once a call is invoked, the parent process blocks and waits for a response from the subprocess before continuing to execute.
- In a synchronous business process, if a system level error is thrown in the transaction, a SOAP fault is generated and returned to the parent process or a com.bea.control.ServiceControlException is generated.
- In asynchronous business processes, all calls are invoked by a Web service which dumps the call instance into a Java Message Service (JMS) queue.
- In asynchronous business processes, the transaction is never propagated to the subprocess. In other words, the subprocess runs in its own transaction. The parent business process uses Java Message Service (JMS) to drop messages into a JMS queue. Once the parent process drops a message into the queue, it assumes that message delivery is successful. If an error occurs on the subprocess, the parent process is not informed of the error. For information on enhancing your business process so that you can detect failures, see "Asynchronous Subprocesses" in Building Synchronous and Asynchronous Business Processes.
- In asynchronous business processes, the parent business process continues to execute until the process finishes or until the process receives a callback from the subprocess. The callback is always associated with the process instance initially created by the parent business process.
- In an asynchronous business process, once the parent process invokes a message request to the subprocess, through the Service Broker control, it continues to instantiate and make further requests to the subprocess. If the subprocess doesn't have time to respond to the request from the parent process before it receives a second request, the second request will be dropped and the subprocess will not receive it at all. For this reason, you should design the parent process so that it blocks and waits for a callback from the subprocess before taking further action. For an example of using an Event Choice node to perform this function, see "Asynchronous Subprocesses" in Building Synchronous and Asynchronous Business Processes.
- In a asynchronous business process, if a system level error is thrown in the transaction, the error is not propagated back to the parent process.
- The com.bea.control JwsContext interface provides access to container services that support Web services (JWS files). For more information, see "com.bea.control JwsContext Interface" in com.bea.control Package. The setUnderstoodInputHeaders() method of the com.bea.control JwsContext interface is not supported for asynchronous processes.
- It is recommended that you do not use callback methods that have return values, since JPDs do not support return values on Service Broker Controls.
Security
The Service Broker control conforms to all standard security checks associated with JMS and WSDL. SSI is not supported. For more security information, see Security.
If you want to configure security settings for your Service Broker control, it is recommended that you use the WebLogic Integration Administration Console to configure these settings and do not set them on the process. For more information, see "Updating Security Policies" in Process Configuration in Managing WebLogic Integration Solutions, which is available at the following URL :http://e-docs.bea.com/wli/docs81/manage/processconfig.html#1039959.
Related Topics
Building Stateless and Stateful Business Processes
Building Synchronous and Asynchronous Business Processes
com.bea.control Package
Security