Business processes and human tasks have well-defined interfaces that allow them to be accessed externally as Web services. If these interfaces reference business objects, you need to export the interface definitions and business objects to your client programming environment.
This procedure must be repeated for each business object that your client application needs to interact with.
In WebSphere® Process Server, business objects define the format of request, response and fault messages that interact with business processes or human tasks. These messages can also contain definitions of complex data types.
For example, to create and start a human task, the following items of information must be passed to the task interface:
These items are encapsulated within a single business object. All operations of the Web service interface are modeled as a "document/literal wrapped" operation. Input and output parameters for these operations are encapsulated in wrapper documents. Other business objects define the corresponding response and fault message formats.
In order to create and start the business process or human task through a Web service, these wrapper objects must be made available to the client application on the client side.
This is achieved by exporting the business objects from the WebSphere environment as Web Service Definition Language (WSDL) and XML Schema Definition (XSD) files, importing the data type definitions into your client programming environment, then converting them to helper classes for use by the client application.
Assume a business process exposes the following Web service operation:
<wsdl:operation name="updateCustomer"> <wsdl:input message="tns:updateCustomerRequestMsg" name="updateCustomerRequest"/> <wsdl:output message="tns:updateCustomerResponseMsg" name="updateCustomerResponse"/> <wsdl:fault message="tns:updateCustomerFaultMsg" name="updateCustomerFault"/> </wsdl:operation>
with the WSDL messages defined as:
<wsdl:message name="updateCustomerRequestMsg"> <wsdl:part element="types:updateCustomer" name="updateCustomerParameters"/> </wsdl:message> <wsdl:message name="updateCustomerResponseMsg"> <wsdl:part element="types:updateCustomerResponse" name="updateCustomerResult"/> </wsdl:message> <wsdl:message name="updateCustomerFaultMsg"> <wsdl:part element="types:updateCustomerFault" name="updateCustomerFault"/> </wsdl:message>
The concrete customer-defined elements "types:updateCustomer", "types:updateCustomerResponse" and "types:updateCustomerFault" must be passed to and received from the Web services APIs using <xsd:any> parameters in all generic operations (call, sendMessage, and so on) performed by the client application. These customer-defined elements are created, serialized and deserialized on the client application side using helper classes that are generated using the exported XSD files.
(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)