Preface

IBM WebSphere Application Server Enterprise Process Choreographer provides business process support within the WebSphere Application Server. It can be used for the choreography of all kinds of business processes or flows.

The business processes that are implemented in an enterprise typically require a mixture of human and IT resources. The types of business processes can vary greatly, ranging from Web services navigation to business transaction support. Business processes can be automatic, recoverable processes, or processes that require human interaction. With Process Choreographer, you can combine business process technology with any other service offered by the open J2EE architecture.

This paper uses scenarios to show how you can benefit from using Process Choreographer in today's business environment. It explains some basic business-process concepts that are used by Process Choreographer and describes how to develop, use, and administer business processes. Finally, an overview of the architecture is also given.

Back to top

Business processes in today's business environment

Companies today face a growing problem. Business logic and application data are scattered throughout the organization across a multitude of software assets. Much of it resides in databases, packaged applications (such as enterprise resource planning (ERP) systems), or back-end systems (such as, IBM CICS). Other business logic can be found in existing Java and J2EE applications.

With the rise of open standards, business logic and application data will soon be available through internally and externally available Web services. Instead of reinventing the wheel with every new application they build, companies need a way to reuse their existing software assets and to leverage the power of Web services in the development of new J2EE-based applications.

Integrated J2EE workflow capabilities, delivered with WebSphere Application Server Enterprise, offer a new, service-oriented approach to application development called Service Choreography. With intuitive business process-based development tools, you can take existing software assets and quickly define how those assets can be used in a new J2EE application. For example, you might want to combine customer information from a packaged CRM solution and J2EE components from an existing customer-facing application with new business logic to create a new Web-based order entry application. You could then extend the availability of this application by exposing it as a Web service for your business partners.

With WebSphere Application Server Enterprise, developers can visually choreograph the interactions between various software assets. They can work more efficiently because they have a standard way of representing and interacting with virtually any software asset and do not, therefore, have to spend time working with different interfaces and low-level APIs. Drag-and-drop tools allow them to define the sequence and flow of information between software assets. Individual software assets and even larger application workflows become building blocks that can be reused in developing other applications. Further gains in productivity are possible because runtime support for these new J2EE workflow capabilities is fully integrated in the application server to deliver a single administration and deployment environment.

The following sections show how you can use business processes to create applications of various types.

Composition of Web services -- business process-based applications

Traditionally, an application contains code for the implementation of individual business functions (such as "create order entry"), and code for the flow logic of the application according to the business requirements (such as "high-value order messages have to be separately approved"). Whenever the business requirements change, the code must be changed. Usually these changes are to the business flow logic and only rarely do they affect the implementation of the individual business functions.

The use of business processes changes the way applications are built. The process engine allows an application architecture that separates the description of the business logic (the flow logic) from the implementation of the business functions. The resulting application structure is known as a business process-based application. The control flow is managed by a workflow management system, which is responsible for the invocation of the individual business functions according to the business logic.

Programming a business process-based application consists of two independent steps:

• Programming the components -- the individual business functions are implemented "as usual", that is, they are coded, bought, or already exist. The actual representation of a business function can be, for example:
  • An EJB method
  • A JCA connector call that provides connectivity to a back-end system, such as CICS
  • An operation of a (WSDL) port type, for example, a SOAP-based Web service
• Programming the business processes -- the business logic is described as a process that consists of the steps in the process that need to be performed, their relationship to one another, and their ordering constraints.

A business function is assigned to each of the steps in the process. A process step can be an elementary step or a composite one, resulting in a recursive programming model.

Business process-based applications offer advantages over traditional applications because they have a number of properties that are guaranteed by the middleware responsible for their execution. These properties are:

