Implementing a Simple Business Process Structure

This chapter does not cover all of the features of BPEL or other metadata models; instead, it focuses on the core constructs involved in creating business activities to build a business process. With these constructs, you can create business processes in Java or any other language. Figure 8-2 shows the structure of the Business Process (Composition) pattern.

Figure 8-2: Structure of the Business Process (Composition) pattern

In Figure 8-2, it is important to treat the diagram as a set of relationships rather than a series of classes and objects. In the case of BPEL, the BusinessProcessImpl is actually a BPEL file with XML-based metadata. A BPEL container receives the file and exposes it via the BusinessProcess , a WSDL interface definition. The metadata defines a sequence of business activities, other business processes, and data relationships between the activities and processes that are necessary to fulfill the complete sequence. A business activity may or may not be another business process.

The business process could also be a set of Java class relationships with the BusinessProcess being a Java interface exposing the BusinessProcessImpl concrete class. The sequence itself becomes an ordered collection of steps to complete a particular business process, and the business activities are other Java classes or Web Services.

Understanding the Components of a Business Process (Composition)

Figure 8-2 is a basic Business Process (Composition) pattern. Depending on the mechanisms you use to construct a business process, the method of processing a sequence of business activities can be extremely complex. Further, the way the data flows between business activities can become complex as well. The primary components of a business process are the following:

BusinessProcess: This is the interface to the business process. In reality, there are multiple interfaces to the business process that all represent the same process but are built for different consumers. One registered with UDDI represents a common interface to the business process for any architecture to use or implement a Web Service adhering to the interface guidelines. This interface does not contain binding information. Instead, it is like an interface with no concrete implementation behind it ”simply a specification to the Web Service that others could build. Other interfaces in UDDI are associated with specific instances of the business process that clients bind to for usage. Finally, the interface in UDDI is translated to a language-specific interface that clients write the business process implementation to in a specific programming language such as Java. Web Service users call the final interface and implementation through the interfaces registered with UDDI. Businesses look up the WSDL version of the interface via the UDDI query mechanisms and use it as a means of determining the contract for a business process for client usage or for implementation of the business process.

BusinessProcessImpl: The business process is the service implementation of the business process interface. As Web Services mature, there will be fewer complex business processes in Java and more residing in generic metadata languages processed by business process engines. BPEL is one of these metadata languages. Before metadata implementations of business processes are ubiquitous, metadata languages must address security, transactional mechanisms, and performance. The implementation class, combined with the business activities themselves , contains the logic to form a complex state machine. In the case that the process is simply a set of steps with no complex logic, the process implementation can simply execute each activity in the ActivitySequence in order.

ActivitySequence: The sequence is the list of business activities that must occur before the business process completes. This sequence does not have to be synchronous in nature, and it is not required to follow a single path . Several steps in the business process may execute asynchronously, with synchronization points built into the process. Further, complex branching implemented in a business process implementation may select the proper business activity based on data collected as the sequence progresses. For example, if a customer resides within five miles, you would want to schedule one of your trucks to deliver coffee rather than submit the order to a shipper for pickup and delivery.

Data: Each business activity may have side effects in the form of new data that other business activities require. For example, when creating an order, you want to retrieve the credit card number for a customer and use the customer identity as a key to an order. In both cases, the business activity simply retrieves the customer identifier from a common pool of data. Like the sequence itself, different data may route to a particular business activity based on the results of some of the data or on the results of a business activity. For example, a pound of coffee that a customer purchases as a gift would not ship to the customer's address; instead, it would ship to an alternate address. In this case, you must ensure that the business activity used for shipping obtains the alternate shipping address rather than the primary shipping address.

BusinessActivity: Each business activity is a unit of work that is a prerequisite to completing a business process. A business activity may itself be a business process but is not required to be one. Instead, the designer that breaks down the system for implementation is responsible for choosing the correct coarseness for a particular business activity. A business activity could even be a single method call on an object.

Throughout the previous definitions, I have purposely stayed away from tying one of the components to a particular implementation. There is no reason that each of the above units must be a class in Java. Instead, look at the business process as a composition of completed steps that affect the business; you can worry about the concrete mechanisms to implement the business process later in the chapter.

Understanding Collaborations Between Business Process Components

Clients access a Web Service defined by the BusinessProcess . The BusinessProcessImpl implements the BusinessProcess and processes the client request after invocation. Typically there will be a start() operation or similar operation (the Command pattern forms a simple business process structure and can have a similar interface).

The business process implementation processes the sequence of business activities based on data the activities may have stored as side effects of their execution. There are varieties of logical conditions that may be applicable between sequential steps of a business process, depending on how expressive the business process language is. The mechanism used to represent a sequence of business activities must be rich enough to embody all of the business processes in a particular domain. The sequence itself is merely an ordered collection of business activities with enough contextual information to allow the business process to call the activities in the appropriate order.

The business process implementation and business process activities are responsible for maintaining data and moving it to individual business activities, whereas the business activities use the data to determine how to process an individual step in the business process. Figure 8-3 shows a sequence diagram illustrating the base interactions that fulfill a business process.

Figure 8-3: Business process execution sequence

Business activities are not typically self-contained; rather, they rely on individual business objects, business object collections, or other business processes to achieve a particular task within the business process. For example, creating a sales order in your own application requires constructing an order object (a collected business object) and associating a set of order lines (a collection of business objects). Each of these steps to create and insert data into collections is a business activity that interacts with additional business constructs.