Data exchange between business processes and services

A business process can consume service component architecture (SCA) services or it can be consumed by other SCA services. The way in which Web Services Description Language (WSDL) message data is exchanged between the SCA service and the process depends on how the process was modeled.

A business process consumes a service

The consumption of a service in a business process is implemented using a Business Process Execution Language (BPEL) invoke activity in the process model. The data that is passed to the SCA service is retrieved from one or more BPEL variables. Usually, the data is passed by value, which means that the invoked service works with a copy of the data.

Under certain circumstances, data can be passed by reference. Passing data by reference can help to improve the performance of business processes.

If all of the following conditions are met, the data is passed by reference to the business process:
  • The invocation of the service is synchronous.
  • The BPEL process and the invoked service are in the same module.
  • The data is exchanged in one of the following ways:
    • One or more BPEL variables are declared using XML schema types or elements. The WSDL message parts are mapped individually between the service invocation and the variables.
      <variable name="inputPart1Var" type="ws:inputPart1Type">
      <variable name="inputPart2Var" type="ws:inputPart2Type">

      The Web service activity uses the parameter extension to refer to the BPEL variables. In the SCA interaction, the WSDL is treated as a wrapper for the data that is passed by reference.

      <invoke ....>
        <wpc:input>
          <wpc:parameter name="ws:inputPart1" variable="inputPart1Var"/>
          <wpc:parameter name="ws:inputPart2" variable="inputPart2Var"/>
          ...
        </wpc:input>
      </invoke ....>
    • One or more BPEL variables are declared using XML schema types or elements. The Web service interaction complies with the document-literal wrapped style; parameter elements are mapped between the wrapper document and the variables.
      <variable name="inputParm1Var" type="ws:inputParm1ElemType">
      <variable name="inputParm2Var" type="ws:inputParm2ElemType">

      The Web service activity uses the parameter extension to refer to the BPEL variables. This is the default behavior for processes that are created in WebSphere Integration Developer. In the SCA interaction, the wrapper holds the parameters that are passed by reference.

      <invoke ....>
        <wpc:input>
          <wpc:parameter name="ws:inputParm1" variable="inputParm1Var"/>
          <wpc:parameter name="ws:inputParm2" variable="inputParm2Var"/>
          ...
        </wpc:input>
      </invoke ....>

If the invoked service modifies the data, these changes are applied to the corresponding BPEL variables. However, as a best practice the invoked service should not update the data because any changes that are made to the data are not persistent. For long-running processes the changes are discarded when the current transaction commits, and for microflows the changes are discarded when the process ends. In addition, an event is not generated when the variable is updated by the invoked service.

A business process is consumed by a service

A business process that is consumed by other services contains receive activities, pick activities, or event handlers in the process model. The data that is passed to the process is written to one, or more BPEL variables. Usually, the data is passed by value, which means that the process works with a copy of the data.

However, if all of the following conditions are met, the data is passed by reference:
  • The invocation of the business process is synchronous.
  • The service and the invoked business process are in the same module.
  • The data is exchanged in one of the following ways:
    • One or more BPEL variables are declared using XML schema types or elements. The WSDL message parts are mapped individually between the service invocation and the variables.
      <variable name="outputPart1Var" type="ws:outputPart1Type">
      <variable name="outputPart2Var" type="ws:outputPart2Type">

      The activity uses the parameter extension to refer to the BPEL variables. In the SCA interaction, the WSDL is treated as a wrapper for the data that is passed by reference. For a receive activity, the corresponding BPEL snippet might look like the following example:

      <receive ....>
        <wpc:output>
          <wpc:parameter name="ws:outputPart1" variable="outputPart1Var"/>
          <wpc:parameter name="ws:outputPart2" variable="outputPart2Var"/>
          ...
        </wpc:output>
      </receive ....>
    • One or more BPEL variables are declared using XML schema types or elements. The Web service interaction complies with the document-literal wrapped style; parameter elements are mapped between the wrapper document and the variables.
      <variable name="outputParm1Var" type="ws:outputParm1ElemType">
      <variable name="outputParm2Var" type="ws:outputParm2ElemType">

      The activity uses the parameter extension to refer to the BPEL variables. This is the default behavior for processes that are created in WebSphere Integration Developer. In the SCA interaction, the wrapper holds the parameters that are passed by reference. For a receive activity, the corresponding BPEL snippet might look like the following example:

      <receive ....>
        <wpc:output>
          <wpc:parameter name="ws:outputParm1" variable="outputParm1Var"/>
          <wpc:parameter name="ws:outputParm2" variable="outputParm2Var"/>
          ...
        </wpc:output>
      </receive ....>

If the invoked process modifies the BPEL variables, the input data from the calling service is also modified.


(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)