Web services have evolved into a matured technology over the past few years. A web service, as the W3C consortium defines it, is a software system designed to support interoperable machine-to-machine interaction over a network. Large enterprises are seeking ways to make IT more agile to support their business processes. On the one hand, they are trying to make the best out of the existing applications, and on the other hand, they are attempting to minimize the costs of developing new solutions.

The Service-Oriented Architecture (SOA) presents an architecture that enables agile IT technology for the business process management. With the appearance of web services, the foundation of modular applications was set in SOA. Since web services are technology-neutral, they enable high interoperability. While exposing small-scale application pieces or business services, web services enable integration and reusability. Both facts result in saving time and money.

Web services can be seen as application components or as building blocks of larger applications. The communication between these building blocks is enabled through the open standards, most commonly through HTTP. HTTP is a widely accepted communication protocol between two parties. The traffic can be taken through the proxies and firewalls, which present no obstacle to HTTP communication. Web services consist of two parts. The first part presents the implementation of the web service itself. Web services can be implemented in various programming languages, such as Java, C#, Perl, JRuby, and so on. When the implementation is ready, the second part comes into play, which is the service description or service interface defined through the WSDL document. The service description is universally based on the XML language. The XML language presents a simple, open, and self-describing format. With XML, we can describe many common data types, and we can also define custom data types, if needed.

Web service exposes its implementation or functionality through the web service interface. The web service interface is defined as the Web Service Description Language (WSDL) document. Remember, WSDL is released in several versions of specifications, which are widely used today. In 2001, WSDL 1.1 (Web Service Definition Language) was released, followed by WSDL 2.0 (Web Service Description Language) in 2007. However, the basic concepts of WSDL did not change. WSDL is based on the XML language. WSDL can be seen as a web service description, consisting of the abstract and concrete part. We first describe the abstract part, which consists of data for exchanging information and operations.

The fundamental part of the WSDL description is the definition of operations. The operations present the distinct functionality that a requestor would request when calling a web service. The requestor would also need information about the input and output parameters of the operations. For that purpose, we defined a part of WSDL that is called messages . There are three different types of messages. They can be further defined as input messages, output messages, and fault messages. The messages can be further broken down into parts, which present the building blocks of the messages. Note that for several reasons, it is not recommended to have more than one part in the message. When we define the document/literal binding style, we have problems in cases of more than one part in the message definition. The solution for scenarios where we have more parts defined in the message definition is with the usage of message wrapping, where we end up with one part per message definition. With wrapping, we achieve compliance with WS-I (Web Service Interoperability organization), and also the document/literal binding style requirements are fulfilled.

Further more describing the concrete part of the WSDL document, the operations are grouped into port type, as shown in the following figure:

Now we have the service interface described; however, we still need to describe a method of how web services can be called by a client. This is achieved through the binding element of the WSDL document. With binding, we choose the wire protocol that will be used for calling the web service. To call a web service via HTTP we use the following binding: http://schemas.xmlsoap.org/soap/http.

We can also call web service via other protocols, such as SMTP, FTP, MQ, IIOP, and so on. With binding (the soap:body part) we also define how message parts appear in the SOAP body. The available attribute values are as follows:

The sample binding of a web service is shown in the following code:

<wsdl:binding name = "HelloWorldProcessBinding" type = "client:HelloWorldProcess">
  <soap:binding transport = "http://schemas.xmlsoap.org/soap/http"/>
  <wsdl:operation name = "process">
  <soap:operation style = "document" soapAction = "process"/>
    <wsdl:input>
      <soap:body use = "literal"/>
    </wsdl:input>
    <wsdl:output>
      <soap:body use="literal"/>
    </wsdl:output>
    <wsdl:fault name="fault">
      <soap:fault name="fault" use="literal"/>
    </wsdl:fault>
  </wsdl:operation>
</wsdl:binding>

We can define multiple bindings for different port types. When we define bindings along with the port type, we get the port definition. Inside the port definition, there is an address element, which presents the endpoint (physical location) of web service. The port definition now presents a concrete definition of a web service that the client can call. At the top level of the WSDL definition document is the element service, which consists of all the ports defined by web service as follows:

<wsdl:service name = "helloworldprocess_client_ep">
  <wsdl:port name = "HelloWorldProcess_pt" binding = "client:HelloWorldProcessBinding">
  <soap:address location = "http://medion:7001/soa-infra/services/default/bpel-101-HelloWorld/helloworldprocess_client_ep"/>
  </wsdl:port>
</wsdl:service>

When we execute a web service, we need to exchange the messages via some uniform way. We achieve this by using the SOAP protocol. From the architectural point of view, the SOAP protocol defines the SOAP message in the following way:

One alternative for exchanging the messages is the REST (Representational State Transfer) style, which we will cover in the Invoking the RESTful web services recipe. In this chapter, we will examine different ways of building web services as well as consuming them through BPEL. We will show how to invoke the asynchronous and synchronous types of web services. Also, we will show how to execute web services from BPEL in sequence and in parallel. The last recipes will show you how to handle the faults thrown from web services and how to model the faults in the BPEL processes.