Why Companies Are Embracing a Process-Based Architecture
The industry is in the process of moving to a new application model, one that is fundamentally different from the one we're familiar with.

Today, an "application" is a discrete piece of software that a user opens on his or her computer in order to perform a specific task. In the evolving model, the activities that users click on will call on an underlying layer of interconnected services running within WebSphere Application Server, ultimately providing an infrastructure layer, transparently providing software automation to perform business processes as required. This infrastructure change is driven by:
1.   The need to change applications rapidly to meet evolving requirements. This is not new, but has been exacerbated by the Internet and the real desire to have more loosely coupled external trading collaborations.
2.   The need to integrate existing applications, data, and processes to automate value chains. This is in essence what the industry is describing when referring to "process driven architectures" - i.e., integrate rather than throw away. Corporations are driving this need to integrate in order to reduce total cost of ownership (TCO) and increase return on existing investments (ROI).

The emergence of a reliable, shared, standardized infrastructure based on the J2EE standard, such as WebSphere Application Server, and a service-oriented architecture (SOA) has been a predominant force in enabling this application infrastructure change described above. And, today no company wants to write an application from scratch. The ability to use a large number of services common to all applications (security, transaction, connection pooling, messaging, etc.) is the nirvana on which the J2EE platform was originally sold.

This same model can be applied to application service pieces to answer questions such as "Why can't I apply services that are common to my business across different business scenarios?" and "Why can't I do it at a higher level of abstraction?" Let me put it another way: enterprise development of WebSphere applications can involve as much as 18 million lines of code. How are you going to deliver this - on time and to budget, and then maintain and update it - without abstraction?

This touches upon another industry nirvana, component-based development (CBD) and software component reuse. Reuse, a primary focus of process-driven architectures, is the ability to reuse frequently used processes, subprocesses, and frequently used activity or component patterns throughout an organization.

Business process management is right there at the convergence of metadata-driven components, using Web services to solve EAI-type requirements and using process activities as an interface to a service for reuse.

Applications are more maintainable because the "process" is not hard-coded but instead described by an XML definition and deployed in real time. This enables flexibility and responsiveness to change at the most volatile architecture layer, that which implements business policies and procedures.

If applications comply with the same business process metamodel, one has a greater chance to be able to compose and recompose these processes across applications, provided that their respective process engines interoperate (design-time composition/orchestration, runtime choreography).

Declarative component reuse becomes achievable as activities become the interface to services that are "new" or "wrappered" legacy processes/components exposed in the middle-tier platform fulfilled by business rules, i.e., we achieve modular, reusable software components that can be manipulated visually in a declarative design tool.

The idea here is that we take the object-oriented idea of reuse and essentially repackage it with reuse by "specification." Process activities can be customized and their properties altered to be reused in different scenarios.

In addition, BPM addresses another aspect of application development, the ability to support long-running units of work. In the past, transaction processing systems have provided a synchronous link between the consumer of the data and the data itself. As applications are more and more integrated with their environment, one cannot expect to have the whole world synchronously (and transactionally) connected to applications. We need the ability to selectively couple our architecture, i.e., to make sensible choices about where it is necessary to have tightly coupled or loosely coupled endpoints.

Ultimately in today's business and technology environment it's not just about connecting application A to application B; it's about taking a set of applications, applying a business process flow to control the integration and a set of rules to ensure data and transactional consistency, and then exposing this aggregate application using whatever middleware is appropriate.

When to Implement a Separate Process Layer
Many companies that have designed, or are thinking of designing, their middle tier using a granular service approach find that they need a layer that coordinates the services to provide an aggregate service. This has often been done in a piecemeal fashion in which complex code resides in session beans that are viewed as "fat" service objects in the middle tier. Moving "process" from the business logic layer into the process layer considerably increases flexibility for the following reasons:
1.   A change in the process definition does not then necessarily require a modification of business services.
2.   The processes become "visible" and are able to be rapidly changed/ amended and redeployed.
3.   BPM provides the ability to monitor, audit, and escalate processes. This provides the ability to identify and deal with processes that are not working, while also providing real metrics to the business: Which are the most popular services? Which services are regularly escalated, etc.
4.   Volatile rules in the business services layer can be externalized. Examples of this are decision points that can be externalized in the process model and changed at runtime.
5.   A process flow layer can be used to connect different user interfaces to the same business service. Business analysts can do process modeling and maintenance.
6.   In using the worklist aspects of BPM, organizations have the ability to "push" work to users - this is being referred to as fulfillment of the "last mile" of workflow and EAI. Many companies that are looking to automate and drive back-office value chains use BPM in this way.

The Relationship Between Process and Web Services
One of the big questions within the IT industry, and particularly in the areas of EAI and BPM, is how do Web services help businesses? In a business process context, Web services themselves are in some ways at the very edges of the business processes in that they provide a loosely coupled invocation mechanism to the "units of work" that are implemented by back-office or legacy applications. These are traditionally exposed via proprietary APIs, but increasingly EAI vendors are allowing access to their connectors over SOAP, enabling them to be composed within the various business processes.

Taken in this context, Web services won't always be appropriate, as it is likely that in certain scenarios you will require robust persistent-based durable messaging. In this case it is likely that you will implement a more traditional EAI hub-and-spoke infrastructure, perhaps using JMS as the standard access mechanism. Your application requirements will dictate the type of coupling that you use.

However, there will also be cases when you have low-volume transactions with existing legacy that you are able to elegantly expose through a Web service entry point. This model enables organizations to quickly, and with little cost, allow connectivity to legacy, and is increasingly being utilized within internal firewall boundaries.