• Concurrency. If a process contains parallel branches, the middleware guarantees that the branches are executed concurrently in parallel threads, possibly even on different nodes in a cluster.
• Recoverability. If the system crashes while executing a process-based application, the execution of the application is continued where it was left off -- steps that have already been performed are not redone.
• Heterogeneous, distributed execution. The execution of the individual functions of a business process (its steps) can be distributed in a network, on heterogeneous operating systems and hardware platforms.
• Range of quality of service. The process engine supports non-interruptible processes (microflows), interruptible processes (macroflows), and combinations of the two.

Involving people

Many enterprises are looking at ways to automate their business processes. Fully-automated processes without human interaction can be executed at low cost, with high throughput and short response times.

However, many real-world processes cannot be fully automated. For example, special approvals might have to be given by an authorized manager, rather than automatically by a machine. Therefore, it is common for business processes to consist of a combination of automated steps and steps with human interaction.

The following figure shows an example of a process that requires human interaction. The process is triggered by the arrival of a message in its input queue. This type of process is also called a message-processing flow or a message flow. Typically, processing of this message requires a combination of steps that implement the business process and produce an appropriate result message. However, when an exception occurs during the execution of any of these steps, the business process requires human interaction for exception handling.

As long as the automated steps are short and do not produce exceptions, the processing of this type of process can be done with high throughput and short response times. Although human interaction is part of the definition of the process, this does not impact its execution if those steps are not actually performed. The business-process paradigm easily supports the description of the entire business process, including the manual steps, as a single process. The process engine is responsible for the efficient execution of automatic processes and for the inclusion of human interaction to handle exceptions.

Undoing complex operations using compensation

Today's applications typically require transactional properties, in particular, the guarantee that a complex request is executed either in its entirety or not at all. For traditional transactions, this is described by the ACID properties atomicity, consistency, isolation, and durability. It is achieved by a transaction manager, resource managers, and back-end systems working together according to the XA standard, or similar, protocol. This cooperation ensures that the operations performed on behalf of a transaction are either all committed or all rolled back.

Often, however, a complex request cannot be run as an ACID transaction for a number of reasons:

• Back-end systems or resource managers might not be able to participate in the XA protocol. Updates to these systems are performed immediately and do not participate in the overall transaction. If the transaction fails, these updates are not undone; the processing of the complex request results in an inconsistent state.
• As long as a transaction has not been committed, none of the changes done on its behalf are visible to the outside world. The isolation property guarantees that they only become visible when the transaction's final state has been reached. This works well for short-running processes that invoke synchronous operations.
  However, when a process involves asynchronous steps, for example, steps implemented by a back-end system driven by JMS messages or steps involving human interaction, intermediate results of the process must be made visible. This means that the JMS message must be sent out, the information about the step the person has to work on (the work item) must be made available, and so on. Therefore, the intermediate state of the process must be committed.
• There are actions in a business process that are inherently non-transactional. Sending a letter to a customer is such an operation -- as soon as the letter has left the sender, there is no way to undo the operation.
• Activities in an interruptible process can be transactional or non-transactional. Transactional activities run in their own transaction, however, in an interruptible process there is no transaction that surrounds all the activities in the process. Therefore, no locks are held to ensure the data integrity of the entire process. If the process fails, compensation can be used to undo the changes that were successfully done by the activities.

In all of these examples, intermediate results of the business process are made available and they cannot be undone by simply rolling back an ACID transaction with the help of the transaction manager. Instead another operation must be done that explicitly reverses the original operation:

• If a back-end system has been called to update data, for example, to increment a value, the system must be called again, for example, to decrement the value.
• If a letter has been sent in error to a customer, another letter must be sent to apologize for the error.

These operations might need to be cascaded if other operations have already started that use the results that have been wrongly made available.

To help you to define undo operations and their automatic execution, you can specify the steps of a process as compensation pairs. This means that in addition to the standard "forward" operation, a "backward" operation is assigned to the activity, as shown in the following figure.

The process runs using the forward operations. In addition, each invocation of a forward operation is logged with its input and output data in a compensation list. At any time during the execution of a process, you know which operations have been invoked and with which data.

