ArticlePDF Available

SWAP: Leveraging the Web to manage workflow

Authors:

Abstract

Many organizations are beginning to discover what workflow vendors already know-namely, that the real value of the Web lies not just in its documents and resources, but also in the activities surrounding them. Collaborative work involves not only handoff and routing of data between humans, but the coordination of activities among them and with automated agents as well. Workflow engines typically ensure that the information ends up on the right desktop along with the tools to accomplish a slated task. It is difficult to synchronize work and activity tracking within a technically diverse organization. Tools and formats typically differ among workgroups, as do skill levels and understanding among individual participants in a process. Browser-based user interfaces offer a mechanism to easily access distributed information and hand off documents and data over the Web, but at the expense of being able to effectively manage and track work activities. Web protocols provide no inherent support for automated change notification, handoff of control, or initiation of human- and computer-executed activities. In essence, there is no standard way for service requests to trigger a workflow process and monitor it across platforms and between organizations
85
IEEE INTERNET COMPUTING
http://computer.org/internet/
JANUARY • FEBRUARY 1999
The Web’s explosive growth has made
it the platform of choice for Internet
application developers. Workflow
vendors are no exception to this
trend. They are employing Web infra-
structure and protocols in traditional
workflow products to give customers
worldwide connectivity for sharing
information both inside and outside
an organization.
Many organizations are beginning
to discover what workflow vendors
already know—namely, that the real
value of the Web lies not just in its
documents and resources, but also in
the activities surrounding them.
Collaborative work involves not only
handoff and routing of data between
humans, but the coordination of
activities among them and with auto-
mated agents as well. Workflow
engines typically ensure that the
information ends up on the right
desktop along with the tools to
accomplish a slated task.
It is difficult to synchronize work
and activity tracking within a techni-
cally diverse organization. Tools and
formats typically differ among work-
groups, as do skill levels and under-
standing among individual partici-
pants in a process. Browser-based user
interfaces offer a mechanism to easily
access distributed information and
hand off documents and data over the
Web, but at the expense of being able
to effectively manage and track work
activities. Web protocols provide no
inherent support for automated
change notification, handoff of con-
trol, or initiation of human- and
computer-executed activities. In
essence, there is no standard way for
service requests to trigger a workflow
process and monitor it across plat-
forms and between organizations.
A Network-Based Protocol
Solution
An Internet Engineering Task Force
working group has been proposed to
define a simple, lightweight, extensible
protocol for communicating informa-
tion about long-lived workflow activi-
ties over the Internet (see the sidebar,
“Related Workflow Standards,” for
links to this group, its work, and other
relevant Web sites). The ability to
integrate work providers and work
performers to support asynchronous
services across an intranet, extranet, or
the Internet is a powerful mechanism.
It allows the use of software from mul-
tiple vendors to build scalable work-
flow automation solutions. To this
end, more than 30 commercial ven-
dors and research labs have con-
tributed to the IETF effort.
The work to date has been toward
defining the Simple Workflow Access
Protocol. SWAP is being designed to
allow for interoperability between dif-
ferent workflow systems and the
applications they support. Standard-
izing a protocol rather than defining a
standard software library or API mini-
mizes the implementation constraints
on a vendor’s workflow system. The
workflow implementor must define
only the structure of the calls and data
placed on the wire. Interoperability
overhead is minimized and grounded
in a network-based protocol specifica-
tion rather than the migration of
process definitions from one system
to another according to intersite
agreements or common data format
definitions.
To keep it simple, the scope of
SWAP is limited to the interactions
and requirements between a requester
and a workflow service. This approach
leverages existing Internet protocol
designs and avoids the harder problem
of prescribing a general interoperabili-
ty workflow definition or interchange
format.
For its purposes, the working
group defines a workflow process as a
series of steps that involves coordina-
tion of tasks, handoff or routing of
information, and synchronization of
activities. While a user can easily pub-
lish a Web page to disseminate infor-
mation, it is very difficult to browse
or publish access to a generic work-
flow service.
Current practice is through
Common Gateway Interface scripting,
whereby a server maps an HTTP
method call to execution code resident
on the receiving server. Because the
code is usually programmed and sup-
ported in a way particular to the host-
ing organization, companies have hesi-
tated to commit their core business
processes outside their ability to con-
trol them. The code representing the
enactable workflow process tends to
evolve, which can cause unexpected
errors and exceptions and invocation
mismatches. This makes maintaining
interorganizational processes costly.
COLLABORATIVE WORK
SWAP:
Leveraging the Web To
Manage Workflow
Gregory Alan Bolcer • Endeavors Technology Inc., and
University of California, Irvine • gbolcer@endeavors.org
Gail Kaiser • Columbia University • kaiser@cs.columbia.edu
.
SWAP would solve these problems
by using HTTP and WebDAV pro-
tocol extensions and transferring
structured information encoded in
XML.
Resource and Execution
Model
SWAP is a work in progress, and defi-
nitions have yet to be formally
reviewed and commented on.
However, after several Birds-of-a-
Feather meetings, a consensus is
emerging on some design approaches
and definitions. The SWAP Internet
draft,1which expires in February
COLUMN
86
JANUARY • FEBRUARY 1999
http://computer.org/internet/
IEEE INTERNET COMPUTING
The Web site for the Simple Workflow Access Protocol
working group is at http://www.ics.uci.edu/~ietfswap/.
The site includes more information about SWAP as well as
links to current IETF Internet-draft documents at
http://www.ietf.org/internet-drafts/. It also defines work-
flow as “the computerized facilitation or automation of a
business process, in whole or part.”
Other Workflow Standards
SWAP has overlapping concerns with many other stan-
dards efforts in the workflow and Web communities. Both
the Workflow Management Coalition (WfMC) and the
Object Management Group (OMG) have proposed work-
flow standards1,2 that are much more mature than SWAP.
The Web sites for these organizations are
http://www.aiim.org/wfmc/ and http://www.omg.org,
respectively.
SWAP differs from these efforts in its focus on using HTTP
as a substrate. This creates both an opportunity and a
problem.
The opportunity, of course, is the prospect of capitaliz-
ing on HTTP’s wide support, particularly on desktops and
Internet-enabled devices that don’t easily support tradi-
tional workflow installations. The problem is that HTTP
doesn’t currently offer the level of notification and transac-
tion control required for cooperative work on the Web.3
The WfMC and OMG workflow standards require very
sophisticated technologies to support distributed workflow
execution and participation. Efforts to embrace and inte-
grate the Web into these standards have proved difficult.
The Web’s minimalist infrastructure doesn’t easily support
flexibility, consistency, and assurances of a more robust
traditional workflow solution.
Other Related Standards
What this specifically means to the SWAP working group
is that protocol and data type definitions will be borrowed
from other standards and working groups. SWAP intends
to address these particular requirements by leveraging
work done to date on HTTP and WebDAV. WebDAV has
been a largely successful HTTP extension that provides a
clean interface for assigning and retrieving properties on a
resource. The home page for WebDAV is
http://www.ietf.org/html.charters/webdav-charter.html.
The Internet printing protocol (IPP) shares several con-
cerns regarding asynchronous job processing (see
http://www.ietf.org/html.charters/ipp-charter.html).
The many notification protocols, such as the
Generalized Event Notification Architecture, provide
guidance to the issues and drawbacks of doing publish-
subscribe and remote procedure notification on the
Internet; and various XML standardization groups provide
DTDs for certain types of domain-specific definitions and
common business processes.
While all these issues are under consideration by the
working group, the SWAP participants have determined
that in the interest of time-to-market, external dependencies
will be kept to a minimum. Formal incorporation of other
standards work will be limited, but care will be taken to
ensure future compatibility.
Why SWAP?
SWAP is related to several other protocol standardization
efforts, including Remote Procedure Calls using XML
encoding (XML/RPC) and HTTP and its extensions
(HTTP/1.1, HTTP-NG). HTTP has been useful for many
purposes because it doesn’t require programmers to build
different protocol engines to support highly related tasks.
For protocols that aren’t supported, the Protocol Extension
Protocol allows extension of HTTP functionality.
Because SWAP involves generic services, several work-
ing group members have asked what is workflow-specific
about the protocol. The definition of the SWAP workflow
protocol is useful in several ways. First, workflow has a
unique requirement in that a generic workflow service,
once invoked, can take anywhere from minutes to years to
complete. How will the service change over this time?
What will be the availability? How do updates and notifi-
cations take place? It is not yet clear whether existing noti-
fication and transaction protocols can be scaled to a prob-
lem that includes this type of asynchrony.
Second, workflow involves a mix of automated ser-
vices and human-enacted activities. While protocols have
focused on one or the other, only the workflow communi-
ty has explored the issues for seamlessly intermixing of
the two.
References
1. Workflow Management Coalition (WfMC), “The Workflow
Management Coalition Reference Model,” Tech. Report WFMC-TC-
1003, v.1.1, Jan. 1995.
2. G. Taubes, “Taming Virtual Taskmasters,” Networks series,
IBM
Research
, Vol. 36, No. 3, 1998 pp. 7-9; also available online at
http://www.research.ibm.com/resources/magazine/1998/issue_2/
networks398.html.
3. R. Fielding et al., “Support for the Virtual Enterprise: Web-based
Development of Complex Information Products,”
Comm. of the ACM
,
Vol. 41, No. 8, Aug. 1998, pp. 84-92.
Related Workflow Standards
.
1999, identifies the following opera-
tions as desirable goals:
Initiate. Create, remotely set up,
and invoke a workflow process.
Set up the work with the appro-
priate values and permissions, or
provide references to resources
and data as needed.
Monitor. Check the work’s current
status, get a history of the execu-
tion, or find out the current and
possible states. The latter may
include collectively reviewing a set
of distributed activities.
Control. Read and set the running
state of remote, generic, asynchro-
nous workflow services. Pause or
resume an executing workflow
after it is running, or terminate it
when it is no longer needed.
Notify. Send appropriate notifica-
tions of status changes to interest-
ed observers during normal execu-
tion or when exceptions occur.
A generic workflow service appears
externally as a small number of differ-
ent resources provided by a server.
Resources are distinguished by their
Web address in the form of a Uniform
Resource Identifier, as opposed to a
URL—first because a URL often con-
fuses the name of a resource with its
location. Additionally, an expectation
of how named resources are generated
is implicit in a URI scheme.
SWAP doesn’t enforce the naming
of the actual locator for a particular
process resource; it allows the host
company to determine this individu-
ally. The host company may then
adopt a generative scheme that
includes human-friendly identifiers
where appropriate.
Implementation of these resources
(services and/or objects) is outside the
protocol’s scope. SWAP is concerned
only with ensuring that requests are
made to valid URIs such that a prop-
er and consistent result is returned.
SWAP uses the following interface
definitions in forming a workflow
model:
Process instance. The actual per-
former of the workflow service.
Every time a service is invoked, a
new process instance is created,
started, paused, resumed, or
terminated.
Process definition. The named
resource from which process
instances can be created. The
process definition URI is the loca-
tion of the generic service from
which multiple instances are
shared.
Observer. A resource interested in
the completion of a process
instance. Given a list of observer
URIs, a process instance can noti-
fy observers when the process has
changed state or completed.
Activity observer. A type of observ-
er that allows a process instance to
be notified upon completion of
external work. A process instance
may need to invoke a subprocess
instance on a remote system. An
activity observer simply provides
an interface to browse parent-
child process dependencies and to
receive notification of a completed
subprocess.
Work list/work item. A process
instance that represents a human-
executed activity. Work items hold
the references to activities for the
people who are expected to per-
form them and who can, in turn,
search and retrieve all work items
assigned to them.
A workflow process instance is created
when actual resources are committed
to accomplishing a workflow service,
usually when the service is invoked.
Resources can support multiple inter-
faces. For example, if it is necessary to
invoke a remote service on another
machine, a resource can implement
both the process instance and the
observer interfaces.
Mapping Control Mechanisms. A
process instance may run for days,
months, or even years. Because of the
asynchronous nature of workflow,
mechanisms for controlling and man-
aging it using HTTP need to be
mapped out. Keeping an HTTP con-
nection alive long enough to perform
changes and monitor progress of a
long-running workflow process, while
doable, is not something the hyper-
text protocol was designed to support.
SWAP assumes that the workflow
engine has the ability to map the pro-
tocol methods and translate the para-
meters to the appropriate workflow
process instances and to return the
appropriate values. Here’s how it
works.
Let’s say that a process definition is
offered at a specific URI. An HTTP
request to the URI invokes a new
process instance. A given workflow
implementation has complete control
over how it creates the URI that names
the target process. Names serve as a
unique ID for the process involved.
They are used as a unique service ID
for other requests to that process
instance. For example, an HTTP
request can provide data to the process
instance through name-value pairs.
Another request could retrieve the cur-
rent state of the process instance, or
pause, resume, or terminate it. Every
interaction specifies a method, the
standard HTTP header field that con-
trols what action the server takes.
There is still some debate in the
working group about whether adding
methods particular to SWAP is the
appropriate approach. This column
describes the current thinking, but the
same functionality could easily be sup-
ported using just the HTTP POST
method and passing the SWAP-specif-
ic directives in the parameter values.
All parameters, including scoping
and name spaces, are put into an
XML encoding to be sent with the
appropriate calls. In the example of
Figure 1, the root node has a list of
attributes, including interfaces,
process instance key, valid states, actu-
al state, and data. From this XML
snippet, we can determine the values
and state of that process instance as
well as other possible instances.
The example shows a hypothetical
purchase order made by the SWAP
working group chair using the config-
uration information provided by an
online PC manufacturer. Upon the
request, SWAP creates a trackable
process instance but doesn’t begin exe-
cuting the process. The method call
in this case returns the HTTP status
code indicating multiple return values
as seen in Figure 2.
It turns out that the memory size
conflicts with the order configuration.
The customer can then choose to ter-
COLLABORATIVE WORK
87
IEEE INTERNET COMPUTING
http://computer.org/internet/
JANUARY • FEBRUARY 1999
.
minate the purchase order or amend
it using the appropriate PROPFIND
and PROPPATCH methods for assign-
ing particular values.
Conclusions
SWAP has the potential to provide
interoperability between workflow
systems using the Web and the
Internet, allowing distributed work-
flow solutions to be more easily
deployed and accessed than at pre-
sent. SWAP’s simple workflow model
and implementation approach allow
business processes to be structured
more naturally. This will encourage
people to use the network and com-
puting infrastructure already in place
in their company’s work culture.
SWAP allows abstraction through
its support of process and subprocess
execution across multiple machines
and between various workflow vendor
implementations. Its standardization
will provide a framework not just for
sharing documents but also for coor-
dinating the activities that surround
them. By limiting the protocol’s
scope, the SWAP working group
hopes to quickly define a usable pro-
tocol specification that leverages work
to date in both the workflow and
Web communities. The goal is to
increase the Web’s potential as an
infrastructure for building and
deploying workflow solutions and
also alleviating the difficulty of con-
structing such solutions.
An early prototype of a SWAP-
enabled HTTP server was built at
Netscape, however, no reference
implementation has yet been made.
Many of the workflow vendors partic-
ipating in the SWAP working group
support HTTP in some capacity, so
discussions about interoperability
demos are in the works. In the mean-
time, the protocol is being iteratively
revised, and the working group open-
ly welcomes participation.
ACKNOWLEDGMENT
The authors would like to acknowledge Keith
Swenson, Surendra Reddy, Richard Heim, Lisa
Lippert, and members of the SWAP mailing list
for their comments and feedback.
REFERENCE
1. K. Swenson, “Simple Workflow Access
Protocol (SWAP),” Strawman document,
Aug. 1998, available online at http://www.
ietf.org/internet-drafts/draft-swenson-swap-
prot-00.txt.
Gregory Alan Bolcer received a PhD and BS
from the University of California, Irvine,
and an MS from the University of
Southern California. He is the founder
and CEO of Endeavors Technology Inc., a
supplier of Web-based workflow solutions.
Gail Kaiser is a professor of computer science
and director of the Programming Systems
Library at Columbia University. She is on
the IEEE Internet Computing editorial board.
COLUMN
88
JANUARY • FEBRUARY 1999
http://computer.org/internet/
IEEE INTERNET COMPUTING
>>Response
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxxx
<?xml version=“1.0” ?>
<s:swap xmlns:s=“SWAP:”>
<s:multistatus>
<s:response>
<s:processInstance>
<s:href>
http://www.widget-makers.com/status?proc=10.1
</s:href>
<?-- “other items as defined by process” -->
</s:processInstance>
<s:propstat>
<s:prop><z:size/</s:prop>
<s:status>HTTP/1.1 409 Conflict</s:status>
<s:comment>part unavailable</s:comment>
</s:propstat>
<s: propstat>
<?-- “other resource properties” -->
</s:propstat>
</s:response>
</s:multistatus>
</s:swap>
</xml>
Figure 2. XML return values for a SWAP call.
>>Request
CREATEPROCESSINSTANCE /submit/order?proc=10 HTTP/1.1
Host: www.widget-makers.com
Content-Type: text/xml
Content-Length: xxxx
Authorization: Digest username=“skreddy”
realm=“skreddy@oracle.com”, ...
<?xml version=“1.0” ?>
<s:swap xmlns:s=“SWAP:”>
<s:observer>http://www.ics.uci.edu/pub/ietf/swap/chair.html</s:observer>
<s:name>equipment-purchase-process</s:name>
<s:subject>procurement</s:subject>
<s:description>New equipment purchase</s:description>
<s:contextData>
<z:processor xmlns:z=http://conf.pcmanufact.com>
pentiumII
</z:processor>
<z:memory xmlns:z=http://conf.pcmanufact.com>
<z:size>256 Meg</z:size>
<z:speed>60 ns</z:speed>
<z:type>DRAM</z:type>
</z:memory>
<!-- “name, billing address, etc.” -->
</s:contextData>
<s:startImmediately>no</s:startImmediately><!-- “available?” -->
</s:swap>
</xml>
Figure 1. XML encoding of SWAP content.
Interested in being an
IC reviewer?
IEEE Internet Computing is seek-
ing referees for article submissions
on Internet technologies. If you are
interested, please send your name,
contact information, curriculum
vita, and keywords for your areas of
expertise to Steve Woods
<swoods@computer.org>
.
... Autonomy means that an outsourcing service provider, called an insourcing company, can decide whether to and how much of its local data to share with an outsourcing service requester, called an outsourcing company. In spite of outsourcing agreements, most insourcing companies are usually reluctant to expose their core business information on their internal business logic and full process status to outsourcing companies (Bolcer, 1999;Georgakopoulos, 1999;Merz, 1999). Such unwillingness often confl icts with the need to share data, and therefore these two confl icting factors determine the degree of autonomy for the amount of shared data. ...
... This diversity of the process modeling methods makes it diffi cult to integrate different process models (Dabke, 1999;Georgakopoulos, 1999). To address this problem and accommodate seamless integration of different business process models, many standard organizations and researchers have proposed the canonical standard methods for process modeling (Workfl ow Management Coalition, 1998;Object Management Group, 2000;Bolcer, 1999). As a canonical standard method, this chapter uses concepts and notations (e.g., the graphical notations in Figures 1 and 2) of the workfl ow reference model (Workfl ow Management Coalition, 1998) proposed by the Workfl ow Management Coalition because of its popularity among commercial software vendors, and interoperability with other standards. ...
Chapter
Process information sharing is a beneficial tool through which a company can monitor and control its outsourced business process transparently, as if the outsourced business process is performed locally. However, autonomy and agility of insourcing companies providing outsourcing services have placed limitations in the development of process information sharing, which the previous research has not satisfactorily addressed. This chapter proposes a federated process framework and its system architecture that provide a conceptual design for effective implementation of process information sharing supporting the autonomy and agility of the insourcing companies. First, in terms of autonomy, the federated process framework supports a flexible sharing policy to control the amount of shared data so that the framework can be applied to a wide variety of practical situations, from loosely-coupled cases to tightly-coupled cases. Second, in terms of agility, the system architecture based on the federated process framework supports the entire life cycle of business process outsourcing by allowing sufficient adaptability to the changes of business environments. We develop the framework using an object-oriented database and Extensible Markup Language to accommodate all the constructs and their interactions within object-oriented message exchange model in a distributed computing environment.
... While there are clear differences between the formalisms, it is possible to generalize in terms of their basic expressive commitments and therefore suitability for modeling dynamic, flexible workflows (Conradi & Jaccheri, 1998;Curtis, Kellner & Over, 1992;Green & Rosemann, 2000;Lei & Singh, 1997). The standards defined by the Workflow Management Coalition (Fischer, 2001), the Internet Engineering Task Force (IETF) (Bolcer & Kaiser, 1999), and the Object Management Group (OMG, 2000) are all predicated on a common perspective. We consider a few languages from this perspective. ...
Chapter
Much of the early focus in the area of Semantic Web has been on the development of representation languages for static conceptual information; while there has been less emphasis on how to make Semantic Web applications practically useful in the context of knowledge work. To achieve this, a better coupling is needed between ontology, service descriptions, and workflow modeling, including both traditional production workflow and interactive workflow techniques. This chapter reviews the basic technologies involved in this area to provide system and business interoperability, and outlines what can be achieved by merging them in the context of real-world workflow descriptions.
... While there are clear differences between the formalisms, it is possible to generalize in terms of their basic expressive commitments and therefore suitable for modeling dynamic, flexible workflows (Conradi & Jaccheri, 1998;Curtis, Kellner, & Over, 1992;Green & Rosemann, 2000;Lei & Singh, 1997). The standards defined by the Workflow Management Coalition (Fischer, 2001), the Internet Engineering Task Force (IETF) (Bolcer & Kaiser, 1999), and the Object Management Group (OMG, 2000) are all predicated on a common perspective. We consider a few languages from this perspective. ...
Chapter
Much of the early focus in the area of Semantic Web has been on the development of representation languages for static conceptual information, while there has been less emphasis on how to make Semantic Web applications practically useful in the context of knowledge work. To achieve this, a better coupling is needed between ontology, service descriptions and workflow modeling, including both traditional production workflow and interactive workflow techniques This article reviews the basic technologies involved in this area to provide system and business interoperability, and outlines what can be achieved by merging them in the context of real world workflow descriptions.
... While there are clear differences between the formalisms, it is possible to generalize in terms of their basic expressive commitments and therefore suitable for modeling dynamic, flexible workflows (Conradi & Jaccheri, 1998;Curtis, Kellner, & Over, 1992;Green & Rosemann, 2000;Lei & Singh, 1997). The standards defined by the Workflow Management Coalition (Fischer, 2001), the Internet Engineering Task Force (IETF) (Bolcer & Kaiser, 1999), and the Object Management Group (OMG, 2000) are all predicated on a common perspective. We consider a few languages from this perspective. ...
Chapter
Much of the early focus in the area of Semantic Web has been on the development of representation languages for static conceptual information, while there has been less emphasis on how to make Semantic Web applications practically useful in the context of knowledge work. To achieve this, a better coupling is needed between ontology, service descriptions and workflow modeling, including both traditional production workflow and interactive workflow techniques This article reviews the basic technologies involved in this area to provide system and business interoperability, and outlines what can be achieved by merging them in the context of real world workflow descriptions.
... While there are clear differences between the formalisms, it is possible to generalize in terms of their basic expressive commitments and therefore suitability for modeling dynamic, flexible workflows (Conradi & Jaccheri, 1998;Curtis, Kellner & Over, 1992;Green & Rosemann, 2000;Lei & Singh, 1997). The standards defined by the Workflow Management Coalition (Fischer, 2001), the Internet Engineering Task Force (IETF) (Bolcer & Kaiser, 1999), and the Object Management Group (OMG, 2000) are all predicated on a common perspective. We consider a few languages from this perspective. ...
Article
Full-text available
Much of the early focus in the area of Semantic Web has been on the development of representation languages for static conceptual information; while there has been less emphasis on how to make Semantic Web applications practically useful in the context of knowledge work. To achieve this, a better coupling is needed between ontology, service descriptions, and workflow modeling, including both traditional production workflow and interactive workflow techniques. This chapter reviews the basic technologies involved in this area to provide system and business interoperability, and outlines what can be achieved by merging them in the context of real-world workflow descriptions.
... Input and output relations thus define the sequence of work. This perspective is chosen for the standards of the Workflow Management Coalition (WfMC 2000), the Internet Engineering Task Force (IETF) (Bolcer and Kaiser, 1999), and the Object Management Group (OMG 2000) as well as most commercial systems (Fisher 2000). IDEF-0 (1993) and Data Flow Diagram (DFD) (Gane and Sarson 1979) are paradigm examples of this. ...
Article
An important area of BPM is the modeling of processes. Processes modeling is done for a number of reasons in relation to BPM, and this chapter will describe main approaches to different types of process modeling. Modeling approaches will be structured according to the main modeling perspective being used. In conceptual modeling in general, one can identify 8 modeling perspectives; behavioral, functional, structural, goal-oriented, object-oriented, language action, organizational and geographical. In this chapter, we will present examples of process modeling according to these different perspectives, and discuss what perspectives are most appropriate to use to achieve the different goals of modeling.
... Input and output relations thus de fi ne the sequence of work. This perspective is chosen for the standards of the Work fl ow Management Coalition (WfMC 2001 ) , the Internet Engineering Task Force (IETF) (Bolcer and Kaiser 1999 ) , as well as most commercial systems. ...
Chapter
Full-text available
In this chapter, we will give an overview of general mechanisms and perspectives used in conceptual modelling. We will first look upon modelling as a type of hierarchical abstraction. We present main abstraction mechanisms used in modelling languages (generalisation, aggregation, classification, association). Meta-modelling as a type of classification is discussed specifically, as is influence of philosophical ontology through BWW and UEML. We survey different modelling languages according to the main phenomena they describe, what we call the main modelling perspective of a modelling language. We have identified eight perspectives (behavioural, functional, structural, goal and rule, object-oriented, communicational, actor and role and topological). We discuss process modelling according to these perspectives before finally we discuss how to apply several such perspectives at the same time in an integrated manner, including examples of different approaches for integrating different perspectives in one language both for design modelling (UML) and enterprise modelling (EEML).
Article
The unpredictability of business processes requires that workflowsystems support exception handling with the ability to dynamicallyadapt to the changing environment. Traditional approaches to handlingthis problem have fallen short, providing little support for change,particularly once the process has begun execution. Further,exceptions vary widely in their character and significance,challenging the application of any single approach to handling them.We briefly discuss the classification of exceptions, highlightingdiffering impacts on the workflow model. Based on this discussion, wesuggest principal goals to address in the development of adaptiveworkflow support, including strategies for avoiding exceptions,detecting them when they occur, and handling them at various levels ofimpact. We then identify a number of specific approaches to supportingthese goals within the design of a workflow system infrastructure.Finally, we describe the implementation of many of these approaches inthe Endeavors workflow support system.
Chapter
Workflow Computing bezeichnet ein Gebiet der Informationsverarbeitung, in dem die dv-technische Unterstützung des betrieblichen Arbeitsflusses (Workflow) im Mittelpunkt steht. Im Gegensatz zum Workgroup Computing geht es dabei weniger um die Unterstützung kooperativer Arbeit im Team, sondern vielmehr um die Koordination arbeitsteiliger Vorgänge über verschiedene Arbeitskräfte hinweg. Die im Workflow Computing dominierende Technologie sind sog. Workflow-Management-Systeme, mittels derer sich prozeßorientierte Anwendungssysteme (Workflow-Anwendungen, Workflow-Systeme) realisieren lassen. Unter Workflow- Management-Systemen kann man veranschaulichend ein Instrument zur Automatisierung von „Arbeitsplänen für das Büro“ verstehen.
Chapter
Die Globalisierung elektronischer Märkte fordert von Unternehmen, dass sie sich fortlaufend der weltweiten Herausforderung stellen. Die Notwendigkeit der Reduzierung des Aufwands für Entwicklung, Produktion, Markteinführung und Betrieb, die Forderung nach verbesserter Dienstleistung und Anpassung an Kundenwünsche und Marktbewegungen sowie das Bestreben nach globaler Präsenz und Wirkung hat in den letzten Jahren bereits zum Einsatz elektronischer Informations- und Kommunikationssysteme zur Unterstützung von Automatisierung, Verteilung der Zuständigkeiten und intensivierter Zusammenarbeit innerhalb und zwischen Unternehmen geführt (Applegate 96, Malone 91, Ouzounis 98a). Das Ergebnis ist eine weitgehend heterogene Welt elektronischer Informations- und Kommunikationsplattformen und eine Vielzahl darauf zugeschnittener Anwendungen.
Article
This article focuses on drawbacks of web architectures, considering the need of virtual enterprises. The article suggests that sharing information without regard to physical location through Internet, has promoted new forms of virtual business and social endeavors. A virtual enterprise is an organization unconstrained by geographic location, and a membership intersecting multiple traditional organizations. All that is needed to form a virtual enterprise is at least one common goal, a shared information space, a means of coordinating users' efforts, and people willing to share the work. The Web provides the minimum for setting up such enterprises by enabling identification of shared goals and the people who share them, by providing a standard mechanism for reading the shared information space, and by supporting coordination via e-mail archives. The infrastructure improvements described in this article are applicable to any virtual enterprise that includes creation of complex information products as one of its goals.
Taming Virtual Taskmasters
  • G Taubes
G. Taubes, "Taming Virtual Taskmasters," Networks series, IBM Research, Vol. 36, No. 3, 1998 pp. 7-9; also available online at http://www.research.ibm.com/resources/magazine/1998/issue_2/ networks398.html.
The Workflow Management Coalition Reference Model
Workflow Management Coalition (WfMC), " The Workflow Management Coalition Reference Model, " Tech. Report WFMC-TC- 1003, v.1.1, Jan. 1995.