So far we have talked about operation invocations. A BPEL process explicitly invokes an operation on a service or another BPEL process. Operation invocations are the most common interaction models used in software development. They require that the caller (service consumer) explicitly calls a service (also referred to as a service provider) by invoking a specific operation. This means that we need to know explicitly who we are calling. In cases where we would prefer a more loosely-coupled interaction, without explicitly stating who we are calling, operation invocations would be insufficient. This is where events come in.

An event represents an occurrence, something that happens or is regarded as happening, especially one of some importance. It enables a different interaction model, a model where it is not required to explicitly call a service. Rather, it is sufficient to trigger an event. Once the event is triggered, all services subscribed to this type of event will be invoked automatically.

An event-driven interaction model enables us to create a very loosely-coupled interaction. The one that triggers an event does not know which services are subscribed to that event. Therefore, it does not know which services will be invoked. Also, vice versa, the service subscribed to an event does not know who has triggered the event.

Business processes may be triggered by events. For example, let's imagine a process that takes care of book shelving. This process may be executed on different occasions, such as when the books arrive to the bookstore for the first time, after a customer has looked at the books, and during an inventory. Instead of explicitly invoking the process on each occasion, such a process could react on a corresponding event. A business process might also trigger an event. For example, the book warehousing process might trigger the event to bookshelf the books.

Business processes may have to react on events. Particularly long-running processes, which contain human interactions, often need to react on events. For example, in the previous chapter, we have added a human task to our book warehousing process where a user has to approve the selected bookstore. As it is usually not possible to foresee how long a user will need to complete a human task, we might want to add other measures to be sure that a certain BPEL process does not get stalled. For example, let's suppose that we would like to limit the total execution time of a specific BPEL process. We can achieve this using events and event handlers.

A second example would be a scenario where a business process has been initiated and is in progress; however, we would like to provide a possibility to cancel the process instance at any time. This is the case in many business processes, for example, in an ordering process, a client might place the order and change his or her mind after a certain time while the order is still being processed. In a bank, a client might apply for a loan and while the bank is deciding whether he is eligible for the loan, the client can change his mind.

Also, in our book warehousing process, where the processes select the appropriate bookstore to warehouse the books, we might have the need for handling events. In Chapter 9, Human Tasks, we have added a human interaction to the process. Therefore, we might handle both previously-described situations—limit the total execution time and handle cancelations (for example, if the books would be damaged during transport or similar situations).

Before we get to the example, let's just mention that events are also very useful with asynchronous invocations. In Chapter 5, Interaction Patterns in BPEL, we learned how to invoke services asynchronously. However, with events, we can wait for several incoming service calls simultaneously. Alternatively, we can limit the time waiting for an incoming call. We will talk more about this in the second half of this chapter.

<wait>
  <until>'2014-03-18T21:00:00+01:00'</until>
</wait>
<wait>
  <until>'18:05:30Z'</until>
</wait>

<wait>
  <for>'PT4H10M'</for>
</wait>

<wait>
  <for>'P1M3DT4H10M'</for>
</wait>

<wait>
  <for>'P1Y11M14DT4H10M30S'</for>
</wait>