If the process fails during its execution and has to be compensated, the compensation list is used to drive the backward execution of the process to re-establish the previous process state. For those operations that were successfully executed during the forward execution of the process, the associated undo operation is invoked, and the original data is passed. For example, the undo operation might send a compensation letter to tell the customer that a previous letter was in error and should be ignored.

The following figure shows the execution of the undo actions for the activities that were performed during the forward execution of the process. For activities that have no undo operations defined, and for activities that were not processed during the processes forward execution, nothing is done.

Business-to-business (B2B) processes

Business processes are typically not limited to applications and people within an enterprise, they also involve business partners. Interactions with these partners can be modeled easily as part of the process.

There are two types of interactions with partners:

• Inbound requests. A request is sent by a partner, either to initiate a business process or to pass data to a running business process as part of a "conversation".
• Outbound requests. A request is sent to a partner, either to initiate a business process there, or to send data as part of a "conversation". A special case of an outbound request is the completion of a business process and the delivery of its results to the partner.

For both types of requests, the interaction with partners involves the use of a WebSphere component, Web Services Gateway. The gateway is responsible for routing inbound Web-services requests to the appropriate WebSphere component, for example, the process engine, and routing outbound Web-services requests to the right partner.

Back to top

Business process concepts

This section explains some of the basic business-process concepts that are used by Process Choreographer.

Business process

The top-level construct of the meta model is the process itself. A process is a multi-step operation. A graphical representation of a process is a directed graph. The major constructs in this process graph are activities and control connectors. The activities describe the tasks to be performed, and the control connectors describe the potential sequence in which the activities are to be carried out. The following figure shows an example of such a process graph.

Activities are represented as named rectangles; the name typically describes the purpose of the activity. Activities have implementations that can involve human interaction, perform synchronous or asynchronous invocations, or wait for incoming events. Examples of services providing synchronous activity implementations are SOAP-based Web services, CICS transactions, and EJB method invocations. An example of an asynchronous invocation is sending and receiving a message via JMS.

Control connectors are represented as arrows; the head of the arrow describes the direction in which the flow of control moves through the process. The activity where the control connector starts is called the source activity; where it ends is called the target activity.

There are two types of business processes: non-interruptible processes (microflows) and interruptible processes (macroflows). The main differences between the two are their transactional behavior and the size of their footprints.

Activities

There are different types of activities to address different types of tasks. Process Choreographer supports the following types of activities:

• Elemental activities
• Person activities
• Receive event activities
• Process activities
• Empty activities

Elemental activities are used to invoke operations or services. There are two supported styles.

• Elemental activities that invoke a synchronous operation, such as an EJB method, a Java snippet, a J2EE connector, or a SOAP service. This includes elemental activities that just "fire and forget" an invocation. Examples of this are sending a JMS message without waiting for a response or sending an e-mail.
• Elemental activities that invoke asynchronous services, such as a service with a JMS message binding and receive a response later.

Person activities are used to include human interaction in a process. When a person activity is reached in a process, a work item for a person or a group of people is created. Finding the right person to do the job as defined by the requirements of the process and according to the definitions in a central directory is called staff resolution. A person can check whether a work item has been created for him. If this is the case, he can accept to do the work by claiming the work item. When the person has finished the work item, he makes the resulting data available to the workflow system. After this, the process navigation continues.

Receive event activities allow the process to wait for outside events. For example, a process that handshakes with another program (may be a partner process), sends off messages, does something, and then eventually waits for an external trigger to continue its operation. Events are sent to a process using the Process Choreographer API.

Process activities are used for nesting processes. A process can call other processes that call other processes, and so on. This construct allows you to create hierarchical processes. It also allows you to reuse process logic by factoring it out as a subprocess.

Empty activities do not perform operations. Instead they act as explicit synchronization points for parallel branches in a process, or to allow explicit join or branch nodes.

