Business Processes and Web Services
(Page 1 of 4 )
Last week we introduced you to the idea of using existing Web services to build more complex web services. This week, we're going to take a closer look at business processes and their role in constructing Web services. This article is excerpted from chapter 12 of
Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418).
External Interface of a Process
Let's first look at business processes from an external perspective. BPEL is built on top of Web services, so WSDL plays the major role for the specification of interfaces used and exposed by a process. We'll briefly revisit standard Web services definition interfaces and then examine the external interface of a business process.
Standard WSDL: PortTypes and Messages
In Chapter 4 "Describing Web Services," we introduced the Web Service Description Language (WSDL). WSDL portTypes refer to WSDL messages with parts described by XML schema types.
The interface of a business process is specified as a collection of portTypes. Therefore, a business process is a special case of a Web service implementation. All inbound and outbound interfaces are described using WSDL. The binding of interfaces to service endpoints is outside the scope of the process language.
The following list introduces the namespaces and prefixes we use throughout this chapter:
po—http://www.skatestown.com/ns/po
inv—http://www.skatestown.com/ns/invoice
pos—http://www.skatestown.com/services/ interfaces/poSubmission.wsdl
skt—http://www.skatestown.com/services/ interfaces/skatestown.wsdl
sup—http://www.wheelsandboards.com/services/ interfaces/orderSupplies.wsdl
plt—http://www.skatestown.com/processes/ poSubmissionPLT
ppa—http://www.skatestown.com/processes/ poSubmissionPPA
Let's first look at the WSDL messages defined for the SkatesTown purchase order Web service. Two new messages are used for faults that may occur during purchase order processing. In addition, there's a new message for purchase order cancellations. The following WSDL snippet shows the messages used for the Web service operations exposed by the purchase order process. Note that the first two messages have already been used in the SkatesTown's purchase order Web service:
<message name="poSubmissionRequest">
<part name="purchaseOrder" element="po:po"/>
</message>
<message name="poSubmissionResponse">
<part name="invoice" element="inv:invoice"/>
</message>
<message name="poSubmissionFaultInvalidPO">
<part name="customerID" element="xsd:ID"/>
<part name="orderNumber"
element="xsd:positiveInteger"/>
</message>
<message name="poSubmissionFaultOutOfStock">
<part name="customerID" element="xsd:ID"/>
<part name="orderNumber"
element="xsd:positiveInteger"/>
</message>
<message name="cancelPurchaseOrderRequest">
<part name="purchaseOrder" element="po:po"/>
</message>
The Web service interface provided by the WSDL portType determines the messages used as input, output, or fault messages, respectively. The next snippet shows the operations of the purchase order process. The purchase order submission request is extended with fault messages, and the purchase order cancellation operation is added to the interface:
<portType name="poSubmissionPortType">
<operation name="doSubmission">
<input message="pos:poSubmissionRequest"/>
<output message="pos:poSubmissionResponse"/>
<fault name="invalidPO"
message="pos:poSubmissionFaultInvalidPO"/>
<fault name="outOfStock"
message="pos:poSubmissionFaultOutOfStock"/>
</operation>
<operation name="cancelPurchaseOrder">
<input
message="pos:cancelPurchaseOrderRequest"/>
</operation>
</portType>
During the processing of a purchase order request, the process itself calls other Web services provided by SkatesTown's suppliers. These outbound invocations are defined in the same way. The following sample shows the interface of Web services that are required by the implementation of the purchase order process:
<portType name="orderSuppliesPortType">
<operation name="orderSupplies">
<input message="asp:orderSuppliesRequest"/>
</operation>
</portType>
Notice that these services are one-way operations. How does information flow back into the process? The response to these one-way requests is described by a separate one-way operation called in the reverse direction. It's provided by the process and invoked by the supplier. The next WSDL snippet shows these callback interfaces. Together with the purchase order portType introduced earlier, this completes the specification of interfaces provided by the purchase order business process:
<portType name="orderSuppliesCallbackPortType">
<operation name="orderSuppliesOk">
<input message="asp:orderSuppliesResponse"/>
</operation>
<operation name="orderSuppliesFailed">
<input message="asp:orderSuppliesFault"/>
</operation>
</portType>
Up to this point, there was no requirement for concepts beyond the scope already covered by WSDL. Next, you'll see how multiple one-way requests can be associated with each other. PortTypes are paired in order to describe the relationship of multiple steps in an asynchronous interaction.
Next: WSDL Extensions for Interactions with a Business Process >>
More Web Services Articles
More By Sams Publishing
|
 This article is excerpted from chapter 12 of Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418). Check it out today at your favorite bookstore. Buy this book now.
|
|
