Service-Oriented Architecture (SOA), as an architectural platform, is adopted today by many businesses as an efficient means for integrating enterprise applications built of Web services—loosely coupled pieces of software that encapsulate their logic within a distinct context and can be easily combined into a composite solution. Although building applications that enable remote access to resources and functionality is not new, doing so according to the principles of service orientation, such as loose coupling, represents a relatively new approach to building composite solutions.
Nowadays, the most common way to build composite applications based on service‑oriented principles is to use the Service-Oriented Architecture, Web services, and WS-BPEL (Web Services Business Process Execution Language) technologies together.
While Web Services is a technology that defines a standard mechanism for exposure and consumption of data and application logic over Internet protocols such as HTTP, WS‑BPEL is an orchestration language that is used to define business processes describing Web services' interactions, thus providing a foundation for building SOA solutions based on Web services. So, to build an SOA solution utilizing Web services with WS-BPEL, you have to perform the following steps:
Build and then publish Web services to be utilized within an SOA solution
Compose the Web services into business flows with WS-BPEL
This chapter gives an overview of the Web services, SOA, and WS-BPEL technologies and how these technologies are interrelated. It also contains references to related documentation and other chapters of this book, which discuss the topics touched upon in this introductory chapter in greater detail. If you already have a basic knowledge of the above technologies, feel free to skip this chapter.
The Web Services technology provides an efficient way to share application logic across multiple machines running various operating systems and using different development environments. To achieve this, Web Services utilizes the SOAP, WSDL, XML Schema, and some other XML-based technologies, providing a standards-based approach to overcoming the platform and language differences.
The following sections give you an overview of these technologies, explaining how they fit into the big picture.
In a nutshell, SOAP is a messaging protocol used to transfer application data in XML format over a transport protocol, such as HTTP. Nowadays, Web service applications employ SOAP as a standard protocol for exchanging information in a decentralized, distributed manner.
Note
For detailed information about SOAP, you can refer the W3C SOAP Recommendation documents. Links to these documents can be found at http://www.w3.org/TR/soap/.
SOAP-based interfaces interact with each other by means of SOAP messages that are specially formatted XML documents used to carry data and metadata. The general structure of a SOAP message is shown below:
<SOAP-ENV:Envelope ...> <SOAP_ENV:Header> ... ... </SOAP_ENV:Header> <SOAP_ENV:Body> ... ... </SOAP_ENV:Body> </SOAP-ENV:Envelope ...>
As you can see in the previous code snippet, an XML document representing a SOAP message consists of the following elements:
An
Envelopeelement wrapping the entire message.A
Headerelement, which is actually optional and may contain subelements carrying metadata associated with the message.A
Bodyelement, which contains the payload of the message. This element may contain an optional fault element, which describes an error if it occurs.
While SOAP messages may be used in various message exchange scenarios, the most popular one is the request/response pattern, which is normally used when calling a remote function exposed by a Web service. Diagrammatically, the request/response scenario might look like the following figure:
As you can see in the above figure, both the service requestor and service provider include the message processing logic required to send/receive and process SOAP messages involved in the request/response scenario used here. If the service requestor is calling a remote function exposed by the service provider, the request message is supposed to carry the values of the parameters passed to the exposed function. After the request message is received, the service provider processes it, extracting the payload (in this case, the parameters passed to the function) from the envelope. Then, the requested function is invoked, utilizing the parameters specified. Once the function result is ready, the service provider wraps this result in a SOAP envelope and sends it back to the service requestor in the response message. The service requestor in turn extracts the function result from the response message and sends it to the calling code.
Note
In Chapter 2, you will learn how to implement service providers and service requestors with PHP using the PHP SOAP extension.
Now that you have a rough idea of how the remote procedure call (RPC) scenario works with SOAP, let's look at an example.
Suppose you have a Web service that exposes the getOrderStatus function, taking the number of a purchase order as the parameter and returning the status of that order as the result.
Note
It is important to understand that the getOrderStatus function discussed in this example may be implemented in any programming language and run on any platform, provided they allow you to expose this function through SOAP. The fact is that Web services hide the details of underlying logic from their consumers, publicly exposing only their interfaces. In the following chapters, you will see a few examples of implementing service underlying logic with PHP.
The following figure depicts a scenario where a service requestor invokes the getOrderStatus function exposed as a Web service:
The general steps performed at run time are the following:
1. The service requestor sends a SOAP request message containing the number of a purchase order to the service provider.
2. The service provider processes the request message, extracting the PO number from the SOAP envelope.
3. The service provider invokes the
getOrderStatusunderlying function, passing the extracted PO number as the parameter.4. The service provider encapsulates the result produced by the
getOrderStatusfunction into a SOAP response message.5. The service provider sends the SOAP response message back to the requestor.
In this example, the SOAP request message sent to the Web service provider might look like the following:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:getOrderStatus>
<body>US-247860</body>
</SOAP-ENV:getOrderStatus>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
As you can see, the body of the above SOAP message contains the purchase order number passed as the parameter to the getOrderStatus function. The response to this message might look like the following:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:getOrderStatusResponse>
<body>Shipped</body>
</SOAP-ENV:getOrderStatusResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The getOrderStatus function may be designed so that it throws a SOAP exception when something goes wrong. For example, an exception may be thrown upon a failure to connect to the database that contains information about the purchase orders placed. A fault message generated by the Web service exposing the getOrderStatus function might look like the following:
<?xml version="1.0" encoding="UTF-8"?>
SOAPcommunicating<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Failed to determine the order status</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
As you can see, the fault section resides within the body section of the message, and includes two subelements detailing the fault that occurred, namely: faultcode and faultstring.
Looking through the SOAP request message discussed in the preceding section, you may notice that it carries only the parameter for the getOrderStatus function exposed by the service. The message doesn't actually contain any information about how to get to the service, what remote function is to be invoked, and what that function is to return. Obviously, there must be another document that describes the Web service, providing all this information to consumers of the service.
Web Services Description Language (WSDL) provides a mechanism to describe Web services, making them available for external consumption. A WSDL service description is an XML document that defines how to communicate with the Web service, describing the way in which that Web service has to be consumed.
Note
For detailed information about WSDL, you can refer to the Web Services Description Language (WSDL) W3C Note available at http://www.w3.org/TR/wsdl.
Actually, a WSDL service description document consists of two parts: logical and physical. The logical part of a WSDL describes the abstract characteristics of a Web service and includes the following sections:
types is an optional section in which you can define types for the data being carried, normally using the XSD type system.
message contains one or more logical parts representing input and output parameters being used with an operation.
operation describes an action performed by the service, specifying input and output messages being used as parameters of the operation.
portType establishes an abstract set of operations supported by the service.
The physical part of a WSDL describes the concrete characteristics of a Web service and includes the following sections:
binding associates a concrete protocol and message format specifications to operations and messages defined within a particular port type established in the logical part of the document.
port establishes an endpoint by associating a binding with a concrete network address.
service contains one or more port elements representing related endpoints.
Turning back to the example discussed in the preceding section, the WSDL description document that describes the Web service exposing the getOrderStatus function might look like the following:
<?xml version="1.0" encoding="utf-8"?> <definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://localhost/WebServices/ch1/poService"> <message name="getOrderStatusInput"> <part name="body" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="body" element="xsd:string"/> </message> <portType name="poServicePortType"> <operation name="getOrderStatus"> <input message="tns:getOrderStatusInput"/> <output message="tns:getOrderStatusOutput"/> </operation> </portType> <binding name="poServiceBinding" type="tns:poServicePortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getOrderStatus"> <soap:operation soapAction= "http://localhost/WebServices/ch1/getOrderStatus"/> Web ServicesWSDL, binding with<input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="poService"> <port name="poServicePort" binding="tns:poServiceBinding"> <soap:address location= "http://localhost/WebServices/ch1/SOAPserver.php"/> </port> </service> </definitions>
Let's go through this document in detail to understand the format of a WSDL description document.
The definitions element is the root in every WSDL document, wrapping all the WSDL definitions used in the document. Also, it houses the namespaces used within the document:
<definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace= "http://localhost/WebServices/ch1/poService">
Next, you define the abstract definitions for the messages to be used for exchanging data. Here is the abstract definition for the message that will be used for carrying the input parameter for the getOrderStatus function:
<message name="getOrderStatusInput"> <part name="body" element="xsd:string"/> </message>
Here is the abstract definition for the message to be used for sending back the result of the getOrderStatus function:
<message name="getOrderStatusOutput"> <part name="body" element="xsd:string"/> </message>
Once you have messages defined, you can group them into operations, which in turn are grouped into a service interface. Here is the portType section representing an abstract view of the service interface, which, in this example, supports only one operation:
<portType name="poServicePortType"> <operation name="getOrderStatus"> <input message="tns:getOrderStatusInput"/> <output message="tns:getOrderStatusOutput"/> </operation> </portType>
Now that you have an abstract service interface defined, you can go ahead and specify physical details of the data exchange. In a binding section, you map the abstract service interface defined within a portType section earlier into a concrete format, specifying the concrete protocol for data transmission and message
format specifications. In this example, the binding section is used to deploy the getOrderStatus operation—the only operation supported by the service:
<binding name="poServiceBinding" type="tns:poServicePortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getOrderStatus"> <soap:operation soapAction= "http://localhost/WebServices/ch1/getOrderStatus"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>
In the above snippet, you define a SOAP binding of the request-response RPC operation over HTTP and specify the concrete URI indicating the purpose of the SOAP HTTP request.
Finally, you use the service element hosting the port element to specify the physical address of the service.
<service name="poService"> <port name="poServicePort" binding="tns:poServiceBinding"> <soap:address location= "http://localhost/WebServices/ch1/SOAPServer.php"/> </port> </service>
In the above example, the getOrderStatus function exposed as a Web service takes only one input parameter. But what if you need to pass more than one parameter to a Web service? Suppose you modify the getOrderStatus function so that it takes one more parameter, say, poDate specifying the date an order was placed. If so, you have to include a new part element to the message construct describing the logical abstract content of an input message in the WSDL document:
<definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace= "http://localhost/WebServices/ch1/poService"> <message name="getOrderStatusInput"> <part name="poNumber" element="xsd:string"/> <part name="poDate" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="body" element="xsd:string"/> </message> ... Web ServicesWSDL, binding with</definitions>
Now, a SOAP message issued by a service requestor when calling the getOrderStatus remote function would look as follows:
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:getOrderStatus> <poNumber>US-247860</poNumber> <poDate>21-jan-07</poDate> </SOAP-ENV:getOrderStatus> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
As you might notice, the WSDL document discussed in the preceding section doesn't contain the types construct. It is OK in this particular example because you don't actually need any custom XML Schema Definition (XSD) types when defining message parts in the WSDL document. Instead, you use the native XSD schema type string.
However, in some situations you may find it useful to utilize custom XML Schema types within a WSDL document. You can define custom XSD types within the types construct of a WSDL document and then reference them within message elements. For example, you might define a complex XSD type in the types section of the WSDL document discussed in the previous section and then reference this XSD type when creating the abstract definition of the output message:
<?xml version="1.0" encoding="utf-8"?> <definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd1="http://localhost/WebServices/schema/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace= "http://localhost/WebServices/ch1/po.wsdl"> <types> <xsd:schema targetNamespace="http://localhost/WebServices/schema/"> <xsd:element name="poInfo"> <xsd:complexType> <xsd:sequence> <xsd:element name="pono" type="xsd:string" /> <xsd:element name="shippingDate" type="xsd:string" /> <xsd:element name="status" type="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </types> <message name="getOrderStatusInput"> <part name="poNumber" element="xsd:string"/> <part name="poDate" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="poStatus" element="xsd1:poInfo"/> </message> ... </definitions>
In this example, a response message sent by the service to a service requestor might look as follows:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:getOrderStatusResponse> <poStatus> <pono>US-247860</pono> <shippingDate>21-jan-07</shippingDate> <status>Shipped</status> </poStatus> </SOAP-ENV:getOrderStatusResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
While this example shows how to define custom XML Schema types within the types construct of a WSDL document, you can achieve better reusability by putting XSD type definitions in a single XSD document.
Continuing with this example, you might remove the contents of the types construct into a separate file so that it's available, say, at http://localhost/WebServices/schema/po.xsd. The contents of this file should look as follows:
<?xml version="1.0"?> <schema targetNamespace="http://localhost/WebServices/schema/" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="poInfo"> <complexType> <sequence> <element name="pono" type="string" /> <element name="shippingDate" type="string" /> <element name="status" type="string" /> </sequence> </complexType> </element> </schema> </schema>
With that done, you can make use of the import statement in the WSDL document in order to associate the namespace representing the custom XSD schema with the location of the above document, thus making the contents of the schema available within the WSDL document:
<?xml version="1.0" encoding="utf-8"?> <definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd1="http://localhost/WebServices/schema/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace= "http://localhost/WebServices/ch1/po.wsdl"> <import namespace="http://localhost/WebServices/schema/" location="http://localhost/WebServices/schema/po.xsd"/> <message name="getOrderStatusInput"> <part name="poNumber" element="xsd:string"/> <part name="poDate" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="poStatus" element="xsd1:poInfo"/> </message> ... Web ServicesXML schema</definitions>
Note
As you no doubt have realized, having XSD type definitions in separate files allows you to build more flexible, reusable, and modular solutions. In Chapter 3, you will see how the XSD documents referenced in WSDL can be then reused by an Oracle database holding and processing SOAP messages data.
The Web Services technology provides an efficient way to share application logic across multiple machines running various operating systems and using different development environments. To achieve this, Web Services utilizes the SOAP, WSDL, XML Schema, and some other XML-based technologies, providing a standards-based approach to overcoming the platform and language differences.
The following sections give you an overview of these technologies, explaining how they fit into the big picture.
In a nutshell, SOAP is a messaging protocol used to transfer application data in XML format over a transport protocol, such as HTTP. Nowadays, Web service applications employ SOAP as a standard protocol for exchanging information in a decentralized, distributed manner.
Note
For detailed information about SOAP, you can refer the W3C SOAP Recommendation documents. Links to these documents can be found at http://www.w3.org/TR/soap/.
SOAP-based interfaces interact with each other by means of SOAP messages that are specially formatted XML documents used to carry data and metadata. The general structure of a SOAP message is shown below:
<SOAP-ENV:Envelope ...> <SOAP_ENV:Header> ... ... </SOAP_ENV:Header> <SOAP_ENV:Body> ... ... </SOAP_ENV:Body> </SOAP-ENV:Envelope ...>
As you can see in the previous code snippet, an XML document representing a SOAP message consists of the following elements:
An
Envelopeelement wrapping the entire message.A
Headerelement, which is actually optional and may contain subelements carrying metadata associated with the message.A
Bodyelement, which contains the payload of the message. This element may contain an optional fault element, which describes an error if it occurs.
While SOAP messages may be used in various message exchange scenarios, the most popular one is the request/response pattern, which is normally used when calling a remote function exposed by a Web service. Diagrammatically, the request/response scenario might look like the following figure:
As you can see in the above figure, both the service requestor and service provider include the message processing logic required to send/receive and process SOAP messages involved in the request/response scenario used here. If the service requestor is calling a remote function exposed by the service provider, the request message is supposed to carry the values of the parameters passed to the exposed function. After the request message is received, the service provider processes it, extracting the payload (in this case, the parameters passed to the function) from the envelope. Then, the requested function is invoked, utilizing the parameters specified. Once the function result is ready, the service provider wraps this result in a SOAP envelope and sends it back to the service requestor in the response message. The service requestor in turn extracts the function result from the response message and sends it to the calling code.
Note
In Chapter 2, you will learn how to implement service providers and service requestors with PHP using the PHP SOAP extension.
Now that you have a rough idea of how the remote procedure call (RPC) scenario works with SOAP, let's look at an example.
Suppose you have a Web service that exposes the getOrderStatus function, taking the number of a purchase order as the parameter and returning the status of that order as the result.
Note
It is important to understand that the getOrderStatus function discussed in this example may be implemented in any programming language and run on any platform, provided they allow you to expose this function through SOAP. The fact is that Web services hide the details of underlying logic from their consumers, publicly exposing only their interfaces. In the following chapters, you will see a few examples of implementing service underlying logic with PHP.
The following figure depicts a scenario where a service requestor invokes the getOrderStatus function exposed as a Web service:
The general steps performed at run time are the following:
1. The service requestor sends a SOAP request message containing the number of a purchase order to the service provider.
2. The service provider processes the request message, extracting the PO number from the SOAP envelope.
3. The service provider invokes the
getOrderStatusunderlying function, passing the extracted PO number as the parameter.4. The service provider encapsulates the result produced by the
getOrderStatusfunction into a SOAP response message.5. The service provider sends the SOAP response message back to the requestor.
In this example, the SOAP request message sent to the Web service provider might look like the following:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:getOrderStatus>
<body>US-247860</body>
</SOAP-ENV:getOrderStatus>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
As you can see, the body of the above SOAP message contains the purchase order number passed as the parameter to the getOrderStatus function. The response to this message might look like the following:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:getOrderStatusResponse>
<body>Shipped</body>
</SOAP-ENV:getOrderStatusResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The getOrderStatus function may be designed so that it throws a SOAP exception when something goes wrong. For example, an exception may be thrown upon a failure to connect to the database that contains information about the purchase orders placed. A fault message generated by the Web service exposing the getOrderStatus function might look like the following:
<?xml version="1.0" encoding="UTF-8"?>
SOAPcommunicating<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Failed to determine the order status</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
As you can see, the fault section resides within the body section of the message, and includes two subelements detailing the fault that occurred, namely: faultcode and faultstring.
Looking through the SOAP request message discussed in the preceding section, you may notice that it carries only the parameter for the getOrderStatus function exposed by the service. The message doesn't actually contain any information about how to get to the service, what remote function is to be invoked, and what that function is to return. Obviously, there must be another document that describes the Web service, providing all this information to consumers of the service.
Web Services Description Language (WSDL) provides a mechanism to describe Web services, making them available for external consumption. A WSDL service description is an XML document that defines how to communicate with the Web service, describing the way in which that Web service has to be consumed.
Note
For detailed information about WSDL, you can refer to the Web Services Description Language (WSDL) W3C Note available at http://www.w3.org/TR/wsdl.
Actually, a WSDL service description document consists of two parts: logical and physical. The logical part of a WSDL describes the abstract characteristics of a Web service and includes the following sections:
types is an optional section in which you can define types for the data being carried, normally using the XSD type system.
message contains one or more logical parts representing input and output parameters being used with an operation.
operation describes an action performed by the service, specifying input and output messages being used as parameters of the operation.
portType establishes an abstract set of operations supported by the service.
The physical part of a WSDL describes the concrete characteristics of a Web service and includes the following sections:
binding associates a concrete protocol and message format specifications to operations and messages defined within a particular port type established in the logical part of the document.
port establishes an endpoint by associating a binding with a concrete network address.
service contains one or more port elements representing related endpoints.
Turning back to the example discussed in the preceding section, the WSDL description document that describes the Web service exposing the getOrderStatus function might look like the following:
<?xml version="1.0" encoding="utf-8"?> <definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://localhost/WebServices/ch1/poService"> <message name="getOrderStatusInput"> <part name="body" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="body" element="xsd:string"/> </message> <portType name="poServicePortType"> <operation name="getOrderStatus"> <input message="tns:getOrderStatusInput"/> <output message="tns:getOrderStatusOutput"/> </operation> </portType> <binding name="poServiceBinding" type="tns:poServicePortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getOrderStatus"> <soap:operation soapAction= "http://localhost/WebServices/ch1/getOrderStatus"/> Web ServicesWSDL, binding with<input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="poService"> <port name="poServicePort" binding="tns:poServiceBinding"> <soap:address location= "http://localhost/WebServices/ch1/SOAPserver.php"/> </port> </service> </definitions>
Let's go through this document in detail to understand the format of a WSDL description document.
The definitions element is the root in every WSDL document, wrapping all the WSDL definitions used in the document. Also, it houses the namespaces used within the document:
<definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace= "http://localhost/WebServices/ch1/poService">
Next, you define the abstract definitions for the messages to be used for exchanging data. Here is the abstract definition for the message that will be used for carrying the input parameter for the getOrderStatus function:
<message name="getOrderStatusInput"> <part name="body" element="xsd:string"/> </message>
Here is the abstract definition for the message to be used for sending back the result of the getOrderStatus function:
<message name="getOrderStatusOutput"> <part name="body" element="xsd:string"/> </message>
Once you have messages defined, you can group them into operations, which in turn are grouped into a service interface. Here is the portType section representing an abstract view of the service interface, which, in this example, supports only one operation:
<portType name="poServicePortType"> <operation name="getOrderStatus"> <input message="tns:getOrderStatusInput"/> <output message="tns:getOrderStatusOutput"/> </operation> </portType>
Now that you have an abstract service interface defined, you can go ahead and specify physical details of the data exchange. In a binding section, you map the abstract service interface defined within a portType section earlier into a concrete format, specifying the concrete protocol for data transmission and message
format specifications. In this example, the binding section is used to deploy the getOrderStatus operation—the only operation supported by the service:
<binding name="poServiceBinding" type="tns:poServicePortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getOrderStatus"> <soap:operation soapAction= "http://localhost/WebServices/ch1/getOrderStatus"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>
In the above snippet, you define a SOAP binding of the request-response RPC operation over HTTP and specify the concrete URI indicating the purpose of the SOAP HTTP request.
Finally, you use the service element hosting the port element to specify the physical address of the service.
<service name="poService"> <port name="poServicePort" binding="tns:poServiceBinding"> <soap:address location= "http://localhost/WebServices/ch1/SOAPServer.php"/> </port> </service>
In the above example, the getOrderStatus function exposed as a Web service takes only one input parameter. But what if you need to pass more than one parameter to a Web service? Suppose you modify the getOrderStatus function so that it takes one more parameter, say, poDate specifying the date an order was placed. If so, you have to include a new part element to the message construct describing the logical abstract content of an input message in the WSDL document:
<definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace= "http://localhost/WebServices/ch1/poService"> <message name="getOrderStatusInput"> <part name="poNumber" element="xsd:string"/> <part name="poDate" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="body" element="xsd:string"/> </message> ... Web ServicesWSDL, binding with</definitions>
Now, a SOAP message issued by a service requestor when calling the getOrderStatus remote function would look as follows:
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:getOrderStatus> <poNumber>US-247860</poNumber> <poDate>21-jan-07</poDate> </SOAP-ENV:getOrderStatus> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
As you might notice, the WSDL document discussed in the preceding section doesn't contain the types construct. It is OK in this particular example because you don't actually need any custom XML Schema Definition (XSD) types when defining message parts in the WSDL document. Instead, you use the native XSD schema type string.
However, in some situations you may find it useful to utilize custom XML Schema types within a WSDL document. You can define custom XSD types within the types construct of a WSDL document and then reference them within message elements. For example, you might define a complex XSD type in the types section of the WSDL document discussed in the previous section and then reference this XSD type when creating the abstract definition of the output message:
<?xml version="1.0" encoding="utf-8"?> <definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd1="http://localhost/WebServices/schema/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace= "http://localhost/WebServices/ch1/po.wsdl"> <types> <xsd:schema targetNamespace="http://localhost/WebServices/schema/"> <xsd:element name="poInfo"> <xsd:complexType> <xsd:sequence> <xsd:element name="pono" type="xsd:string" /> <xsd:element name="shippingDate" type="xsd:string" /> <xsd:element name="status" type="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </types> <message name="getOrderStatusInput"> <part name="poNumber" element="xsd:string"/> <part name="poDate" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="poStatus" element="xsd1:poInfo"/> </message> ... </definitions>
In this example, a response message sent by the service to a service requestor might look as follows:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:getOrderStatusResponse> <poStatus> <pono>US-247860</pono> <shippingDate>21-jan-07</shippingDate> <status>Shipped</status> </poStatus> </SOAP-ENV:getOrderStatusResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
While this example shows how to define custom XML Schema types within the types construct of a WSDL document, you can achieve better reusability by putting XSD type definitions in a single XSD document.
Continuing with this example, you might remove the contents of the types construct into a separate file so that it's available, say, at http://localhost/WebServices/schema/po.xsd. The contents of this file should look as follows:
<?xml version="1.0"?> <schema targetNamespace="http://localhost/WebServices/schema/" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="poInfo"> <complexType> <sequence> <element name="pono" type="string" /> <element name="shippingDate" type="string" /> <element name="status" type="string" /> </sequence> </complexType> </element> </schema> </schema>
With that done, you can make use of the import statement in the WSDL document in order to associate the namespace representing the custom XSD schema with the location of the above document, thus making the contents of the schema available within the WSDL document:
<?xml version="1.0" encoding="utf-8"?> <definitions name ="poService" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd1="http://localhost/WebServices/schema/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace= "http://localhost/WebServices/ch1/po.wsdl"> <import namespace="http://localhost/WebServices/schema/" location="http://localhost/WebServices/schema/po.xsd"/> <message name="getOrderStatusInput"> <part name="poNumber" element="xsd:string"/> <part name="poDate" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="poStatus" element="xsd1:poInfo"/> </message> ... Web ServicesXML schema</definitions>
Note
As you no doubt have realized, having XSD type definitions in separate files allows you to build more flexible, reusable, and modular solutions. In Chapter 3, you will see how the XSD documents referenced in WSDL can be then reused by an Oracle database holding and processing SOAP messages data.
While using Web services allows you to achieve interoperability across applications built on different platforms with different languages, applying service-oriented concepts and principles when building applications based on using Web services can help you create robust, standards-based, interoperable SOA solutions.
Note
It is interesting to note that Service-Oriented Architecture, while providing architectural foundation for building service-oriented solutions, is not tied to a concrete technology or technology set. In contrast, it may be implemented with various technologies, such as DCOM, CORBA, or Web Services. However, only the Web Services technology set is currently the primary way to put SOA into practice.
As mentioned, to build an SOA solution based on Web services, you need to follow the service-orientation principles when pulling the services together into an application. Here are some of the key principles of service-orientation you need to keep in mind when designing SOA solutions:
Loose coupling represents a relationship that allows the underlying logic of a service to change with minimal or no impact on the other services utilized within the same SOA. Loose coupling is the key principle of service orientation. Implementing services as loosely coupled pieces of software allows you to keep up with the other key principles of service orientation, such as service reusability, service autonomy, and service statelessness.
Service contract represents service descriptions and other documents describing how a service can be programmatically accessed. In the Binding with WSDL section earlier in this chapter, you saw an example of a WSDL service description document that describes a service, defining the contract for that service.
Abstraction of underlying logic means that a service publicly exposes only logic described in the service contract, hiding the implementation details from service consumers. This means that services interact with each other only via their public interfaces. As you learned in the preceding example, the WSDL descriptor describing a service actually provides the interface for service consumers.
Autonomy means that services control only the logic they encapsulate. Dividing application logic into a set of autonomous services allows you to build flexible SOA solutions, achieving loose coupling, reusability, and composability.
Reusability in service-orientation is achieved by distributing application logic among services so that each service can be potentially used by more than one service requestor. Building reusable services supports the principle of composability.
Composability represents the ability of services to be grouped into composite services that coordinate an exchange of data between services being aggregated. For example, using an orchestration language, such as WS‑BPEL, allows you to compose fine-grained services into more coarse‑grained ones. WS-BPEL is discussed in the WS-BPEL section later in this chapter.
Statelessness means that services don't maintain their state specific to an activity. Building stateless services encourage loose coupling, reusability, and composability.
Interoperability between services is easily achieved as long as the services interact with each other through interfaces that are platform- and implementation-independent.
Discoverability refers to standard mechanisms that make it possible for service descriptions describing services to be discovered by service requestors. Universal Description, Discovery, and Integration (UDDI) specification provides such a mechanism, which allows for publishing service descriptions documents in an XML-based registry, thus making them available for public use.
As you can see, most of these principles are tightly related. For example, if you bear the autonomy principle in mind when dividing application logic into services to be utilized within an SOA, you will have reusable, composable, and loosely coupled pieces of software that can be reused in future projects.
On the other hand, ignoring at least one principle of service-orientation makes it very hard to keep up with the others. For example, if you ignore the principle of statelessness when designing services, you will end up with less reusable and less composable building blocks for your SOA solutions.
Now that you know the key principles of service orientation, it's time to look at how these principles can be applied when designing SOA solutions. This section briefly discusses process of designing a service-oriented application, applying the service‑orientation principles outlined in the preceding section.
The service-oriented analysis phase is the first one in the process of designing a service‑oriented application. Regardless of whether you are going to build an SOA solution upon the existing application logic or build it from scratch, you have to consider the following questions:
Which services are required to satisfy business requirements?
How should application logic be divided between services?
How should services be composed to implement the required SOA solution?
The easiest way to understand what has to be done at this stage is by taking up an example.
Imagine you run an online magazine that specializes in publishing technical articles submitted by technical people working on a contract basis. When a potential author submits an article proposal, you look through it and then either accept it or reject it, depending on your current editorial needs and some other things. Here are the general steps you perform upon accepting a proposal:
1. Save the proposal in the database.
2. Save information about the author (for new authors only).
3. Notify the author about accepting the proposal.
4. Issue a PO.
5. Send the PO to the author.
Now, suppose you want to design an SOA solution automating this process.
As mentioned earlier, the first thing you have to determine is which services have to be built. Keeping in mind the service-orientation principles outlined in the preceding section, you might create the following services to be then used as building blocks in the SOA solution being designed:
As you can see, the first three services in the above list are entity-centric, representing corresponding business entities.
Note
There are two main approaches for designing services representing business logic: entity-centric and task-centric. While a task-centric service is tightly bound to a specific task and so has a poor chance of reuse, an entity-centric service represents a specific business entity, standing a good chance of being reused in solutions dealing with the same business entity. Both the approaches are discussed in more detail later in Chapter 7, which focuses on issues related to service-oriented business modeling.
An entity-centric service usually provides a full set of operations required to manipulate an instance of a specific business entity. For example, the Proposal service might support the following set of operations to fulfill processing requirements:
saveProposalgetProposalByIdgetProposalByTitlegetProposalsByAuthorgetProposalsByTopic
Assuming that submitted proposal documents have a certain structure (say, each proposal includes the Topic and Outline sections), the above list of operations supported by the Proposal service might need to be expanded to include some operations responsible for retrieving specific parts of a proposal.
However, it is important to realize that including new operations impacts on the service interface, making you edit the WSDL document describing the service each time you add a new operation. One way to work around this issue is to use parameter-driven operations that invoke the required piece of underlying logic depending on the arguments passed in. In this case, the function encapsulating the underlying logic of a parameter-driven operation delegates the work to some other function where the real work is done.
For example, you might expose a single operation for getting the contents of a proposal, passing parameters identifying whether to find the proposal document by ID or title and which part of the proposal must be returned. In this case, a request message issued by a requestor to invoke the getProposal operation might look as follows:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:getProposal>
<IdType>title</IdType>
<IdValue>Building services with PHP and Oracle XML DB</IdValue>
<DocPart>all</DocPart>
</SOAP-ENV:getProposal>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
As you no doubt have guessed, the parameters used in this example tell the service provider to return the entire document representing the proposal whose title is "Building services with PHP and Oracle XML DB". If you recall from the example discussed in the Binding with WSDL section, the message construct describing the logical abstract content of an input or output message that will be used with an RPC operation contains part elements to define parameters belonging to the operation. So, the message construct describing the above input message in the WSDL document might look as follows:
<definitions ...>
...
<message name="getProposalInput">
<part name="IdType" element="xsd:string"/>
<part name="IdValue" element="xsd:string"/>
<part name="DocPart" element="xsd:string"/>
</message>
...
</definitions>
When the getProposal operation is executed, the input parameters arriving with the request message are passed to the underlying controller method, which in turn invokes an appropriate getProposal* underlying method, depending on the values of parameters passed in.
This approach allows you to cut down the number of operations exposed by a service while still providing the required functionality. Now, you may add a new method to the underlying layer of the service (normally, this layer is represented by a class) and make that method available for the service requestors without having to edit the WSDL document defining the service interface.
Note
In Chapter 2, you will learn how to implement this approach when encapsulating the underlying logic of a service in a PHP class. When continuing with this discussion in Chapter 3, you will see an example of how you can improve the extensibility of parameter-driven service operations by passing operation parameters as XML. Then, Chapter 4 explains in detail how to build services providing generic, parameter-driven operations upon more fine-grained services, rather than directly upon classes or individual functions encapsulating entity‑specific logic. With this approach, you actually employ two service layers to implement application logic manipulating business entities. The first layer includes the services that provide nothing but contact points to the specific operations supported by the services belonging to the second, underlying layer, allowing you to achieve a high level of loose coupling, composability, and reusability.
Now, assuming that you apply the above approach to all the business services mentioned earlier in this section, you might significantly cut down on the number of operations exposed by these services, publicly exposing only generic operations as shown in the following figure:
As you can see, each service depicted in the figure, except for the Notification service, supports more than one operation. This means that unlike the WSDL document discussed in the Binding with WSDL section, the WSDL documents describing the services discussed here will contain multi-operation portType and binding sections.
For example, the WSDL document describing the Proposal service might look like the following:
<?xml version="1.0" encoding="utf-8"?>
<definitions name ="proposalService"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd1="http://localhost/WebServices/schema/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http://localhost/WebServices/ch1/proposal.wsdl">
<import namespace="http://localhost/WebServices/schema/"
location="http://localhost/WebServices/schema/proposal.xsd"/>
SOAbasic principles, applying<message name="addProposalInput">
<part name="body" element="xsd1:proposalEntireDoc"/>
</message>
<message name="addProposalOutput">
<part name="body" element="xsd:string"/>
</message>
<message name="getProposalInput">
<part name="body" element="xsd1:proposalDetails"/>
</message>
<message name="getProposalOutput">
<part name="body" element="xsd1:proposalDoc"/>
</message>
<message name="getProposalsListInput">
<part name="body" element="xsd1:proposalsDetails"/>
</message>
<message name="getProposalsListOutput">
<part name="body" element="xsd1:proposalsList"/>
</message>
<portType name="proposalServicePortType">
<operation name="addProposal">
<input message="tns:addProposalInput"/>
<output message="tns:addProposalOutput"/>
</operation>
<operation name="getProposal">
<input message="tns:getProposalInput"/>
<output message="tns:getProposalOutput"/>
</operation>
<operation name="getOrderStatus">
<input message="tns:getProposalListInput"/>
<output message="tns:getProposalListOutput"/>
</operation>
</portType>
<binding name="proposalServiceBinding"
type="tns:proposalServicePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="addProposal">
<soap:operation
soapAction="http://localhost/WebServices/ch1/addProposal"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
<operation name="getProposal">
<soap:operation
soapAction="http://localhost/WebServices/ch1/getProposal"/>
<input>
<soap:body use="literal"/>
SOAbasic principles, applying</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
<operation name="getProposalLists">
<soap:operation
soapAction="http://localhost/WebServices/ch1/getProposalLists"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="proposalService">
<port name="proposalServicePort"
binding="tns:proposalServiceBinding">
<soap:address
location="http://localhost/WebServices/ch1/SOAPServer.php"/>
</port>
</service>
</definitions>
Note
Note that this WSDL document assumes that the data type definitions used when defining the messages involved are described in a separate XSD document located at http://localhost/WebServices/schema/proposal.xsd.
As you can see, in this WSDL document the portType construct contains three operation elements, each of which represents an abstract definition of an operation supported by the Proposal service. The binding information for each of these operations is then specified with a corresponding operation element defined within the binding construct.
Once you have created all the services needed to automate the process of submitting proposals, it's time to think about how to put them into action.
Actually, there are several ways in which services can be organized to compose an SOA solution. For example, you might create a composite service as a PHP script exposed as a Web service, and which programmatically invokes other services as necessary. However, the most common way to build an SOA composition is by using WS-BPEL, an orchestration language that allows you to create orchestrations—composite, controller services defining how the services being consumed will interoperate to get the job done.
An orchestration assembles services into an executable business process that is to be executed by an orchestration engine. Schematically, an orchestration might look like the following figure:
As you can see, the previous figure illustrates an assembly of services coordinated by the logic encapsulated in the controller service. This controller service may be a WS-BPEL business process, which when executed against the orchestration engine completes a certain business task. In this particular example, the controller service may be organized so that it completes the steps outlined at the beginning of the preceding section Applying SOA Principles.
Note
Built with WS-BPEL orchestration language, a controller service, like any other service, should have a corresponding WSDL document describing the service to its consumers. Building WSDL definitions for composite services built with WS‑BPEL is discussed in the WSDL Definitions for Composite Services section later in this chapter.
You can create an orchestration to be used as a service within another, larger orchestration. For example, the orchestration depicted in the previous figure might be a part of an WS-BPEL orchestration automating the entire editorial process—from accepting the proposal to publishing the article.
The Web Services Choreography specification along with its corresponding Web Services Choreography Description Language (WS-CDL) provides another way to building SOA compositions. While WS-BPEL is used to orchestrate services into composite solutions usually expressing organization-specific business process flows, WS-CDL allows you to describe peer-to-peer relationships between Web services and/or other participants within or across trust boundaries.
Unlike an orchestration, choreography does not imply a centralized control mechanism, assuming control is shared between the interacting participants. What this means is that an orchestration represents an executable process to be executed by an orchestration engine in one place, whereas choreography in essence represents a description of how to distribute control between the collaborating participants, using no single engine to get the job done.
To define choreography, you create a WS-CDL choreography description document that will serve as the contract between the interacting participants. Specifically, a WS‑CDL document describes the message exchanges between the collaborating participants, defining how these participants must be used together to achieve a common business goal. For example, there may be a choreography enabling collaboration between an orchestration, a controller service representing a WS-BPEL process, and a client service interacting with that controller service.
Schematically, this might look like the following figure:
In the scenario depicted in the figure, the choreography layer is used to specify the peer‑to‑peer collaborations of two services. In particular, the WS-CDL choreography document describes message exchanges between the composite service discussed in the preceding section and one of its consumers.
Note
A full discussion of the Choreography specification and its corresponding WS‑CDL language is outside the scope of this book. To learn more about these subjects, you can refer to the W3C document on WS-CDL, which can be found at http://www.w3.org/TR/ws-cdl-10/.
As mentioned earlier, WS-BPEL is an orchestration language used to describe execution logic of Web services applications by defining their control flows and providing a way for partner services to share a common context. To clarify, partner services are those that interact with the WS-BPEL process.
Note
It is interesting to note that although WS-BPEL is currently the most popular executable business process language, it is not the only way to define execution logic of an application based on Web services. There are some other specifications, such as XLANG, WSFL, XPDL, and BPML, each of which might be used as an alternative to WS-BPEL.
WS-BPEL is based on several specifications, such as SOAP, WSDL, and XML Schema, where WSDL perhaps is the most important one. WSDL is what makes a service usable within composite services based on WS-BPEL. WS-BPEL allows you to define business processes interacting with cooperating services through WSDL descriptions. This will be explained in detail in the WSDL Definitions for Composite Services sub-section later in this section.
With WS-BPEL, you build a business process by integrating a collection of Web services into a business process flow. A WS-BPEL business process specifies how to coordinate the interactions between an instance of that process and its partner services.
The following figure illustrates an example of a workflow diagram representing a WS-BPEL business process:
As you can see, the WS-BPEL process depicted in the figure integrates the services required to complete the steps performed after accepting a proposal into an end-to-end process, as outlined at the beginning of the Applying SOA Principles section earlier. In this particular example, the process integrates four Web services, as depicted in the figure shown in the Orchestration section earlier. As you will see in the next section, a WS‑BPEL process connects to a Web service through a partner link defined in the WSDL document.
Apart from the ability to invoke multiple services, a WS-BPEL process may manipulate XML data and perform parallel execution, conditional branching, and looping to control the flow of the process. For example, in this process you use a switch activity, setting up the two branches. If the proposal being processed has been submitted by a new author, the process will call the Author service's operation responsible for saving the information about the author in the database. Otherwise, this step is omitted.
Note
For simplicity's sake, this section illustrates only a workflow diagram of the WS‑BPEL process, rather than executable BPEL code of that process. You will have plenty of opportunities to get your hands dirty with WS-BPEL code in Chapter 5. Then, in Chapter 6 you will learn how to design WS-BPEL processes with ActiveBPEL Designer.
In the Binding with WSDL section earlier in this chapter, you learned how to use WSDL, providing a way for a service consumer to get knowledge of a service provider. Actually, WSDL plays a major role in SOA development. As mentioned, even a WS-BPEL orchestration can be associated with WSDL definitions, thus making it possible to treat that orchestration as a service itself that can be invoked by another service or can be a part of another orchestration or choreography.
Being a service itself, a WS-BPEL process should have a corresponding WSDL document, making it possible for client services to invoke the process. For example, the WS-BPEL process depicted in the previous figure might be associated with the following WSDL definition:
<?xml version="1.0" encoding="utf-8"?> <definitions name="proposalProcessingService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd1="http://localhost/WebServices/schema/" xmlns:plink= "http://schemas.xmlsoap.org/ws/2004/03/partner-link/" targetNamespace= "http://localhost/WebServices/ch1/proposalProcessing/"> <types> <xsd:schema targetNamespace= "http://localhost/WebServices/ch1/proposalProcessing.wsdl"> <xsd:import namespace="http://localhost/WebServices/schema/" schemaLocation="http://localhost/WebServices/schema/ propProc.xsd"/> </xsd:schema> </types> <message name="receiveProposalInput"> <part name="body" element="xsd1:proposalDocType"/> </message> <message name="receiveProposalOutput"> <part name="body" element="xsd:string"/> </message> <portType name="proposalProcessingServicePortType"> <operation name="receiveProposal"> <input message="tns:receiveProposalInput"/> <output message="tns:receiveProposalOutput"/> </operation> </portType> <plink:partnerLinkType name="proposalProcessingService"> <plink:role name="proposalProcessingServiceRole"> <portType="tns:proposalProcessingServicePortType"/> </plink:role> </plink:partnerLinkType> </definitions>
As you can see, this WSDL document doesn't contain binding or service elements. The fact is that a WSDL document of a WS-BPEL process service contains only the abstract definition of the service and partnerLinkType sections that represent the interaction between the process service and its client services. In this particular example, the WSDL definition contains only one partnerLinkType section, supporting one operation used by a client to initiate the process.
Note
A partnerLinkType section defines up to two roles, each of which in turn is associated with a portType defined within the WSDL document earlier. WS‑BPEL uses the partner links mechanism to define a relationship between a WS-BPEL process and the involved parties. As you will learn later in this section, a WS-BPEL process definition contains partnerLink elements to specify the interactions between a WS-BPEL process and its clients and partners. Each partnerLink in a WS-BPEL process definition document is associated with a partnerLinkType defined in a corresponding WSDL document. Schematically, this looks like the following figure (shown overleaf).
Once you have created the WSDL definition for a process service, make sure to modify WSDL documents of the services that will be invoked during the process execution as partner services. To enable a service to be part of a WS-BPEL orchestration, you might want to add a partnerLinkType element to the corresponding WSDL document. For example, to enable the Notification service to participate in the orchestration depicted in the previous figure, you would need to create the following WSDL document:
<?xml version="1.0" encoding="utf-8"?> <definitions name="notificationService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:plink= "http://schemas.xmlsoap.org/ws/2004/03/partner-link/" targetNamespace="http://localhost/WebServices/ch1/notification/"> <message name="sendMessageInput"> <part name="body" element="xsd:string"/> </message> <message name="sendMessageOutput"> <part name="body" element="xsd:string"/> </message> <portType name="notificationServicePortType"> <operation name="sendMessage"> <input message="tns:sendMessageInput"/> <output message="tns:sendMessageOutput"/> </operation> </portType> <binding name="notificationServiceBinding" WS-BPELcomposite servicestype="tns:notificationServicePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sendMessage"> <soap:operation soapAction= "http://localhost/WebServices/ch1/sendMessage"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="notificationService"> <port name="notificationServicePort" binding="tns:notificationServiceBinding"> <soap:address location="http://localhost/WebServices/ch1/SOAPserver.php"/> </port> </service> <plink:partnerLinkType name="notificationService"> <plink:role name="notificationServiceRole"> <portType="tns:notificationServicePortType"/> </plink:role> </plink:partnerLinkType> </definitions>
Note the partnerLinkType block, which is highlighted. By including this section at the end of the WSDL document describing the service, you enable that service as a partner link, making it possible for it to be part of an orchestration.
As mentioned, WS-BPEL uses the partner links mechanism to model the services interacting within the business process. Here is a fragment of the definition of the WS‑BPEL business process depicted in the previous figure and representing the proposalProcessingService process service, showing the use of partner links:
<process name="BusinessTravelProcess" targetNamespace="http://localhost/WebServices/ch1/proposalProcessing/" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:prc="http://localhost/WebServices/ch1/proposalProcessing/" xmlns:ntf="http://localhost/WebServices/ch1/notification/" <partnerLinks> <partnerLink name="client" partnerLinkType="prc:proposalProcessingService" myRole="proposalProcessingServiceRole"/> <partnerLink name="sendingNotification" partnerLinkType="ntf:notificationService" partnerRole="notificationServiceRole"/> ... </partnerLinks> ... </process>
To save space, the above snippet shows only two partnerLink sections in the process definition. The first partnerLink section specifies the interaction between the WS-BPEL process and its clients, and the other partnerLink specifies the interaction between the WS-BPEL process and the Notification service that acts as a partner service here.
The following figure may help you gain a better understanding of how the partner links mechanism used in WS-BPEL work.
The example depicted in the figure represents the relationship between a partnerLinkType defined in the WSDL document describing a WS-BPEL process service and a partnerLink specified in the process definition. When defining the partnerLinkType, you use the myRole attribute to specify the role of the WS-BPEL process. In contrast, to specify the role of a partner, you would use the partnerRole attribute, as shown in the process definition document discussed above.
Looking through the partnerLink sections in the process definition document discussed here, you may notice that they do not actually provide any information about the location of the WSDL documents containing the corresponding partner link types. This information is stored in the process deployment descriptor file. The format of this document varies depending on the WS-BPEL tool you are using. For example, if you are designing your SOA solution with Oracle BPEL Process Manager, the process deployment descriptor file is called bpel.xml and might look as follows:
<?xml version="1.0" encoding="UTF-8"?> <BPELSuitcase> <BPELProcess src="proposalProcess.bpel" id="proposalProcess"> <partnerLinkBindings> <partnerLinkBinding name="client"> <property name="wsdlLocation">proposalProcess.wsdl</property> </partnerLinkBinding> <partnerLinkBinding name="sendingNotification"> <property name="wsdlLocation"> http://localhost/WebServices/ch1/notification?wsdl</property> </partnerLinkBinding> ... </partnerLinkBindings> </BPELProcess> </BPELSuitcase
In ActiveBPEL Designer, a process deployment descriptor file has the pdd extension. This description document contains the information required for the ActiveBPEL server to execute the corresponding WS-BPEL process. A pdd description specifies the location of the WSDL documents describing parties involved in the references section, as shown in the following snippet:
<?xml version="1.0" encoding="UTF-8"?> <process ...> ... <references> WS-BPELcomposite services<wsdl location="project:/proposalProcess/WSDL/ proposalProcess.wsdl" namespace="http://localhost/WebServices/ch1/proposalProcessing/"/> <wsdl location="project:/proposalProcess/WSDL/notification.wsdl" namespace="http://localhost/WebServices/ch1/notification/"/> </references> </process>
Currently, the list of WS-BPEL engines and WS-BPEL modeling tools contains more than 20 items (http://en.wikipedia.org/wiki/List_of_BPEL_engines), including open-source and commercial implementations. The most significant commercial implementations of WS-BPEL engine and WS-BPEL business process management software include: Oracle BPEL Process Manager, IBM WebSphere Process Server, and Microsoft BizTalk Server.
The most popular open-source implementation of WS-BPEL engine is ActiveBPEL Engine. According to the FAQ on the Active Endpoints Website (http://www.active-endpoints.com/open-source-faq.htm), ActiveBPEL Engine is used by more organizations than any other WS-BPEL implementation. ActiveBPEL Designer is a visual tool for creating and testing WS-BPEL-based solutions to be executed against an ActiveBPEL engine.
Note
As mentioned, Chapter 6 discusses how to compose SOAs with ActiveBPEL Designer, a tool whose 3.X version fully supports WS-BPEL 2.0.
Perhaps the most powerful WS-BPEL tool available on a commercial basis is Oracle BPEL Process Manager, which can be used as a standalone application or as part of Oracle SOA Suite—a set of designing, deploying, and monitoring tools enabling you to build service-oriented solutions and then deploy them to Oracle BPEL Server.
Note
A discussion of Oracle BPEL Process Manager is outside the scope of this book. To learn how to build WS-BPEL based solutions with this powerful tool from Oracle, you can refer to the vendor documentation. To start with, you might visit the Oracle BPEL Process Manager page on the Oracle Technology Network Website at http://www.oracle.com/technology/products/ias/bpel/ and the Service-Oriented Architecture page at http://www.oracle.com/technology/soa.
This introductory chapter gave you the basics on what you must know to get started while designing your own service-oriented applications.
In particular, you learned about Web Services technology, which has great potential as a robust means of building platform-neutral applications. Then, you looked at the common service-orientation principles and how they can be applied when designing applications based on Web services. You also learned about Orchestration and Choreography, which represent two basic approaches to composing SOA solutions. You should now have a sufficient grasp of the ideas behind WS-BPEL, an orchestration language that provides a way of defining an orchestration level when building SOA solutions.
In the next chapter, you will learn how to create building blocks for SOA applications, services, using PHP as the underlying technology. These services will then be used as partner services when building WS-BPEL-based SOA solutions, as discussed in the following chapters.