Activities in a process manipulate data; input data is passed to a process and output or fault data is returned by the process. Within the process, data is kept in global variables. Mapping activities, implemented by Java snippets, can be used to transform data. These mapping activities take their input from one or more variables. The result is written to another set of variables. To invoke an activity that requires an input message, variables are read. If the activity produces output or fault data, then this data is mapped back to the same or another variable.

Non-interruptible processes (microflows)

Non-interruptible processes have the following characteristics:

• They are short-running.
• They run in one transaction or without a transaction.
  If a process runs in a transaction and it contains only transactional activities, it is known as an atomic sphere [1].
• They can contain activities with transactional and non-transactional implementations.
• They cannot have asynchronous activity implementations or activity implementations that involve human interaction.
  Asynchronous request-response operations require that a transaction commits to send the request. Processing the result of the request is then performed in a new transaction. A response is not expected for asynchronous notifications. Therefore, sending notifications is supported in non-interruptible processes. Receive event activities require their own transaction for receiving an event and therefore are not supported within non-interruptible processes.
• All activities in a non-interruptible process are processed in a single thread. Therefore, all activities share the same thread context.

The following figure shows a non-interruptible process and its transaction boundaries.

Process Choreographer version 5.0 supports only transactional non-interruptible processes. When a transaction rollback occurs, the transaction manager rolls back all of the transactional activities of a non-interruptible process. Activities with an implementation that is not transactional remain untouched.

Non-interruptible processes provide developers with the benefits of visual modeling, easy maintenance, and graphical debugging. They can be used in all cases where a developer would start writing Java code to define the interactions of enterprise beans, Java classes, J2C connector interactions, Web Services, and so on.

Interruptible processes (macroflows)

An interruptible process is the type of process known from existing workflow systems, such as WebSphere MQ Workflow. An interruptible process can navigate to an activity which, for example, requires human interaction or a response from a remote service and wait for hours, days, or even years until the expected event occurs.

An interruptible process consists of a set of stratified transactions [3]. This means that in a process that contains a set of activities each navigation step is performed in its own transaction. For example, the following actions occur when an activity that performs a synchronous service invocation is processed:

1. Begin the transaction
2. Get the message carrying the Boolean value of the connector from the persistent process-engine message queue
3. If all incoming connectors have fired, check the start condition:
• If true, start the activity, that is, invoke the synchronous service
• If false, skip the activity
4. Put a message for each outgoing control connector in the persistent process-engine message queue
5. Write the state changes to the database
6. Commit the transaction

If an activity is non-transactional, that is, its activity implementation does not participate in the 2PC protocol of the transaction, compensation-based recovery can be used to undo changes performed by the activity if a failure occurs.

The following figure shows the transaction boundaries in a simple interruptible process.

Interruptible processes support all types of activities. The actions performed in the transaction depend on the semantics of the respective activity type. To illustrate this, the following figure shows a complex process that uses almost all types of activities.

To reliably hold the navigation information of a process, the database stores the persistent state of the process and the messaging system holds the persistent navigation state, that is, the information about which activities in the flow will be navigated to next. The database, the messaging system, and the transactional resources used by an activity implementation all participate in a two-phase-commit protocol. Because the complete state of a running process is stored in the database, a process is not dependent on a specific application server. Interruptible processes have a much larger footprint than non-interruptible processes because they use persistent storage and transactions.

When an interruptible process is run in a cluster, each process step can be performed in parallel on any node. The load is automatically distributed over the different servers.

Interruptible processes are completely forward recoverable. If the application server that is processing an interruptible process terminates unexpectedly, no information is lost. The process either continues on another node in the cluster or, in non-clustered applications, waits until the server comes up again. Interruptible processes are therefore said to have phoenix behavior [1].

Life cycle of a process

A process comes to life when a Process Choreographer API method that can start a process is invoked. The supported API methods are call and initiate:

