IBM WebSphere Application Server Enterprise Process Choreographer is a business-process engine that allows for the efficient execution of business processes. It supports both short-running and long-running business processes.
Short-running business processes, also called microflows, are non-interruptible and usually fully-automated. In contrast, long-running processes, also called macroflows, are interruptible and can involve human interaction. People get involved in business processes, for example, to start them, handle manual steps, and deal with exceptional situations.
This article describes the architecture of the components involved in staff resolution. It explains the interaction between the Web client, business process engine, work item manager, staff resolution plug-ins, and staff repositories. It then focuses on the role of staff resolution. The article assumes that you are already familiar with Process Choreographer concepts and general architecture as described in the WebSphere Application Server Enterprise Process Choreographer - Concepts and Architecture white paper.
Overview of Process Choreographer architecture
Figure 1 shows an overview of the Process Choreographer architecture. Process Choreographer provides a Web client user interface for human interaction. Here, users can act on a set of worklists containing their work items. Each work item represents a process instance, an activity, or an event, on which the user is allowed to perform certain actions. The process of deciding which user is allowed to perform specific actions on a certain work item, is called staff resolution.
Figure 1. Process Choreographer architecture
The user uses the Web client to work with business process, for example, to start business processes, claim work items, and fill out forms. The Web client routes all these actions via the API to the business process engine, which is responsible for navigating through the business processes, and for keeping track of the state of the process and its activities.
The engine does not perform every step itself; it delegates many actions to the various plug-ins. Plug-ins allow the engine to delegate steps that require specific knowledge of a certain external component. Plug-ins get involved with data handling, activity invocation, and staff resolution. This article focuses on the staff resolution architecture with its associated staff resolution plug-ins.
Staff resolution components get involved in process execution:
- At process deployment, to create an optimized form of the staff query.
- When the engine creates a work item during the invocation of a process instance, the scheduling of new activities, or the triggering of events.
Process Choreographer supports business processes with human interaction only when security is enabled in WebSphere Application Server. This allows authentication to take place and work items for a specific user to be determined.
Figure 2 shows the main components involved in staff resolution. These are the Web client, the process engine, the work item manager, the staff support service, the staff resolution plug-ins, and the staff repositories.
Figure 2. Process Choreographer staff resolution architecture
The Web client is based on Java Server Pages (JSP) technology. It provides users a set of worklists containing work items, on which they can perform queries, view further details, or perform certain actions. It also allows the inclusion of user-defined JSPs that support staff activities with complex data or interaction scenarios. The Web client interacts with the process engine via the API. It does not interact directly with the other components that support human interaction.
The process engine is the main component of Process Choreographer. It manages the state transitions for the process instances and for the activities in these process instances. It also manages the state of the various objects that represent business processes. It allows data to be stored either transiently in memory as required by non-interruptible processes for efficient execution, or persistently in a database as required by interruptible processes for durability. The engine also manages the various plug-ins; it invokes them whenever it needs to delegate a task.
The work item manager (WIM) is a component of the process engine that manages work items. It is responsible for:
- Creating and deleting work items in the database.
- Resolving work item queries against the database from potential process participants.
- Invoking staff query resolution, which is performed by the staff support service and the staff resolution plug-ins.
-
Enforcing the 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 a corresponding work item. For example, process participants can claim an activity only if they have a work item of type "potential owner" for that activity.
Note that authorization can be specific to a process instance rather than being specific to a process template, because the authorization to perform a certain activity can depend on the context of the process instance, for example, when the manager of the process starter gets assigned to an activity.
The work item manager uses an internal cache for resolved staff queries. The query results in the cache have a user-defined expiration time. Thus, if a staff query result from an identical query template exists in the cache, the cached result is used. Because the staff repository is not involved, this allows for better performance. However, if an instance of the same process template is created after the associated cached query result has expired, the staff repository gets involved again. This allows for almost up-to-date query results, so that changes in the staff repository are reflected in the staff resolution in a timely manner.
The staff support service is a master plug-in that manages the life cycle of the specialized staff resolution plug-ins, transforms the staff query verbs into plug-in specific queries, and delegates deployment and staff resolution requests to these specialized plug-ins. Staff query verbs are abstract staff queries that can be used at modeling time to define the people who will have access to a specific Process Choreographer work item. At deployment time these verbs are transformed into staff resolution plug-in-specific queries. The staff support service is described in more detail in Staff support service.
The specialized staff resolution plug-ins are bound to a specific staff repository, such as the User Registry or a Lightweight Directory Access Protocol (LDAP) directory. The staff resolution plug-ins are responsible for retrieving staff information from the external staff repositories, for example, an LDAP directory. They are responsible for the deployment and the execution of the staff query, and perform these queries by invoking a set of API calls against their repository. The staff resolution plug-ins are described in more detail in Staff resolution plug-ins.
The staff repositories, such as LDAP directories or the repositories behind the User Registry, are not part of Process Choreographer. They get accessed in read-only mode by the staff resolution plug-ins. They do not have to be modified for use by Process Choreographer.
Staff resolution and business processes
The staff resolution components are in involved in the business process context when:
- A process model gets deployed, the appropriate specialized plug-in configuration is determined, and the staff query verb is transformed and deployed.
- The WIM resolves a query, the appropriate plug-in is called to execute the query by invoking the staff repository API.
Staff resolution and process deployment
Figure 3 illustrates the deployment scenario:
Figure 3. Staff resolution and process deployment
When a process model is deployed, the process engine invokes the staff support service to deploy the staff verbs. The staff support service:
- Determines which of the specialized staff resolution plug-ins is responsible for the queries of this process.
- Determines the appropriate plug-in configuration using the Java Naming and Directory Interface (JNDI) name specified in the process model.
- Translates the verb into the plug-in specific query syntax using the XSLT (Extensible Stylesheet Language Transformations) mapping file specified in the configuration.
- Invokes the plug-in with the transformed query.
The plug-in deploys the query by checking it for errors and transforming it into an optimized object that can be stored in the database. The deployed query is returned to the engine, and stored in the database. It is now ready to be used by the WIM at staff resolution time.
Staff resolution and query execution
Figure 4 illustrates the staff resolution scenario that occurs when the work item manager resolves a query for activity potential owners, process administrators, potential process starters, readers, editors, or event activity potential owners.
Figure 4. Staff resolution and query execution
Because the query resolution is identical for all these roles, the resolution of the activity potential owner described here applies to all the other roles.
- The work item manager invokes the staff support service to resolve the owners of a work item.
- The staff support service forwards the request to the appropriate specialized plug-in, which was determined at deployment time.
- The plug-in invokes the staff repository APIs one or more times, and constructs the list of authorized user IDs from the query results.
- The staff support service returns this list to the WIM.
- The WIM creates the work items corresponding to the returned list. This step does not occur for potential process starters.
The staff support service provides an abstraction layer for the resolution of staff member information. It allows you to use verbs to define generic staff queries without binding the query to a particular staff repository. The staff repository is accessed using the specialized staff resolution plug-ins.
When you model a business process, you can use verbs to define a parameterized staff query to specify the staff members associated with a particular activity. IBM WebSphere Studio Application Developer Integration Edition does not need to know about the specialized staff resolution plug-in implementation of the staff query. The staff support service translates the parameterized staff query generated by Studio Application Developer to a specialized staff resolution plug-in specific query. This transformation is done when the business process is deployed.
The staff support service provides a default set of staff query verbs that can be used for standard staff queries. You can extend the set of verbs to define verbs which are more complex and more closely match your needs. To customize the verb set, you must define the new verb in the XML verb-set and its corresponding mapping template in the XSLT (Extensible Stylesheet Language Transformation) file. The stylesheet requires a template to take the new incoming parameterized XML verb and transform it into the language supported by the specialized staff resolution plug-in. This new transformation file is used at deployment time to transform the query.
Figure 5 shows an example of a parameterized staff verb that might be generated by Studio Application Developer.
|
Figure 5. Example of a parameterized verb
A staff plug-in provider is supplied for each of the specialized staff resolution plug-ins. The provider contains a set of properties for the specialized plug-in. Some of these properties, such as LDAP server settings, might need to be defined before the plug-in can be used. A staff plug-in provider can have multiple configurations. Each configuration has its own set of configuration properties that can be set by the WebSphere Application Server administrator. These property values must be set in the staff resolution plug-in before it is called during deployment or query resolution. Each configuration also has its own JNDI name used by the staff support service to locate it, and a reference to an XSLT transformation file to be used for the transformation of the parameterized staff query.
To conform to the plug-in architecture available for various domains, Process Choreographer delegates staff resolution to plug-ins. This means that various types of enterprise directories can be supported. The plug-ins are responsible for retrieving the staff information from the external staff repository, for example, an LDAP directory.
When the process model is deployed, the plug-ins are invoked to verify the staff query syntax resulting from the verb transformation step performed by the staff support service, and to produce an optimized form of this query that can be executed quickly at run time. The resulting deployed staff query is stored in the Process Choreographer database and is available for the WIM at run time.
At run time, the plug-ins are invoked by the deployed query and a list of resolved context variables. They perform the staff resolution by querying the back-end staff repository's APIs, according to the instructions stored in the deployed staff query, and return a list of user IDs (caller principal names). The WIM uses this list to create work items.
The supported query syntax varies from simple static user assignments to complicated constructions including intermediate results. Some examples of the query syntax are:
Simple static query:
Context sensitive static query:
Search query (User Registry):
Complex query (LDAP):
|
Figure 6. Examples of the query syntax
Several staff queries support context variables. This allows context-sensitive queries so that even static queries have dynamic behavior. Context variables are encapsulated in "%" signs and have the following notation: %parameter name%, for example, %wf:process.starter%.
The staff plug-ins can be considered to be stateless; only their configuration information is kept in memory. Because every request is handled in a separate thread, this allows for better scalability.
The plug-ins are tailored to particular directories such as the User Registry and LDAP. It is possible to instantiate multiple plug-ins of the same type, independent of whether they have the same configuration. Figure 7 shows the supported staff resolution plug-ins and staff repositories:
Figure 7. Supported staff resolution plug-ins and staff repositories
The default and entry level configuration that can be used "out-of-the-box" is the User Registry plug-in with the Local OS User Registry. However, this configuration does not offer the powerful functionality provided by the LDAP plug-in with an LDAP directory. This is the recommended solution for production environments.
The following sections describe the plug-ins delivered with Process Choreographer.
User Registry staff resolution plug-in
The User Registry staff resolution plug-in allows you to refer to users and groups that are known to the WebSphere Application Server. It performs its queries against the User Registry API. Because the User Registry is available whenever WebSphere Application Server security is enabled, and the plug-in does not require any configuration parameters, this plug-in can be used "out-of-the-box".
The plug-in supports static staff assignments and context variables. It also allows user ID validation, retrieval of group members, searches for users, and searches for groups whose users will get a work item assigned.
The User Registry plug-in supports the retrieval of staff information from various types of staff repositories that are supported by the User Registry:
-
The user and group administration of the operating system on the machine where WebSphere Application Server is installed can be used as a staff repository.
Note that if both a domain controller and the local machine are used for security and the same group exists in both places, the LocalOS User Registry on Windows returns users from both the domain and the local machine. You can avoid this by fully-qualifying the group name, for example, "mymachine\mygroup".
-
Any LDAP directory server supported by WebSphere Application Server can be accessed. However, the query functionality is inferior to the one offered via the LDAP plug-in that accesses the LDAP server directly.
-
Any custom repository that implements the User Registry Service Provider Interface (SPI) can be used as a staff repository by Process Choreographer. See the User Registry documentation for further details.
Note that the deprecated
getUsersForGroup()method of the UserRegistry interface must be implemented for custom registries to be supported by the User Registry staff resolution plug-in.
The LDAP staff resolution plug-in provides access to organizational information that is stored in LDAP directories. It uses the JNDI to access the LDAP directory server. You can configure multiple LDAP plug-ins, with each one accessing a different LDAP directory server. Also, many configurations connecting to the same LDAP server can improve the total staff query performance.
You can use the plug-in to query user attributes, evaluate members of LDAP groups, perform searches based on the LDAP filter syntax, or to perform queries with intermediate results that allow, for example, the retrieval of the user ID of the manager of a person. It also supports static staff assignments and context variables.
LDAP staff queries are not restricted to directories that are known to the WebSphere Application Server and that are used for WebSphere authentication. However, the user IDs managed in the LDAP directory must match those (caller principal name) used by WebSphere.
The LDAP staff resolution plug-in requires several deployment parameters that are managed via the staff support service administration user interface. Most configuration parameters are needed to set up the JNDI connection, the others set some query default values.
System staff resolution plug-in
The system staff resolution plug-in supports static staff assignments and context variables. It has no back-end repository to query against, and is thus not enabled for production environments. However, because it does not have a repository, there is no staff directory to configure. This is useful for testing scenarios with staff support.
- Matthias Kloppmann, Gerhard Pfau. WebSphere Application Server Enterprise Process Choreographer -
Concepts and Architecture. December 2002.
- Günther Jornitz, Matthias Kloppmann, Gerhard Pfau, Stefan Rüttinger. WebSphere
Platform Programming Model - Business Process Choreography. To be published.
- Kurt Lind, Eric Van Norman. WebSphere
Platform Programming Model - Staff Support Service. To be published.
- Kurt Lind. WebSphere Application Server Enterprise Process Choreographer -
Staff Resolution Parameter Reference. March 2003.
- WebSphere Studio Application Developer Integration Edition 5.0 online help
Comments (Undergoing maintenance)





