1

10

11

The following slides presents a highly distributed topology when ALBPM is deployed in a J2EE Application Server like WebLogic or WebSphere. The following is a map of how the WorkSpace (or any other client application using PAPI) and Process Execution Engine(s) can be deployed. The following map displayes the different protocols used to connect each one of the ALBPM runtime components that are involved in orchestrating human and system centric activities. This diagram shows a single J2EE Cluster where the ALBPM WorkSpace Web Application is deployed. It would be also possible to have other Clusters where the ALBPM WorkSpace is deployed. Multiple Clusters hosting the WorkSpace Web Application would make sense when connecting geographically dispersed human communities. It is important to provide high availability to this front end layer since it is the layer that connects persons to process their work based on what roles have been assigned to them within the Organization. This is the layer to scale with a large concurrent user base. As more users connect to the system, more WorkSpace nodes will need to be added to the cluster. The scalability strategy in this case, is to continue to add more WorkSpace nodes or eventually create a new cluster with more nodes to host the WorkSpace Web Application. 12

This diagram will explain the effect of processing an interactive activity in the displayed highly available architecture. 1. A request comes from the end user requesting the completion of an interactive activity. This will trigger the WorkSpace Web Application to invoke certain servlets to process the end user requested action. 2. The WorkSpace Servlet layer uses PAPI to request the execution of a given operation to the Engine. In this case, as the deployment of the Engine is in a J2EE Container, the end point of the PAPI Request is a call into a Stateless EJB. In the event that there are not enough threads for this Stateless EJB, the request will get enqueued until a thread becomes available. 3. When the Stateless EJB is able to start processing the request, it will start an XA transaction with the backend Engine RDBMS to persist the latest and eventually modified instance state into the Engine DB. 4. Once this transaction has been completed, the Engine will execute the routing action and will determine which is the next activity the instance should be moved to. The result of this is a message into the Engine News JMS Topic indicating that the instance is leaving a given interactive activity. In the Event that the next activity that the instance is going to is an Interactive one, a special message indicating IN/OUT will be posted into the Engine News JMS Topic.

13

This diagram illustrates the execution of an Automatic activity in the overall distributed architecture presented above. 1. When an automatic action needs to be executed by the Engine, a JMS Message is pushed into the Engine ToDo JMS Queue. This message is then picked up by an associated Message Driven Bean that in this diagram is identified by the label Dispatcher MDB that will start the processing of the requested operation. There are different ways in which a message may get into this activity and it is usually associated to any of the following actions: The execution of a previous activity routed the instance to an automatic activity. In this case, the Engine routing action will push a message into this Queue. The Engine has an Internal Scheduler Servlet that checks for the expiration of Due operations (Due Transitions, Activity Expirations, Process Expirations). When this Servlet detects there is one of these items expired, it will push a message into this Queue to dispatch the execution of the required action.

2. When the message is picked up by the Dispatcher MDB, it will start an XA transaction involving the retrieval of the message from the queue and the start of a transactions with the Engine RDBMS. This first thing to do with the Engine RDBMS transaction is to check whether the request is still valid

14

15

16