• When initiate is invoked, a response is not returned to the caller when the process finishes. However, by using people, asynchronous, or receive event activities interaction takes place between a process and the process starter, other people, or other services.
• When call is invoked, the process starter receives a response when the process finishes. The response mechanism can be as simple as returning a result from a synchronous non-interruptible process. Alternatively, a reply context can be provided when the process is called. This context is used by the process engine when the process ends to send back the response.

When a process is started, a process instance for an existing process model is created and started. The process engine then starts navigating the business process. That is, the process engine determines which of the activities of the business process are activated and in which order. Regular navigation of a process continues until all of its activities are in their end state. Valid end states are finished, failed, expired, or terminated.

A process ends either when one of its fault terminals is navigated or when all incoming control connectors of the process sink have been evaluated. If the process was started using call, a response is sent back to the caller of the process.

See the description of the business process engine's navigator for more information on state transactions of an activity instance.

Back to top

Developing, using, and administering business processes

Developing, using, and administering business processes involves several different tools:

• WebSphere Studio Application Developer - Integration Edition (WSAD-IE) allows you to create, deploy, install, test, and debug process applications. WSAD-IE integrates a base development environment for Java classes, servlets, JSPs, EJBs, and static HTML pages with the powerful enterprise functionality of creating Java connectors and Web services.
• WSAD-IE offers choreography for dynamic artifacts through Process Choreographer processes.
• Process Choreographer provides a ready-to-use Web client that allows workflow participants to access workflow applications and their business processes.
• WebSphere Application Server provides an administrative console for the administration of business processes.

Developing processes with WSAD-IE

In a typical process-development scenario, business analysts and domain experts define the business process on an abstract level. This includes defining the process, its activities, and the conditions that determine which path of the process is executed and when.

The implementation of the process is then developed. This includes specifying which services implement which activities. These services can either access functionality in a back-end system, such as CICS or IMS via Java Connectors, or access services in an ERP system using Web services. The activities that involve human interaction must also be created. GUI pages and queries must be defined to best support the staff that will work with the application.

You can do all of these tasks without leaving the WSAD-IE environment. When the application is ready to test, you can deploy and install it in the unit-test environment of WSAD-IE. The debugging and tracing functions provide a very efficient way to get a process application ready for production.

When the process application has been sufficiently tested in WSAD-IE, you can deploy it in the production system. Apart from the additional installation of process archives (FARs), the installation of an enterprise application with processes is identical to the installation of any J2EE application. The following figure shows the creation of an enterprise application in WSAD-IE and its installation in a WebSphere production environment.

Working with processes, work items, and worklists

The Process Choreographer Web client is based on servlets and JSPs. You can use the Web client as is without having to implement any code. This allows you to develop and present user-centric workflow applications without any upfront investment in user-interface design.

However, workflow user interfaces often require customization to adhere to specific business-process scenarios or to the corporate look and feel of existing Web sites. Process Choreographer provides a tutorial and coding samples to help you change the appearance of the Web client while preserving standard workflow end-user interaction.

Work items (also known as assignments) are the means by which "pieces of work" are assigned to people. A user can interact with a Process Choreographer application using the Web client only if a work item has been created for him or for a group of which he is a member.
To determine if there is a work item waiting, the user performs a query, such as work-item query. The query result is the work items that match the query conditions. Process Choreographer supports both ad-hoc queries and predefined queries. Predefined queries are stored as worklists.

A work item represents a relationship between a person or group of people and an object, typically a specific activity instance. The relationship is further described by attributes that specify the type of object and the reason why this object is assigned to the user.

Work items are created by the process engine when the following happens:

• A process is started.
  Then the following work items are created:
  • A work item for the process starter
  • A work item for each process reader
  • A work item for each process administrator
  The process starter is the person who started the process. Process readers are people with the right to read the values of the process and all its activities. Process administrators are people with the right to manage the process. This includes, for example, forcing a process into an end state if certain error conditions occur.
