Seeing Business Processes in Practice

The business process as a formal unit of computing is an extremely difficult concept to understand and fully utilize for many reasons:

• Business process concepts overlap with common computing architectures and styles: This overlap makes it difficult to legitimize the business process over existing computing techniques.

• Business process implementations differ dramatically between companies: In fact, in many companies the way a business process gets implemented gives a competitive edge to the company.

• Large business processes often span multiple companies: Usually there are steps or input in the business process that involve coordination from outside processes and activities.

The concept of a business process is less a computing concept than a business concept. Only recently have people attempted to model the business process as a tangible computing step. Business process computing equates toa set of business objects representing a physical domain, such as a warehouse and its inventory. Instead of using classes to represent a physical structure, you can use business processes to model and deconstruct how a business functions, such as the process a business uses to count stock in a warehouse.

Before business processes were a formal unit of a model, business processes tended to be part of the object-oriented representation of a business or part of the custom logic that lived outside of the business object model. Unfortunately, business processes are extremely fluid in nature, with each company having its own approach to implementing a particular business process. Often, a company's implementation of a particular business process gives the company a competitive advantage over another company. Because of this fluidity , it is difficult to create a single object model that represents all businesses, and, in fact, your application will be at a competitive disadvantage in the marketplace if it imposes a particular business process on the purchaser of an application. Further, businesses that compete in a space based on their business processes need to be able to treat the process itself as a selling point for an application, the object model behind the business process becomes merely a way of accessing data to feed the business process.

A good example of the fluidity of business processes is in the P.T. Monday Coffee Company shipping process. The company works on a model of personal service within a radius of the distribution point, maintaining a "retro" feeling about the company that the customers enjoy; in the morning, a customer can wake up and get fresh roasted coffee at their doorstep along with their milk delivery from another company. This personal service is a competitive advantage to the P.T. Monday Coffee Company and an unexpected twist to most application builders. Not only does the shipping process have to consider traditional shippers, the process must also consider the P.T. Monday Coffee Company itself as a potential shipper of the coffee. By considering an application as a collection of business processes that contains a set of activities that the process carries out, you should be able to quickly locate the activities that need adjustment in the process.

Using Business Process Model Languages

Just as there are standards for modeling object-oriented classes, there are standards for modeling and representing business processes. XML documents represent a model of a business process. At this time, there are two primary standards:

• Business Process Execution Language (BPEL): Proposed by BEA Systems, IBM, and Microsoft.

• Business Process Modeling Language (BPML): Proposed by just about everyone except the BPEL team. The backers of BPEL include webMethods, SeeBeyond, Adobe Systems, and more.

The structure defined in this chapter mirrors the structure of BPEL relatively closely. BPEL is a structured XML representation of a business process. The XML data generated through modeling also runs as a first-class Web Service in a business process engine. The XML data does not have to serve a dual role as modeling and execution language; many business processes could simply exist in a programming language, such as Java, or could even be generated into a programming language from the XML model.

At the time of writing, the primary way of modeling business processes with BPEL is through an enhanced XML editor that represents business processes in a tree-like structure. The long- term goal of business process modeling includes modeling languages that are derivations of workflow modeling and, essentially , advanced flow models.

Understanding the Marginalization of the Object Model

For an object-oriented programmer, the marginalization of the object model is disconcerting at first. Instead, the business process is more of a pure, flat, component model with an interface definition and an implementation. An interface defines a particular business process. In the case of Web Services, this interface is aWeb Service Description Language (WSDL) file identified by a particular technical model (tModel) residing in a Universal Description, Data, and Discovery (UDDI) directory. Each business implements the interface as the composition of one or more Web Services or service implementations, thus the alternate labeling of this pattern as a composition rather than a business process.

A business process can also contain other business processes. Implementing a unit of work breaks down into an atomic business activity that may or may not be a method on an object that is a service implementation.

BPEL even further marginalizes the object model by moving flow logic, such as branch statements and the ability to repeat actions, into XML. Implementing a complex business process with BPEL requires little, if any, complex logic in a particular programming language such as Java. Figure 8-1 illustrates, from a high level, the capabilities of BPEL to create complex business logic. With BPEL, a BPEL container runs a business process definition that is in the form of a BPEL XML document. The business process is a Web Service through the creation and registration of the WSDL document. Clients simply call the Web Service that forwards requests to the BPEL container. The service implementation is the BPEL container and its interpretation of the BPEL definition document related to the BusinessProcess definition.

Figure 8-1: Business process logic implemented using BPEL

The business process leverages a variety of metadata constructs that resemble common programming language constructs. The operations include sequencing, basic logic constructs such as looping, and switch statements. Also, operations included simplify the construction of a business process such as the ability to invoke other Web Services and store data in locations within the BPEL container.

Even with the movement of logic into metadata, there is substantial room for languages such as Java. It will likely be many years , and possibly never, before metadata replaces languages such as Java. Java provides good performance, rich syntax and semantics, and abilities that are not reasonable to implement in metadata. For example, nowhere in the BPEL specification does it talk about persistence or database semantics; instead, Java handles all of the interactions between logic, data, and persistence.

Note  

Despite the advanced state of BPEL, I build the business processes in this chapter using the Java language. As long as you maintain a good structure and separation in the Java implementation, the process should be translatable into BPEL. Interestingly, a consumer of a business process does not know whether you use BPEL because the Web Service that surfaces a particular business process abstracts away the implementation details.

Understanding the Motivation for the Business Process Pattern

Overall, the intent of the Business Process (Composition) pattern is to illustrate and provide guidance for combining business activities into a single, consumable Web Service with a well-defined interface.

This pattern is also an attempt to change your mindset from a Java-language, object-oriented perspective to a business process perspective. Rather than envisioning a Web Service as a reflection of an object model, you start to consider the business process as the primary construct in the application. Eventually, particular business activities within the business process are business object methods or business object collections, but the bulk of the thought goes into design and implementation of the coarser business process.

There is quite a bit of overlap between the concept of the business process and the concept of composition, thus their inclusion in this book as a single pattern. The only time the terms are not interchangeable is when you forgo using business processes altogether and leverage Web Services as an object proxy model. Nonetheless, the general structure easily translates between the two paradigms .