Consider the case in Figure 1. Here we can see an example of a business process designed in Versata's Process Logic Designer that utilizes Web service process activities to communicate with an external credit card verification system and an internal legacy goods ordering system whose Web service endpoint could be exposed through an EAI vendor's connector. In this scenario we are utilizing Web services within our process flow to rapidly satisfy application and business requirements.

BPM vs EAI
BPM is closely related to the problems that are traditionally addressed by EAI. However, BPM is built on a service-oriented architecture. This architecture, as discussed, changes the economics of integrating disparate applications and business processes.

BPM lends itself to smaller initial projects, allowing companies to build incrementally. Also, most BPM solutions feature server-based pricing with drastically reduced requirements for specialized consulting services, which is a necessity with proprietary adapter and scripting language-based EAI solutions.

For any company wanting to invest in the service-oriented architecture approach, BPM adds the capability to automate long-running, multistep business transactions that span heterogeneous systems.

BPM solutions based on Java and J2EE leverage existing skills within the enterprise. Analysts are able to declaratively specify business processes and in-house developers can, where needed, leverage their Java-based skill sets to implement them.

BPM Standards
Given that an end-to-end business process can extend across technology platforms and encompass several different vendors, it stands to reason that vendors and companies are keen to promote standardization of business process modeling, execution, and interactions.

Currently there are many different standardization initiatives, which has resulted in confusion rather than the compatibility for which they were intended. These include:

WSFL
Web Services Flow Language (WSFL), was defined by IBM and is a proposed standard that addresses workflow on two levels:
1.   It takes a directed graph model approach to defining and executing business processes.
2.   It defines a public interface that allows business processes to advertise themselves as Web services.

WSFL can be used to model processes that move from one activity to the next, where decisions are made at each control point, using an XML syntax that can be read by both humans and machines. By consuming WSFL, a workflow engine can walk through business processes activity by activity, control point by control point. WSFL has now been superceded by BPEL4WS.

XLANG
XLANG , a Microsoft specification that is an XML-based language, describes business process interactions. XLANG is implemented within Microsoft's BizTalk server and its BizTalk Orchestration Designer can compile XLANG schedule drawings into XML-structured XLANG schedule files. Because XLANG is XML-based, its schedules must comply with XML rules for well-formed documents, which means it must conform to a specification or standard schema. XLANG has also been superceded by BPEL4WS.

BPEL4WS
BPEL4WS is a relatively new standard from Microsoft, IBM, and BEA. This standard supercedes a previous Microsoft standard, XLANG, and a previous IBM standard, WSFL. It describes the manner in which different participants in a process collaborate from a single participant viewpoint, i.e., rather than relating the process from a holistic viewpoint.

BPMI
The Business Process Management Initiative (BPMI) promotes a standard to describe business processes called Business Process Modeling Language (BPML). BPML describes comprehensive control flow and data flow constructs, providing support for both short and long-running transactions, including compensating activities. BPML also provides support for exception handling and timeouts. However, it does not address such issues as authentication and nonrepudiation.

UML 2.0
It would be relatively easy to forget UML, but process definitions themselves are analogous to a UML activity diagram. UML is extensible and as such can be adapted to many applications. In fact Versata has used this ability to define its own "rules" stereotype.

ebXML
UN/CEFACT and OASIS have collaborated on ebXML, an end-to-end stack of protocols and specifications for conducting electronic business using the Internet. ebXML predates the Web services paradigm and has been discussed as an alternative to Web services, however, this somewhat misses the point. Web services technology currently does not provide adequate support for business transaction services. This, however, is what ebXML was designed for (think EDI-style information exchange) and where it clearly distinguishes itself from Web services.

It is likely that at some point there will be a merging of some of the technologies used in the Web services model and ebXML. An example of this is UN/CEFACT and OASIS recently adopting SOAP as the basis of the ebXML messaging infrastructure. For its part, the W3C is evaluating the ebXML specification and will likely incorporate aspects of the specification that they feel meet requirements missing from the Web services architecture.

EDOC
The Object Management Group's vision for EDOC is to simplify the development of component-based EDOC systems by means of a modeling framework based on UML 1.4 and conforming to the OMG (Object Management Group) Model Driven Architecture. In particular they are striving to achieve:

This approach has a lot of merit and can be seen as the basis for achieving a Model Driven Architecture (MDA).

Wf-XML
The Wf-XML standard, designed and supported by the Workflow Management coalition, is designed to support process-level interoperability. Wf-XML defines a set of operations that can be carried out to start, interrogate, and terminate a process using an Internet/Web services-style paradigm. Although Wf-XML is not based on the SOAP standard, and the operations are not defined in WSDL, it is an applicable standard for Web services, specifically aimed at business process/workflow runtime interoperability. The WfMC recently announced Wf-XML SOAP bindings for interoperability standards support.

The Versata Logic Server is based on a Wf-XML implementation and Versata has done some work in designing additional process artifacts that tie this in with Web services support.

The Workflow Management Coalition has already spent over nine years facilitating this set of standards that enables processes to be used across organizations. We believe that what is essential is the description of the process and the ability for interoperability.

Conclusion
Although a standard business process language would be great to have, the reality is that, with competing standards, this will be in flux until a dominant one emerges. Make no mistake, however. This is fundamental to achieving business process integration and collaboration. The ability to have technology-independent metamodels "behind" BPM is where the "rubber meets the road."

References
BPEL4WS: www-106.ibm.com/developerworks/ webservices/library/ws-bpelcol1
BPML: www.bpmi.org.
Positioning paper comparing BPML and BPEL4WS: www.bpmi.org/downloads/BPML-BPEL4WS.pdf
Proposal from the UML 2.0 members concerning process models: www.omg.org/cgi-bin/doc?ad/01-11-01
ebXML: www.ebxml.org
More information on EDOC and MDA: http://omg.org
Wf-XML: www.wfmc.org