Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1

Ratings: (0)|Views: 1 |Likes:
Published by Shashank Gosavi

More info:

Categories:Types, School Work
Published by: Shashank Gosavi on May 14, 2013
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





A Client/Server Architecture for DistributedWorkflow Management Systems
 Hans Schuster,
Stefan Jablonski,
Thomas Kirsche,
Christoph Bussler 
A specific task of distributed and parallel Information Systems is workflow management. In particular, work-flow management systems execute business processes that run on top of distributed and parallel InformationSystems. Parallelism is due to performance requirements and involves data and applications that are spreadacross a heterogeneous, distributed computing environment. Heterogeneity and distribution of the underlyingcomputing infrastructure should be made transparent in order to alleviate programming and use. We introducean implementation architecture for workflow management systems that meets best these requirements. Scal-ability (through transparent parallelism) and transparency with respect to distribution and heterogeneity arethe major characteristics of this architecture. A generic client/server class library in an object-oriented envi-ronment demonstrates the feasibility of the approach taken.
In the area of business process reengineering, technologies for the execution of business pro-cesses are needed that can flexibly and dynamically be adjusted to the rapidly changing structureof business processes. Due to their distributed and parallel nature they are enacted by distributedand parallel Information Systems.
Workflow management 
(WFM) promises to be a proper plat-form for the execution of business processes, i.e. WFM represents a new technology for theenactment of business processes in distributed and parallel Information Systems. WFM is aimedat the automation of business processes. We call the executable image of a business process
. According to [McBl91]
workflow management systems
(WFMS) are characterized as
“proactive computer systems which manage flow of work among participants, according to a defined proce-dure consisting of a number of tasks. They coordinate users and systems participants, together with theappropriate data resources [...]. The coordination involves passing tasks from participant to participant incorrect sequence, ensuring that all fulfil their required contributions [...].”
Some typical elements of workflows are described in this citation. The example depicted inFigure 1 gives an idea of how the aspects show up in workflow specifications. From the
 func-tional viewpoint 
, the workflows being executed are “Travel Claim Processing”, “Submit Travel
University of Erlangen, Dept. of Computer Sciences VI (Database Systems), Martensstraße 3, D–91058 Erlangen
 Digital Equipment GmbH, Application Integration Technology Group, CEC Karlsruhe, Vincenz-Priessnitz-Straße 1, D–76131 Karlsruhe
Claim”, “Approve Travel Claim”, and “Reimburse Client”. The latter three are refinements of the overall travel claim process. Nesting workflows within the workflow “Travel Claim Proces-sing” means that they implement the composite workflow. The ordering between workflows isspecified by arrows indicating a
behavioral aspect 
, the persons who shouldexecute the workflows are attached to the workflows (e.g. client, manager). Data elements beingpassed between workflows are travel claim (TC) data in this example. Thus, the TCs form the
informational perspective
. Both workflows “Submit Travel Claim” and “Approve Travel Claim”point to the application “Travel Claim System”; the workflow “Reimburse Client” points to theapplication “Finance Booking System”. When executing one of these workflows, the applicationpointed to is called. Obviously, all workflows can be arbitrarily distributed. Section 2 providesa more detailed discussion of the aspects briefly explained here.
Figure 1: Travel Claim Processing
Travel Claim Processing
Submit Travel Claim Approve Travel Claim Reimburse ClientClientManager (Client)Fin. Clerk (Group(Manager))TC TCTravelClaimSystemFinanceBookingSystemClient
WFM comprises of many different tasks which are orchestrated by the (kernel of the) WFMS([BuJa93]): workflows ready for execution have to be determined using control flow structures;human or non-human agents have to be selected for executing the workflows; data needed forworkflow execution must be provided; finally, applications – including legacy applications – arecalled to perform a function.Workflows are executed in complex enterprises. Therefore, WFMSs are characterized by thefollowing infrastructural requirements and facts:
WFMSs are large scale systems. They have to handle huge numbers of workflowtypes, instances, users, departments, etc.
According to the distribution of an enterprise a WFMS is a distributed applicationby itself.
The hard- and software infrastructure of an enterprise will be heterogeneous; how-ever, a WFMS must cover up this heterogeneity.
WFMSs have to integrate newly written and legacy applications.
WFMSs are active systems. They drive the execution of workflows by notifyingagents about outstanding tasks.
WFMSs are a basis for collaborative work. They coordinate cooperating agentsduring the execution of workflows.
These characteristics have to be considered in the architecture of a WFMS. It will turn out thatthe main architectural issues of WFMS are
with respect to hard- and softwareheterogeneity, hard- and software distribution, varying size of the system, and different servicessupported. A client/server architecture is very suitable for achieving this goal. In this paper, wedetail the client/server architecture of a WFMS.
2Workflow Modeling in Workflow Management Systems
Although the architecture of WFMSs is the main topic in this paper, we have to introduce aworkflow model first in order to know what workflows look like. The architecture of WFMSsshows
a workflow is executed, while a workflow model shows
has to be performed.A distinguished architecture must use an orthogonal and modular workflow model to be orthogo-nal and modular by itself. The following discussion of the ramifications of our workflow modelABS (
 Activity Behavior Specification
) gives an introduction in what has to be enacted by aWFMS. Details about the workflow model of ABS can be found in [BuJa94].
2.1Functional Perspective
Workflows are described by an object-oriented model. Therefore, workflows are object typesand their fundamental features are represented by data variables and methods. Workflows repre-sent a functional unit (cf. Figure 1). They are either elementary or composite; composite work-flows reference further workflows (called subworkflows) so that nesting of workflows occurs.Elementary workflows invoke applications which are separately modeled as object types. Ap-plications represent an executable image, like a program or a server routine. Workflows arespecified in a modular way such that they can be reused in different contexts i.e. by differentworkflows. A workflow is called by its name along with a predefined set of values for the inter-face variables. Inside of a workflow, only variables local to that workflow can be referenced(scoping rule). Local policy variables may be needed to specify notification and policies (seeSection 2.3). The most important method of a workflow is
. Usually, the interface pa-rameters of a workflow describe the calling parameters for this function.
2.2Behavioral Perspective
For composite workflows the execution sequence of their subworkflows is determined by depen-dencies between the subworkflows This defines the control flow among subworkflows. Twomajor types of control flow are distinguished ([Jabl93]).
Prescriptive types
of control flow are
, and
 parallel execution
. They bear the usual semantics. We use the followingnotation, whereby it is assumed that a superworkflow A comprises of two subworkflows B andC. Descriptive control flow among B and C is expressed by the following constructs:
(B; C) /* serial execution*/ 
(cond(); B; C)/* alternative execution*

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->