• A person activity becomes ready.
  Then the following work items are created:
  • A work item for each potential owner of the activity
  • A work item for each reader of the activity
  • A work item for each editor of the activity
  Potential owners of an activity are the people that can do the task the activity requires. Activity readers are people with the right to read the values of the activity. Activity editors are people with the right to manipulate the outcome of an activity.
• A person activity is claimed.
  This happens when one of the potential owners of an activity claims the activity to work on it. Then a work item for the activity owner is created.
• The claim of a person activity is cancelled.
  This happens when an activity owner decides to abort working on a previously claimed activity. Then the work item, which was created when the activity was claimed, is deleted.
• A receive event is activated.
  Then the following work items are created:
  • A work item for each potential owner of the activity. Potential owners are allowed to send the awaited event.
• An unhandled failure occurs in an activity of the process.
  Then the following work items are created:
  • A work item for the administrator of the process that allows a manual force restart or force complete of the activity.

When the process ends, the default behavior is that the process is deleted. Work items that were created for the process are also deleted.

A worklist is a query that is persistently stored in the database. Worklists can be used by the client of a process application for filtering work items according to predefined criteria. A worklist might, for example, query all purchase requisition activities of a certain process to find those that require confirmation. This worklist could then be used by a process-application client to present the resulting list of work items to a user who has the role "purchase requisition approver".

The queries are defined using SQL-like syntax. You can include constructs in the query to limit the query result, sort the result, restrict the number of objects returned, and specify differences in timezones. Only Process Choreographer administrators can create worklists.

The Process Choreographer API provides functions for handling worklists. The work-item manager is responsible for processing worklists. The work-item manager allows you to:

• Define a worklist and add it to the collection of worklists managed by the worklist manager
• Remove a worklist from the work-item manager
• Evaluate a worklist by executing the respective query

Administering business processes

Business process administration includes the administration of:

• The business process container
• Process modules
• Process templates

Other administration tasks are not covered in this paper.

A business process container is configured for every WebSphere application server that has Process Choreographer installed. Configuration of the business process container occurs when a new application server is created. During configuration, the associations between the business process container, its database, and the different message queues it requires are created. After the initial configuration step, an administrator can change the following settings of the business process container using the WebSphere administrative console:

• The number of retries for process messages which cannot be processed
• The maximum number of messages in the retention queue

Messages are stored in the retention queue if the business process container detects a temporary error condition, such as a database deadlock or a connection failure. As soon as the error condition is resolved, messages from the retention queue are fed back into normal processing.

The business process container contains process modules.

A process module contains a set of process templates. When an enterprise application is installed on an application server, a process module is created for each process archive (FAR) in the enterprise application repository (EAR). The process modules are then added to the business process container of the application server.

A process template is a deployed process model. Process templates support the following administration tasks:

• Start
• Stop
• Get state

Process templates can be started and stopped individually. If a process template is stopped, no new process instances of the corresponding process can be created. This means that an administrator can disable certain functions of a workflow application, for example, for maintenance reasons. Each process template has a state which is either started or stopped.

Back to top

Architecture

This section gives an overview of the internal structure of the business process engine. It takes a look at the various programming interfaces it makes available for client programs to access business-process services. In addition, it takes a closer look at each of the components, describing its function and its role in the overall system.

Programming Interfaces

Process Choreographer provides both general programming interfaces and process-specific programming interfaces. See the WebSphere Application Server InfoCenter for more information about these programming interfaces, including an introduction to programming against the process engine, code examples, and the complete JavaDoc for all the external interfaces.

General programming interfaces

The following process-engine functions are available as general programming interfaces:

• Start processes

  A new process instance can be started by specifying the name of the process template and the input data to be used for the new instance. In addition, you can associate the process instance with a user-defined ID. This ID can be used later as a secondary key to retrieve the process instance. You can also specify a callback that is invoked by the process engine when the process instance completes.

