Calls to a business process can take between a few milliseconds and a few days to complete. The variability lies in the coarseness of the business process as well as the dependent business activities. For example, from the time that a client submits an order to the time it becomes available for pickup by a shipping company may be a few minutes or a few days. In fact, the most interesting business processes will have this variability associated with them, whereas the length of business activities tend to be much more predictable. On the other hand, the aggregation of business activities to fulfill a business process complicates predictability.
Several application requirements come into play when determining what to do with unpredictable and long-running business processes. First, consider that clients usually use browser-based mechanisms for accessing applications based on Web Services and business processes. Users of browser-based interfaces do not expect a long wait for a business process to complete. To facilitate a 10-second response time in a browser-based interface (the generally agreed upon upper limit of a client's patience with browser-based interfaces), the core of the application logic must execute relatively quickly. Consider the number of layers of application above the business logic before you calculate the amount of time your business process has to respond:
A browser-based user interface rendering mechanism must translate the user 's action into actionable steps and then translate the results of the action(s) back to a graphical interface.
If the business process leverages Web Services, the request must flow through the requesting language into the Web Services paradigm and then back into the language of the service implementation.
Each step of the previous process is separated by an interprocess communication mechanism and, possibly, physical distance. These variables make the amount of time spent on communication between business activities the most unpredictable variable, eating up anywhere from a small percentage of your 10 seconds to more than 10 seconds.
The second influence on your asynchronous business process, from a requirement point of view, is the increase in browser-based interactivity and the acceptance of mail-based notification mechanisms for business process completion. Clients tend to accept that server-side business processes are complex, but they do not accept situations where no quick response occurs on the progress of a business process. In the event that the client has a session available, a Web application can deliver asynchronous notifications to the client when the business process makes progress. More often, the client's session is closed and Web applications should use email notification. In fact, the simplicity of email notification for delivering information on the progress of a business process quickly drives you toward this latter solution.
The notion of asynchronous behavior helps mitigate the unpredictable nature of business processes. This chapter examines asynchronous business processes in the Web Service environment. This chapter does not address how to provide notifications to a client that uses an asynchronous business process.