The paradigmatic shift from a Web of manual interactions to a Web of programmatic interactions driven by Web services is creating unprecedented opportunities for the formation of online business-to-business (B2B) collaborations. In particular, the creation of value-added services by composition of existing ones is gaining a significant momentum. Since many available Web services provide overlapping or identical functionality, albeit with different quality of service (QoS), a choice needs to be made to determine which services are to participate in a given composite service. This paper presents a middleware platform which addresses the issue of selecting Web services for the purpose of their composition in a way that maximizes user satisfaction expressed as utility functions over QoS attributes, while satisfying the constraints set by the user and by the structure of the composite service. Two selection approaches are described and compared: one based on local (task-level) selection of services and the other based on global allocation of tasks to services using integer programming.

/pdf/qos-aware-middleware-for-web-services-composition-x57gs4mhme.pdf

QoS-aware middleware for Web services composition

Differences in features supported by the various contemporary commercial workflow management systems point to different insights of suitability and different levels of expressive power. The challenge, which we undertake in this paper, is to systematically address workflow requirements, from basic to complex. Many of the more complex requirements identified, recur quite frequently in the analysis phases of workflow projects, however their implementation is uncertain in current products. Requirements for workflow languages are indicated through workflow patterns. In this context, patterns address business requirements in an imperative workflow style expression, but are removed from specific workflow languages. The paper describes a number of workflow patterns addressing what we believe identify comprehensive workflow functionality. These patterns provide the basis for an in-depth comparison of a number of commercially available workflow management systems. As such, this paper can be seen as the academic response to evaluations made by prestigious consulting companies. Typically, these evaluations hardly consider the workflow modeling language and routing capabilities, and focus more on the purely technical and commercial aspects.

Workflow Patterns

Many scientific disciplines are now data and information driven, and new scientific knowledge is often gained by scientists putting together data analysis and knowledge discovery “pipelines”. A related trend is that more and more scientific communities realize the benefits of sharing their data and computational services, and are thus contributing to a distributed data and computational community infrastructure (a.k.a. “the Grid”). However, this infrastructure is only a means to an end and scientists ideally should be bothered little with its existence. The goal is for scientists to focus on development and use of what we call scientific workflows. These are networks of analytical steps that may involve, e.g., database access and querying steps, data analysis and mining steps, and many other steps including computationally intensive jobs on high performance cluster computers. In this paper we describe characteristics of and requirements for scientific workflows as identified in a number of our application projects. We then elaborate on Kepler, a particular scientific workflow system, currently under development across a number of scientific data management projects. We describe some key features of Kepler and its underlying Ptolemyii system, planned extensions, and areas of future research. Kepler is a communitydriven, open source project, and we always welcome related projects and new contributors to join.

/pdf/scientific-workflow-management-and-the-kepler-system-5a9uicngu7.pdf

Scientific Workflow Management and the Kepler System

Business Process Management (BPM) includes methods, techniques, and tools to support the design, enactment, management, and analysis of operational business processes. It can be considered as an extension of classical Workflow Management (WFM) systems and approaches. Although the practical relevance of BPM is undisputed, a clear definition of BPM and related acronyms such as BAM, BPA, and STP are missing. Moreover, a clear scientific foundation is missing. In this paper, we try to demystify the acronyms in this domain, describe the state-of-the-art technology, and argue that BPM could benefit from formal methods/languages (cf. Petri nets, process algebras, etc.).

/pdf/business-process-management-a-survey-mkhfh265q2.pdf

Business process management: a survey

http://www.workflowpatterns.com/documentation/documents/yawl_qut_report_FIT-TR-2002-06.pdf

YAWL: yet another workflow language

Conventional workflow functionality like task sequencing, split parallelism, join synchronization and iteration have proven effective for business process automation and have widespread support in current workflow products. However, newer requirements for workflows are encountered in practice, opening grave uncertainties about the extensions for current languages. Different concepts, although outwardly appearing to be more or less the same, are based on different paradigms, have fundamentally different semantics and different levels of applicability – more specialized for modeling or more generalized for workflow engine posit. By way of developmental insight of new requirements, we define workflow patterns which are described imperatively but independently of current workflow languages. These patterns provide the basis for an in-depth comparison of 12 workflow management systems. As such, the work reported in this paper can be seen as the academic response to evaluations made by prestigious consulting companies. Typically, these evaluations hardly consider the workflow modeling language and routing capabilities and focus more on the purely technical and commercial aspects.

Advanced Workflow Patterns

While there are many similarities between the languages of the various workflow management systems, there are also significant differences. One particular area of differences is caused by the fact that different systems impose different syntactic restrictions. In such cases, business analysts have to choose between either conforming to the language in their specifications or transforming these specifications afterwards. The latter option is preferable as this allows for a separation of concerns. In this paper we investigate to what extent such transformations are possible in the context of various syntactical restrictions (the most restrictive of which will be referred to as structured workflows). We also provide a deep insight into the consequences, particularly in terms of expressive power, of imposing such restrictions.

/pdf/on-structured-workflow-modelling-2jobvh3ohf.pdf

On Structured Workflow Modelling

Although workflow management emerged as a research area well over a decade ago, little consensus has been reached as to what should be essential ingredients of a workflow specification language. As a result, the market is flooded with workflow management systems, based on different paradigms and using a large variety of concepts. The goal of this paper is to establish a formal foundation for control-flow aspects of workflow specification languages, that assists in understanding fundamental properties of such languages, in particular their expressive power. Workflow languages can be fully characterized in terms of the evaluation strategy they use, the concepts they support, and the syntactic restrictions they impose. A number of results pertaining to this classification will be proven. This should not only aid those developing workflow specifications in practice, but also those developing new workflow engines.

/pdf/fundamentals-of-control-flow-in-workflows-3i0iswqfmp.pdf

Fundamentals of control flow in workflows

The Distributed Systems Technology Centre (DSTC) framework for workflow specification, verification and management captures workflows transaction-like behavior for long lasting processes. FlowBack is an advanced prototype functionally enhancing an existing workflow management system by providing process backward recovery. It is based on extensive theoretical research ([3],[4],[5],[6],[8],[9]), and its architecture and construction assumptions are product independent. FlowBack clearly demonstrates the extent to which generic backward recovery can be automated and system supported. The provision of a solution for handling exceptional business process behavior requiring backward recovery makes workflow solutions more suitable for a large class of applications, therefore opening up new dimensions within the market. For the demonstration purpose, FlowBack operates with IBM FlowMark, one of the leading workflow products.

Bartek Kiepuszewski

Papers

Workflow Patterns

Advanced Workflow Patterns

On Structured Workflow Modelling

Fundamentals of control flow in workflows

FlowBack: providing backward recovery for workflow management systems