David Edmond

Workflow resource patterns: identification, representation and tool support

In the main, the attention of workflow researchers and workflow developers has focussed on the process perspective, i.e., control-flow. As a result, issues associated with the resource perspective, i.e., the people and machines actually doing the work, have been largely neglected. Although the process perspective is of most significance, appropriate consideration of the resource perspective is essential for successful implementation of workflow technology. Previous work has identified recurring, generic constructs in the control-flow and data perspectives, and presented them in the form of control-flow and data patterns. The next logical step is to describe workflow resource patterns that capture the various ways in which resources are represented and utilised in workflows. These patterns include a number of distinct groupings such as push patterns (“the system pushes work to a worker”) and pull patterns (“the worker pulls work from the system”) to describe the many ways in which work can be distributed. By delineating these patterns in a form that is independent of specific workflow technologies and modelling languages, we are able to provide a comprehensive treatment of the resource perspective and we subsequently use these patterns as the basis for a detailed comparison of a number of commercially available workflow management systems.

Worklets: a service-oriented implementation of dynamic flexibility in workflows

This paper presents the realisation, using a Service Oriented Architecture, of an approach for dynamic flexibility and evolution in workflows through the support of flexible work practices, based not on proprietary frameworks, but on accepted ideas of how people actually work A set of principles have been derived from a sound theoretical base and applied to the development of worklets, an extensible repertoire of self-contained sub-processes aligned to each task, from which a dynamic runtime selection is made depending on the context of the particular work instance.

What's in a Service?

A proper understanding of the general nature, potential and obligations of electronic services may be achieved by examining existing commercial services in detail. The everyday services that surround us, and the ways in which we engage with them, are the result of social and economic interaction that has taken place over a long period of time. If we attempt to provide electronic services, and do not take this history into account, then we will fail. Any attempt to provide automated electronic services that ignores this history will deny consumers the opportunity to negotiate and refine, over a large range of issues, the specific details of the actual service to be provided. To succeed, we require a rich and accurate means of representing services. An essential ingredient of service representation is capturing the non-functional properties of services. These include the methods of charging and payment, the channels by which the service is requested and provided, constraints on temporal and spatial availability, service quality, security, trust and the rights attached to a service. Not only are comprehensive descriptions essential for useful service discovery, they are also integral to service management, enabling service negotiation, composition, and substitution. This paper builds on an understanding of services and their interactions, to outline the non-functional properties of services and their uses.

Workflow data patterns: identification, representation and tool support

Workflow systems seek to provide an implementation vehicle for complex, recurring business processes. Notwithstanding this common objective, there are a variety of distinct features offered by commercial workflow management systems. These differences result in significant variations in the ability of distinct tools to represent and implement the plethora of requirements that may arise in contemporary business processes. Many of these requirements recur quite frequently during the requirements analysis activity for workflow systems and abstractions of these requirements serve as a useful means of identifying the key components of workflow languages. In this paper, we describe a series of workflow data patterns that aim to capture the various ways in which data is represented and utilised in workflows. By delineating these patterns in a form that is independent of specific workflow technologies and modelling languages, we are able to provide a comprehensive treatment of the workflow data perspective and we subsequently use these patterns as the basis for a detailed comparison of a number of commercially available workflow management systems, workflow standards and web-service composition languages.

Towards A Semantic Framework for Service Description

The inexpensive and global connectivity provided by the Internet has triggered a wave of interest in providing service-oriented electronic access to commercial activities. This pressure has led, in turn, to a need for accurate service description, so that we may advertise, locate, analyse and compare services. In this paper, we classify services by the context in which they are used. Next, we characterise both conventional and electronic services according to a range of domain independent attributes including price, payment method and availability. We examine possible representations for each of these service dimensions. By integrating these representations into a unified service description language, we hope to provide a means to lubricate the electronic services marketplace.

Achieving a general, formal and decidable approach to the OR-Join in workflow using reset nets

Workflow languages offer constructs for coordinating tasks. Among these constructs are various types of splits and joins. One type of join, which shows up in various incarnations, is the OR-join. Different approaches assign a different (often only intuitive) semantics to this type of join, though they do share the common theme that synchronisation is only to be performed for active threads. Depending on context assumptions this behaviour may be relatively easy to deal with, though in general its semantics is complicated, both from a definition point of view (in terms of formally capturing a desired intuitive semantics) and from a computational point of view (how does one determine whether an OR-join is enabled?). In this paper the concept of OR-join is examined in detail in the context of the workflow language YAWL, a powerful workflow language designed to support a collection of workflow patterns and inspired by Petri nets. The OR-joins definition is adapted from an earlier proposal and an algorithmic approach towards determining OR-join enablement is examined. This approach exploits a link that is proposed between YAWL and Reset nets, a variant of Petri nets with a special type of arc that can remove all tokens from a place.

Business process verification – finally a reality!

Bis(aminophenyl) ethers are prepared by effecting condensation reaction of an (N-acetyl)aminophenol or the corresponding sodium or potassium (N-acetyl)aminophenate with a halonitrobenzene under condensation reaction conditions to form an (N-acetyl)aminophenylnitrophenyl ether and hydrogenating the nitro group thereof under nitro- group hydrogenation conditions to form an (N-acetyl)bis(aminophenyl) ether. The latter compound is hydrolyzed with aqueous mineral acid under acid hydrolysis conditions to form an acidic aqueous dispersion of the bis(aminophenyl) ether product, which can readily be recovered from the disperson. Final bis(aminophenyl) ether products thus prepared are typically of high purity and excellent color properties, i.e., substantially colorless.

Capabilities: Describing What Services Can Do

The ability of agents and services to automatically locate and interact with unknown partners is a goal for both the semantic web and web services. This, “serendipitous interoperability”, is hindered by the lack of an explicit means of describing what services (or agents) are able to do, that is, their capabilities. At present, informal descriptions of what services can do are found in “documentation” elements; or they are somehow encoded in operation names and signatures. We show, by reference to existing service examples, how ambiguous and imprecise capability descriptions hamper the attainment of automated interoperability goals in the open, global web environment. In this paper we propose a structured, machine readable description of capabilities, which may help to increase the recall and precision of service discovery mechanisms. Our capability description draws on previous work in capability and process modeling and allows the incorporation of external classification schemes. The capability description is presented as a conceptual meta model. The model supports conceptual queries and can be used as an extension to the DAML-S Service Profile.

The Use of Patterns in Service Composition

E-services are services that can be invoked over the Internet. One likely use of e-services would be to build business applications that can employ e-services from different service providers. This potential use of composite services in business settings highlights the issues of payment mechanisms, reliability, trust, inter-operability and service guarantees between different service providers. It also becomes essential to choose e-services that best fulfil the requirements of a particular business application. We investigate how patterns can be used in service composition to help in the development of business applications based on e-services.

A reflective infrastructure for workflow adaptability

Abstract We present a flexible framework that enables workflow systems to adapt to changing conditions. The model is designed to reveal key aspects of the tasks involved in representing and enacting business processes. These fundamental characteristics are identified as state, behaviour, distribution, coordination and enactment. By isolating such core concepts in a way that allows them to be varied, we open up the general process of task coordination and execution, allowing for extensions in a planned way. By suitable manipulation of each of these aspects, at the appropriate level, a workflow system may be extensively modified in a way that minimises the effect of such change upon other aspects of the system.