Preparing an asynchronous example

In Chapter 2, Service Invocation, Chapter 3, Variables, Data Manipulation, and Expressions, and Chapter 4, Conditions and Loops, we have implemented the book warehousing process, which selected the most appropriate bookstore in order to warehouse the books. It selected between four bookstores, BookstoreA, BookstoreB, AnotherBookstore, and VintageBookstore. The selection criteria included the stock quantity and the publishing date of a book.

In this chapter, we will build upon the example from Chapter 4, Conditions and Loops. However, the BookWarehousingBPEL process in this chapter will have to be asynchronous. In Chapter 4, Conditions and Loops, we were not familiar with asynchronous processes yet. Therefore, we implemented all processes as synchronous. In Chapter 5, Interaction Patterns in BPEL, you learned about asynchronous processes and invocation. In contrast to a synchronous process, an asynchronous BPEL process does not require the client (process consumer) to wait for the BPEL process to end. It also does not return a response. Rather, it uses a callback invocation to return a result (if required, some asynchronous processes might not return anything).

Note

Human tasks are asynchronous by nature. As human users need to fulfill the human tasks, it is impossible to foresee how long it will take to get a response from a human task. Therefore, all human interactions are modeled with an asynchronous message exchange pattern. Remember that an asynchronous interaction does not require the client to wait for the human task to complete, which is the only logical choice, given the fact that we cannot foresee when the user will fulfill the human task. This means that BPEL processes which will use human tasks should also be asynchronous.

As human tasks are asynchronous, the BPEL process that will contain the human task should also be asynchronous. Although in theory a synchronous BPEL process could contain the human task, it is not a sound design practice to have a synchronous component containing an asynchronous component. Because a synchronous component would depend on an asynchronous component, we could not guarantee synchronous behavior for the first component. In other words, as human tasks are asynchronous by their nature, it would make no sense calling the asynchronous human task from a synchronous BPEL process. A synchronous BPEL process requires the client (process consumer) to wait for the outcome of the process, which it provides through the <reply> activity at the end of the BPEL process that returns the outcome. If we include a human task into a synchronous BPEL process, we have no idea when a human task will be fulfilled. It could take minutes, hours, days, or even weeks, if the user is on vacation. Therefore, making the client wait for the response would be a bad design practice. A much better choice is to make the BPEL process asynchronous as well. This way the client will not wait for the response and will anticipate that it can take a while to get the outcome. Therefore, remember that human tasks should always be invoked from asynchronous processes.

Now, let us convert the BookWarehousingBPEL process into an asynchronous process.

Have a go hero – converting BookWarehousingBPEL to an asynchronous process

It is your turn now. Let's convert the BookWarehousingBPEL process from a synchronous process to an asynchronous process. You should perform the following steps (and refer to Chapter 5, Interaction Patterns in BPEL, for more information):

  1. In the WSDL, add the callback port type and the callback role for partnerLinkType.
  2. In the BPEL, modify the partner link to include the new role.
  3. Also in the BPEL, replace the final <reply> with the <invoke> callback activity.
  4. In the composite diagram, double-click on the exposed service endpoint of the BPEL process and add the callback port type.
  5. Modify the way BookOrderManagementBPEL and BookOrderForEachBPEL invoke BookWarehousingBPEL. Instead of using a synchronous <invoke>, you should use a pair of <invoke> and <receive> activities. The <receive> activity will wait for the callback.
  6. To make the example even better, convert the BookOrderManagementBPEL and BookOrderForEachBPEL processes to asynchronous processes as well. Use the same steps as described earlier.

Note

Alternatively, you can download the prepared project, where the process has already been changed into an asynchronous process. This way you can progress with the rest of this chapter immediately. The project is called Chapter9initial and is part of the code samples for this book.

After you have converted the BookWarehousingBPEL process (and the BookOrderManagementBPEL and BookOrderForEachBPEL processes) from synchronous to asynchronous, the composite diagram for our application should look like this:

Have a go hero – converting BookWarehousingBPEL to an asynchronous process

You can also look at the asynchronous BookWarehousingBPEL process. Notice the <invoke> callback activity at the end of the process, instead of the synchronous <reply> activity.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset