bea.com | products | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > WebLogic Platform > WebLogic Integration > BPM Topics > BPM - Workshop Interoperability Sample > Overview |
BPM - Workshop Interoperability Sample
|
Overview
The WebLogic Integration BPM - Workshop sample shows how Web services and workflows can invoke one another by exchanging XML documents. The sample demonstrates two scenarios:
The sample also demonstrates two message formats:
Note: The BPM - Workshop sample runs only on Window systems.
This section contains information on the following topics:
Interoperation Scenario
Figure 1-1 shows how a workflow can invoke a Web service with an XML message and then some time later receive an XML message from that Web service.
Figure 1-1 Workflow Invokes Web Service with XML and Later Receives XML from the Web Service
The workflow invokes the Web service with an XML document by passing in an XML message over SOAP-HTTP or HTTP-XML. The Web service then begins processing business logic. At some point during or after the processing, the Web service sends a message containing an XML document back to the workflow. This scenario features an asynchronous Web service because the workflow is free to perform its processing after instantiating the Web service. The workflow can then later solicit the response from the Web service. Note that each instance of the Web service must send the XML result back to the workflow instance that invoked it. Note: The Web service methods in the XML over HTTP sample are, strictly speaking, synchronous. This is due to a feature in WebLogic Workshop where the JWS methods that support XML-only bindings over HTTP do not support void return values. Subsequently, it is not possible to have asynchronous XML/HTTP only methods in a Workshop JWS. The sample handles this limitation by having the JWS return dummy integers as return values. How the Scenario is Implemented An intermediary Web service is employed to decouple the workflow from the protocol and message format of the target Web service, as shown in Figure 1-2. Figure 1-2 Workflow Invokes a Web Service with XML and Later Receives XML from the Web Service
The intermediary Web service ensures that the reply XML received from the target Web service comes from the identical Web service instance that it invoked by sending the original XML message. The intermediary must also ensure that it conveys the XML result from the target Web service back to the exact workflow instance that passed it the original XML document. The workflow requires a mechanism for transmitting its raw XML to the intermediary Web service and receiving an XML response from the intermediary Web service at a later time. Note that both of these XML transmissions must be guaranteed to take place between the same intermediary Web service instance and workflow instance. The intermediary Web service also frees up the workflows from having to support a SOAP/XML over HTTP interface. The workflows act as JMS producers and consumers leaving the Web services to handle the SOAP/XML message format translation.
How the Sample Demonstrates the Scenario
As previously mentioned, the sample demonstrates that a workflow can generate an XML document containing purchase order information. In the sample, the SendPO workflow uses an XML document to trigger the ProcessPO workflow. The ProcessPO workflow eventually returns a result XML document to the SendPO workflow after it completes processing the purchase order information.
Figure 1-3 shows the interoperability process for the SOAP over HTTP sample. Table 1-1 describes the process in detail.
Figure 1-4 shows the interoperability process for the XML over HTTP sample. Table 1-2 describes the process in detail.
Figure 1-3 Workflow - Workshop Interaction—SOAP
Note: Each step is described in Table 1-1. As shown in Figure 1-3, the ProcessPO workflow is invoked by the SendPO workflow. The Process PO Web service is deployed as means of invoking the ProcessPO workflow and retrieving its response XML asynchronously. This allows the SendPO workflow to effectively act as a client of the Process PO Web service when it invokes the ProcessPO workflow and receives its result. For this to be feasible, the Process PO Web service must be reachable via HTTP from the WebLogic Integration instance that executes the SendPO workflow. The Send PO Web service handles the details of invoking the Process PO Web service and receiving a result. When the Send PO Web service has the result XML, it conveys it to the SendPO workflow. The SendPO and ProcessPO workflows use the Send PO and Process PO Web services as a means of communicating XML documents to each other asynchronously over HTTP. Table 1-1 SOAP Over HTTP Sample Scenario Steps
Figure 1-4 Workflow - Workshop Interaction—XML
Note: Each step is described in Table 1-2. As shown in Figure 1-4, the ProcessPO workflow is invoked by the SendPO workflow. The Process PO Web service is deployed as means of invoking the ProcessPO workflow and retrieving its response XML asynchronously. This allows the SendPO workflow to effectively act as a client of the Process PO Web service when it invokes the ProcessPO workflow and receives its result. For this to be feasible, the Process PO Web service must be reachable via HTTP from the WebLogic Integration instance that executes the SendPO workflow. The Send PO Web service handles the details of invoking the Process PO Web service and receiving a result. When the Send PO Web service has the result XML, it conveys it to the SendPO workflow. The SendPO and ProcessPO workflows use the Send PO and Process PO Web services as a means of communicating XML documents to each other asynchronously over HTTP. Table 1-2 XML Over HTTP Sample Scenario Steps
Why Only One Instance of WebLogic Integration The sample runs on one instance of WebLogic Integration. In actuality the SendPO workflow and Send PO Web service can be deployed on one instance and the Process PO Web service and ProcessPO workflow can be deployed on another instance, as long as the two instances can reach one another over HTTP. So that the sample can be run a step at a time, the WebLogic Integration Swing Worklist client is used to get input from a user at two intervals during the sample. The Worklist interaction serves only to break the running of the sample into sections that the user can watch execute one at a time.
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |