Time for action – creating the SOA composite application

Let's start. To create the SOA composite application, we will perform the following steps:

1. First, create a new application. Select the New Application… option in the Applications window:
   
2. Next, select SOA Application:
   
3. Name the application Chapter1, as shown in the following screenshot. Use the default directory and click on Next to proceed:
   
4. Next, create a project and name it Bookstore. Use the default directory again:
   
5. After clicking on Next, we are asked what type of composite template we would like to use. We will start from a Standard Composite template. Select the Composite WithBPEL Process option and click on Finish. Alternatively, we can select Empty Composite and add the BPEL process later.
   
6. Clicking on Finish brings us to the Create BPEL Process wizard. Here we have the option to select the BPEL version, name the process, and specify the BPEL XML namespace. Each BPEL process is uniquely identified by QName. Thus, a namespace and a process name are needed. We also need to select the process template and define the service name. We will expose the BPEL process as a SOAP web service, therefore we should leave the Expose as a SOAP service checkbox selected.

   We will use BPEL 2.0 specification, name the process as BookstoreABPEL, add the namespace http://packtpub.com/Bookstore/BooksotreABPEL, and select the Synchronous BPEL Process template. We leave default values for Transaction, Input, and Output, and click on OK, as shown on the following screenshot:

   

What just happened?

We created an SOA composite application with the BPEL process. We can see the composite view already opened under the BookstoreA tab. A composite application usually consists of several service components. The BPEL process is just one component type. The others include human tasks, business rules, mediators, adapters, and Spring components.

The SOA composite view has three sections. The middle part shows all Components, which are part of the composite. In our case, this is the BookstoreABPEL process. In following chapters, we will add more components to the composite. The left part shows Exposed Services. Exposed services are service interfaces exposed to other service consumers. Usually, these are WSDL interfaces (but can also be REST interfaces or events). In our example, the BookstoreABPEL process is exposed through the bookstoreabpel_client WSDL interface, which has one operation named process. The right-hand side shows External References. External references are external services used by our composite. External services are not part of our project. We only use them by referencing their WSDL interface. In our example, we do not have any external references yet. The composite design view is shown in the following screenshot:

We also created the BPEL process. Let's have a closer look. To open the BPEL process, we have to select the already opened BookstoreABPEL.bpel tab. Alternatively, we can double-click on the BookstoreABPEL component on the composite design view (the blue-colored component in the middle of the screen) or double-click on the BookstoreABPEL.bpel file from the project tree in the left-hand side window. This brings us into the BPEL designer:

Each BPEL process consists of a receive activity, which is supposed to receive the initial request. This means that once the service consumer (client) will invoke the process operation on the WSDL interface of the BPEL process, the receiveInput receive activity will receive the request. This request will be a WSDL message, as we will see later in this section.

The other essential part of a BPEL process is the reply activity, which is used by the BPEL process to return the response to the service consumer (client). Remember that we have selected a synchronous BPEL process, which follows the request and response message exchange pattern. Therefore, in the replyOutput activity, the BPEL process will return the response to the client.

Note

The BPEL processes can be synchronous or asynchronous. The synchronous BPEL processes follow the request and response semantics. A service consumer, which invokes a synchronous BPEL process will wait until the process finishes and will receive a reply from the process. This assumes that the BPEL process will finish in a reasonable time and that it will cutely return a response.

The BPEL processes can also be asynchronous. A service consumer, which invokes an asynchronous BPEL process, will not wait for the response. An asynchronous BPEL process might not return any response, or it might use a callback for the response. We will explain the asynchronous BPEL processes in Chapter 5, Interaction Patterns in BPEL.

We will put the BPEL process logic between the initial receive and the final reply activities. Before we do that, we have to create the XML Schemas for the elements and messages used in the BPEL process.