Business-to-Business Architecture Global information management strategies based on a sound distributed architecture are the foundation for effective distribution of complex applications that are needed to support ever changing operational conditions across security boundaries. We present the fully distributed architecture for implementing a Workflow Management System (WFMS). A workflow distributed database consists of a set N of sites, where each site N ∈ N is an MLS database. The sites in the workflow system are interconnected via communication links over which they can communicate. The WFMS architecture operates on top of a Common Object Request Broker Architecture (CORBA) implementation. A CORBA’s Interface Definition Language (IDL) is used to provide a means of specifying workflows. Also we assume that communication links are secure — possibly using encryption. This distributed workflow transaction processing model describes mainly those components necessary for the distribution of a transaction on different domains. Domain is a unit of autonomy that owns a collection of flow procedures and their instances. If a transaction should be dstributed on several domains — a global transaction, in every domain there must exist the following components, (see Fig.4). • TM – Transaction–Manager. The transaction manager plays the role of the coordinator in the respective domain. If a transaction is initiated in this do main, the TM assigns a globally unique identifier for it. The TM monitors all actions from applications and resource managers in its domain. In every domain involved in the distributed workflow transaction environment there exists exactly one TM. • CRM – Communication–Resource–Manager. Multiple applications in the same domain talk with each other via the CRM. This module is used by applications but also other management components for inter-domain communication. CRM is the most important module with respect to the transactional support for distributed workflow executions. Our model specifies the T*RPC as a communication model, which supports a remote procedure call (RPC) in the transactional environment. • RM – Resource–Manager. An accountable performer of work. A resource can be a person, a computer process, or machine that plays a role in the workflow system. This module controls the access to one or more resources like files, printers or databases. The RM is responsible for the ACID properties on its data records. A resource has a name and various attributes defining its characteristics. Typical examples of these attributes are job code, skill set, organization unit, and availability. • AMS – Administration–Monitoring–Service. The monitoring manager is used to control the workflow execution. In our approach, there is no centralized scheduler. In the figue, each Task Manager – designated as TSM, is equipped with a conditional fragment of code which determines if and when a given task is due to start execution. The scheduler communicates with task managers using CORBA’s asynchro- nous Interface Definition Language(IDL) interfaces. Task managers communicate with tasks using synchronous IDL interfaces as well. AMS module is also responsible for the coordination of the different sites in case of an abort that involves multiple sites. Individual task managers communicate to monitoring manager their internal states, as well as data object references – for possible recovery. The distributed architecture suits the inherent distributional character of workflow adequately in a natural way. This approach also eliminates the bottleneck of task managers having to communicate with a remote centralized scheduler during the execution of the workflow. This architecture also posseses high resiliency to failures — if any one node crashes, only a part of the workflow is affected.
Recent Comments