Understanding the Asynchronous Business Process Structure

An asynchronous business process structure is different from an asynchronous thread of execution in a programming language. A thread is a transient structure that a platform introduces. The thread is bound to the length and boundaries of an application. A business process is a long-running process that can span applications and the length of an application.

Within a platform's representation of a thread of execution, there is typically a mechanism for the programmer to identify a particular thread and, subsequently, manipulate the thread via an identifier. With the Java platform, this mechanism is an object reference that an application holds to the thread. This reference is good only for the life of the application. The challenge in a Web Service environment, or even in a Java platform environment, is to create a mechanism for identifying a process that spans the life of an application. Web Services further this challenge to give a mechanism for identifying a process that also spans platforms and languages.

Figure 9-2 illustrates the basic structure of an asynchronous business process. The asynchronous business process representation assumes more of a job management structure than a single process structure. Internally, the service launches jobs and maintains their state. The interface to the BusinessProcessManager contains both methods to create business processes, as well as methods to determine the status of a particular business process. The BusinessProcess is a similar structure to that described in the previous chapter. An additional persistent object, ProcessState , is necessary to maintain information pertaining to a particular process. The process information often duplicates the data held by a particular business process. Considering that a thread running a business process will eventually terminate and disappear, the process state information remains available after the active process terminated . You can use this process information either to recover a process after a system crashes or to obtain process information after the entire process finishes.

Figure 9-2: Structure of the Asynchronous Business Process pattern

The complexity of the asynchronous business process exists because of the need to track multiple processes. Consider that a client has no way of maintaining state in most Web-based application architectures and therefore cannot maintain a connection with a business process spawned by their request. Instead, clients require a unique identifier returned by the business process to identify the business process to the server. After process creation, clients make > requests relative to particular business processes by passing in the unique identifier that the service uses to locate the particular thread or results or status.

Understanding the Components of an Asynchronous Business Process

In addition to the business process components identified in the previous chapter that form the structure of the Business Process pattern, two additional classes form the structure of the Asynchronous Business Process pattern:

BusinessProcessManager: The BusinessProcessManager is responsible for surfacing a way to start a business process and operate against an individual business process. A manager returns a unique identifier on creation of a new instance of a business process, or it uses that unique identifier for identifying a particular instance of the business process. The BusinessProcessManager facilitates the ability of clients to look up attributes of a particular business process that they may be interested in, such as the progress of an order. The BusinessProcessManager conceptually contains zero or more BusinessProcess instances as well as a ProcessState object instance.

ProcessState: Instances of the business processes are transient in nature because the process has a well-defined start and termination point. However, the transience crosses application invocations instead of the normal definition of a thread of execution in a program. The ProcessState instance retains information about the specific business processes and any information that a client or server may need after a process completes. This information may also be valuable in the event that the process manager crashes or goes down for system maintenance.

Not illustrated in Figure 9-2 are the mechanisms that act between the business process manager, business processes, and the process state object instance. The BusinessProcessManager will likely have a thread pool at its disposal in which to start business processes. Upon termination, the threads return to the pool and the final process state information remains in the process state object instance. The process state may leverage a database for persistence, and thus the process manager uses an object/relational mechanism for gathering information about the final process state.

In aWeb Service environment, it is highly unlikely that the interface to the business process manager is a generic, object-oriented, highly dynamic job manager. Although a particular process manager may use a generic job manager under the covers, Web Services users expect a self-contained component interface without a web of dependencies.

Understanding Asynchronous Business Process Collaborations

Figure 9-3 illustrates a simple design sequence using the asynchronous business process structure described previously. In the sequence, a client calls an instance of the BusinessProcessManager to create a new instance of a business process. The client then returns to the BusinessProcessManager to check an attribute of the business process, such as the status.

Figure 9-3: Asynchronous business process sequence

An interesting disconnect through this structure and sequence diagram is the connection between a business process, the business process manager, and the process state. You have a few options for maintaining the connection between the two design components. One option is to allow each business process to retain its own process state information. In this case, retrieval of process attributes goes to the business process rather than a separate process state object.

A second option puts the burden of coordination of the process and attributes on the BusinessProcessManager instance. In this second case, the BusinessProcess may have event interfaces on it so that the manager can keep it in sync with the process state information in the database. In the end, there is likely a compromise. Much of the state for a business process will reside within the business process itself, and there will probably be a process state object for tracking active processes.