• Send asynchronous events to running processes

  For processes instances containing receive event activities, the associated events can be sent using the programming interfaces. The parameters that have to be passed include the system-generated or user-defined ID of the target process instance, the event name, and the event data.

• Query work assigned to a person

  This function can be used to retrieve work items, using either SQL-like queries, or predefined worklists.

• Work with activities assigned to a person

  This includes programming interfaces to claim an activity for which a person received a work item, and to complete claimed activity.

• Perform administrative tasks

  Programming interfaces are available to find out information about running process instances, to terminate a running instance, and to repair activities that have failed.

These general programming interfaces are made available in two forms:

• The complete set of functions as methods of the stateless session EJB that is provided by the business process container.

  This is the preferred method of interaction with the process engine from a client program, such as the supplied Web client.

• The functions for starting new process instances and sending events to running process instances are available via a message-driven bean (MDB). This MDB accepts JMS messages that pass the input or event data in the body of the message, and the additional information, such as the process template name or the event name, in their JMS properties.

  The process engine honors standard JMS properties, such as the specification of a reply queue. A reply to the start process message is sent upon completion of the process instance.

Process-specific programming interfaces (façades)

For each process model, you can use the WSAD-IE tools to generate an associated EJB (façade EJB) and an associated MDB (façade MDB) that provide strongly-typed interfaces for starting instances of the process and sending events to running instances. These façades simplify the coding of interactions with a specific process model.

Business-process components in WebSphere

The following figure shows the internal architecture of the WebSphere process engine, also known as the business process container.

The Navigator component is the heart of the process engine. It manages the state transitions for all process instances, and the state transitions for all activities in those process instances. The state diagrams for process instances and activity instances are shown in the following figures.

The normal life of a process instance begins with a start request. This creates the process instance and puts it into its running state. When all its contained activities have reached an end state, the process instance is marked finished. The process instance ceases to exist, either implicitly or via an explicit API call.

In exceptional cases, the process instance might encounter a fault that was not processed as part of the process logic. In this case, it waits for the completion of the active activities before putting the process into its failed state. Compensation is then invoked if it was defined for the process.

A process instance can also be terminated by a process administrator. In this case, after completion of the active activities, the process instance is put into its terminated state.

The activities of a process start their life in the inactive state when the enclosing process instance is created.

With the start of the process instance, all control connectors leaving its input node are activated. Their Boolean values are determined by evaluating their associated transition conditions, which result in a value of true or false for each control connector. Normal navigation then continues for all activities that are targetted by those control connectors.

Whenever an activity is reached via a control connector, the navigator checks whether this activity has more than one incoming control connector. Only when all the control connectors leading to the activity have been evaluated, will the navigator try to activate that activity. Otherwise, activation of the activity is deferred until all connectors have been evaluated and the activity remains in the inactive state.

When all control connectors have been evaluated, the activity's start condition is checked -- in Process Choreographer, this is always "at least one incoming control connector must be true" and cannot be changed. Depending on the evaluation of the start condition, one of the following happens:

• The activity's start condition evaluates to false. The activity is marked skipped. This means that the activity is not executed, and the process continues navigation. The Boolean values of the control connectors leaving the activity are set to false without evaluating the transition conditions. This processing is called dead-path elimination.
• The activity's start condition evaluates to true, and it is a person activity. In this case, work items are created and the activity is put into the ready state. In this state, an activity can be claimed by a user, which puts the activity into the claimed state while the user is working on it.
• The activity's start condition evaluates to true, and it is an elemental activity implemented by a service. In this case, the activity is put into the running state for the duration of the invocation.
• The activity's start condition evaluates to true, and it is a receive event activity. In this case, the activity is put into the waiting state (not shown in the figure) until an event is received.

When the assigned person of the person activity, or the implementation of the elemental activity, completes the activity and produces a result, the activity is put into its finished state. This also happens for a receive event activity when an awaited event is received. The control logic of the process continues with the evaluation of the transition conditions of the control connectors that originate in the activity.

Eventually, the activity is deleted as part of the deletion of the process.

There are a number of additional states for exceptional processing of activities:

• The failed state is reached when a fault is thrown by an activity which is not handled in the process, and the continue-on-error flag is set for the activity.
• The stopped state is reached when a fault is thrown by an activity which is not handled in the process, and the continue-on-error flag is not set for the activity. This effectively results in "stop-on-error" semantics, which is the default.
  From the stopped state, the activity can either be retried or completed. This results in a transition to the ready, running, finished, or failed state, depending on the request and the type of activity.
• The terminated state is reached if an activity was active when the enclosing process instance was terminated.
• Finally, the expired state is reached if an activity timed out.

Plug-ins

The Navigator delegates some of the tasks it has to perform to plug-ins. These plug-ins decouple the Navigator from components it needs to use and allow IBM to easily extend the capabilities of the process engine in the future.

Plug-ins are provided for:

• The invocation of activity implementations. The process engine has two plug-ins for this, one for the invocation of (external) services via the Web Services Invocation Framework (WSIF), and one for the invocation of Java snippets.
• The handling of data in the process, such as evaluating conditions. The process engine has a plug-in that understands conditions written in Java against WSDL messages.
• The logging of "interesting" events in an audit trail. The process engine has a plug-in that writes data to the audit trail table of the process engine's database.
• The resolution of staff queries against an external directory. The process engine has a number of plug-ins that allow it to work together with external directories, such as the WebSphere Application Server user registry, or an LDAP directory.

Work item management (WIM)

The WIM component is responsible for:

• The creation and deletion of work items in the process engine's database.
• The resolution of work-item queries from process participants against this database.
• The resolution of staff queries against the people directory that is used in with the process engine. To support different types of directories, the interaction with the directory is through the staff resolution plug-in.
• The instance-based authorization based on the work items created for users. Users are authorized to perform actions against an activity or process only if they have received an appropriate work item to do so. For example, process participants can claim an activity only if they have a "potential owner" work item for that activity.

Factory

The Factory component is responsible for the management of the "physical" state information the process engine deals with.

It allows data to be stored in one of the following forms:

• Transiently in memory, as required by non-interruptible processes for efficient execution
• Persistently in a database, as required by interruptible processes for durability

The supported databases include DB2, Oracle, Sybase, and Cloudscape.

Other components

The process engine includes a tracing and logging component that is responsible for the production of diagnosis information.

A façade-session EJB and a façade MDB provide the synchronous and asynchronous renderings of the external interfaces.

The process engine uses its internal queue to send JMS messages to itself to process stratified transactions that are needed for interruptible processes. This queue is a JMS queue that allows the persistent queuing of messages.

Resources

• F. Leymann, D. Roller, M.-T. Schmidt. Web services and business process management. IBM Systems Journal Vol 41, No 2, 2002.
  
  
• F. Leymann, D. Roller. Workflow-based applications. IBM Systems Journal Vol 36, No 1, 1997.
  
  
• Paul Fremantle. Applying the Web services invocation framework: Calling services independent of protocols. June 2002.
  
  
• Nirmal K. Mukhi. Web service invocation sans SOAP: How WSIF scores over the current client programming models for Web services. September 2001.
  
  
• Nirmal K. Mukhi, Aleksander Slominski. Web service invocation sans SOAP, Part 2: The architecture of Web Service Invocation Framework . September 2001.
  
  
• Chandra Venkatapathy, Simon Holdsworth. An introduction to Web Services Gateway: A proxy for Web services . May 2002.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Preface
• Business processes in today's business environment
• Business process concepts
• Developing, using, and administering business processes
• Architecture
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers