d4 - cordis · d4.1 version: 2.0 date: 2009-06-08 dissemination status: pu document reference: d4.1...

State-of-the-art report on the existing approaches to improving reusability of processes and service compositions

Project acronym: COMPAS

Project name: Compliance-driven Models, Languages, and Architectures for Services

Call and Contract: FP7-ICT-2007-1

Grant agreement no.: 215175

Project Duration: 01.02.2008 – 28.02.2011 (36 months)

Co-ordinator: TUV Vienna University of Technology (AT)

Partners: CWI Stichting Centrum voor Wiskunde en Informatica (NL)

UCBL Université Claude Bernard Lyon 1 (FR)

USTUTT Universitaet Stuttgart (DE)

TILBURG UNIVERSITY Stichting Katholieke Universiteit Brabant (NL)

UNITN Universita degli Studi di Trento (IT)

TARC-PL Telcordia Poland (PL)

THALES Thales Services SAS (FR)

PWC Pricewaterhousecoopers Accountants N.V. (NL)

This project is supported by funding from the Information Society Technologies Programme under the 7th

Research Framework Programme of the European Union.

D4.1

Version: 2.0 Date: 2009-06-08

Dissemination status: PU Document reference: D4.1

FP7-215175 COMPAS D4.1v2.0

File: D4.1_State-of-the-Art-Report-for-Improving-Reusability.doc of 68

Project no. 215175

COMPAS Compliance-driven Models, Languages, and Architectures for Services

Specific Targeted Research Project

Information Society Technologies

Start date of project: 2008-02-01 Duration: 36 months

D4.1 State-of-the-art report on the existing approaches to improving reusability of processes and service compositions

Revision 2.0

Due date of deliverable: 2008-12-31

First submission date: 2008-12-30

Latest submission date: 2009-06-08

Organisation name of lead partner for this deliverable:

USTUTT- Universitaet Stuttgart, Germany

Contributing partner(s):

UCBL - Université Claude Bernard Lyon 1, France

Project funded by the European Commission within the Seventh Framework Programme Dissemination Level

PU Public X PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services)

FP7-215175 COMPAS D4.1v2.0


History chart Issue Date Changed page(s) Cause of change Implemented by 0.1 2008-05-09 All sections New document USTUTT 0.2 2008-09-22 Document structure Improvement, Update USTUTT 0.3 2008-10-29 Document structure and

Description of first approach Improvement, First approach description was added

USTUTT

0.4 2008-11-07 Complete migration of document to new COMPAS deliverable formatting

Changes in deliverable template concerning formatting

USTUTT

0.5 2008-11-14 Added Section 1.2, 2.1, 2.3, changed Section 1.2, 1.4

Added content USTUTT

0.61 2008-12-05 Added Sections Abstract, 2.2.4, 2.2.6, 2.2.7, 2.2.21

Added content UCBL

0.62 2008-12-05 Added Section 2.2.16 (reference models), Duplicated Comparison-Table


0.63 2008-12-05 Added Section 2.2.20 (process variants)


0.64 2008-12-09 Improvement of document: terminology, formatting, Section 2.2.4 removed, Section 2.2.6 Process Annotation removed, 2.2.7 Process fragments removed and added to section Relation to COMPAS

Document improvement USTUTT

0.65 2008-12-09 Improvement of formatting and comparison table

Document improvement USTUTT

0.66 2008-12-11 Various approaches, conclusions, relation to compliance

Added content UCBL

0.67 2008-12-15 Added content to Section 2.2.6 (AOP), added content to Section 4.2 Relation to COMPAS, added references to internal and external documents


0.68 2008-12-16 Improvement of Section 4.2, subsection concerning identification of requirements for prospective deliverable D4.3 has been added to section 4.2

Document improvement, added content

USTUTT

0.7 2008-12-17 Improvement of content and formatting of whole document

Preparation of document for review by WP4 partners

USTUTT

0.8 2008-12-21 All sections Integration of comments from reviews, restructuring

USTUTT, UCBL

FP7-215175 COMPAS D4.1v2.0


0.9 2008-12-23 All sections Finalization USTUTT 0.99 2008-12-27 Approved TUV 1.0 2008-12-30 Released TUV 2.0 2009-06-08 Approved & Released TUV

Authorisation No. Action Company/Name Date 1 Prepared USTUTT, UCBL 2008-12-23 2 Approved TUV 2008-12-27 3 Released TUV 2008-12-30 4 Approved TUV 2009-06-08 5 Released TUV 2009-06-08

Disclaimer: The information in this document is subject to change without notice. Company or product names mentioned in this document may be trademarks or registered trademarks of their respective companies.

All rights reserved. The document is proprietary of the COMPAS consortium members. No copying or distributing, in any form or by any means, is allowed without the prior written agreement of the owner of the property rights.

This document reflects only the authors’ view. The European Community is not liable for any use that may be made of the information contained herein.

FP7-215175 COMPAS D4.1v2.0


Contents 1. Introduction ............................................................................................................................ 8

1.1. Purpose and scope ........................................................................................................... 8

1.2. Document overview ........................................................................................................ 9

1.3. Terminology .................................................................................................................... 9

1.4. Abbreviations and acronyms ........................................................................................... 9

2. State-of-the-art ..................................................................................................................... 11

2.1. Definition of criteria for reusability .............................................................................. 11

2.1.1. Subject of reuse ...................................................................................................... 11

2.1.2. Used techniques ...................................................................................................... 11

2.1.3. Phase in process life cycle ...................................................................................... 11

2.1.4. Application domain and coverage .......................................................................... 12

2.2. Approaches .................................................................................................................... 12

2.2.1. Ad-hoc Workflows / Case Handling ...................................................................... 12

2.2.2. Approaches from Programming ............................................................................. 15

2.2.3. Aspect-Oriented Programming .............................................................................. 15

2.2.4. Business Process Variants ...................................................................................... 18

2.2.5. Constraint-Based Workflows ................................................................................. 20

2.2.6. Declarative Processes ............................................................................................. 22

2.2.7. Extending BPEL for Runtime Adaptability ........................................................... 24

2.2.8. Extraction of Business Rules .................................................................................. 26

2.2.9. Goal-Orientation ..................................................................................................... 28

2.2.10. Parameterization of Web Service Flows .............................................................. 29

2.2.11. Reference Models ................................................................................................. 33

2.2.12. Sub-Processes ....................................................................................................... 35

2.2.13. Temporal Logic .................................................................................................... 39

2.2.14. Workflow Patterns ................................................................................................ 40

2.2.15. Worklets ............................................................................................................... 43

3. Comparison of Approaches .................................................................................................. 46

3.1. Comparison ................................................................................................................... 46

3.2. Analysis ......................................................................................................................... 56

3.2.1. Subject of reuse ...................................................................................................... 56

3.2.2. Used techniques ...................................................................................................... 56

3.2.3. Phase in the life cycle ............................................................................................. 57

3.2.4. Application domain and coverage .......................................................................... 57

FP7-215175 COMPAS D4.1v2.0


4. Conclusion ............................................................................................................................ 58

4.1. Summary ....................................................................................................................... 58

4.2. Relation to Compliance ................................................................................................. 58

4.3. Relation to COMPAS .................................................................................................... 59

4.3.1. Drawbacks of the existing approaches to improving reusability ........................... 59

4.3.2. Concept of process fragments ................................................................................ 59

4.3.3. Usage scenarios for reusing process fragments ...................................................... 60

4.3.4. Identification of requirements for classification and specification of reusable process artefacts ............................................................................................................... 62

5. Reference documents ........................................................................................................... 63

5.1. Internal documents ........................................................................................................ 63

5.2. External documents ....................................................................................................... 63

A. Appendix A ......................................................................................................................... 68

A.1. Related standards and technologies .............................................................................. 68

List of figures Figure 1 An example of top level template [VA97] ............................................................. 13

Figure 2 (cons) template and modifications [VA97] ............................................................ 14

Figure 3 Variants of a standardized product change process [HBR08] ............................... 19

Figure 4 Changes for constraint workflows [PSS+07] ......................................................... 21

Figure 5 A simple example of a ConDec model [PA06] ..................................................... 23

Figure 6 Business rule at context level [KEF00] ................................................................. 23

Figure 7 “Find and bind” mechanism [KHC+05] ................................................................ 25

Figure 8 State-of-the-art WS-flow [KLB05] ........................................................................ 32

Figure 9 Parameterized process and its instances [KLB05] ................................................. 32

Figure 10 Criteria for describing process reference models [FLZ05] ................................ 34

Figure 11 Invocation of a sub-process via receive-reply pattern [KKL+07] ...................... 37

Figure 12 Invocation of a sub-process via receive-invoke pattern [KKL+07] ................... 37

Figure 13 Synchronization pattern [AHK+03] ................................................................... 41

Figure 14 Exclusive choice pattern [AHK+03] .................................................................. 41

Figure 15 Unidirectional performative message pattern [TIR07] ...................................... 41

Figure 16 Activities in the "validate" pattern [MRV02] ..................................................... 42

Figure 17 Casualty treatment process [AEA+06] ............................................................... 44

Figure 18 Treat fever worklet process [AEA+06] .............................................................. 44

Figure 19 Annotations for describing behaviour ................................................................ 62

FP7-215175 COMPAS D4.1v2.0


List of tables Table 1 Mapping the evaluation strategies to BPEL constructs – an overview [KLN+06] 31

Table 2 Comparison of approaches 1 - 5 ............................................................................ 49

Table 3 Comparison of approaches 6 - 10 .......................................................................... 52

Table 4 Comparison of approaches 11 - 15 ........................................................................ 55

Table 5 Related standards and technologies ....................................................................... 68

List of listings Listing 1 A counting aspect in BPEL [Cha07] ...................................................................... 17

Listing 2 An example representation of the <find_bind> extension in BPEL [KHC+05] .... 26

Listing 3 An example representation of the <evaluate> extension in BPEL [KLN+06] ...... 31

Listing 4 Call activity in pseudo-syntax, without output and faults [KKL+07] ................... 38

FP7-215175 COMPAS D4.1v2.0


Abstract Work in process and service composition reuse focuses on reusing artefacts. In this case, representing and reusing artefacts is guided by a desired functionality and a given step in a process life cycle. This report is concerned with the analysis and classification of existing reuse approaches according to a set of identified criteria.

1. Introduction In the service-oriented architecture (SOA) domain, different approaches and platforms are being developed to address the goal of Web Services discovery and composition. Each approach provides perspectives to facilitate service integration. Approaches range from static and dynamic ones to manual or automated ones, and each approach defines its own methodology and technique for composing services, and provides its representation language. From a designer and developer’s perspective it is interesting to explore the way to reuse existing services. If reusable components are specified at a higher level of abstraction the reusability process can facilitate composition and hence accelerate application development. The increased availability of embeddable software components and the increasing popularity of the Internet have resulted in a new demand for reusable services. As a consequence, many consumers will spend more time in finding and selecting reusable artefacts since the choice of an appropriate artefact will have an impact on the product. The Motivations of reuse are primarily economic: The potential of saving cost, time and effort of redundant work, increase productivity; decreasing time to market and improving systems quality by reusing both the artifact and the underlying engineering experience. The challenges facing reuse are structural, organizational, managerial, and technical. Given their importance, the issues and problems associated with the representation and selection of suitable reusable artefacts are considered as important research issues in the service-oriented computing community. Some approaches dealing with techniques for reusing processes or service compositions were proposed. In this report, we investigate those approaches and analyze them by using a set of relevant criteria we identified from the literature.

1.1. Purpose and scope Reusing processes and service compositions could increase the productivity of service developers and improve the quality of resulting products by employing reusable units of high quality, that have already successfully proven in practice. The objective of a reuse system is to provide facilities allowing to easily retrieving reusable units. Since Web Services engineering is characterized by several levels of abstraction. Current reuse approaches focus on the reuse of desired artefacts at given levels of abstraction. For example, for a process to be reusable, it should be specified independently of the context in which it will be used. In addition, the representation formalism used to describe artefacts should make easy the process of retrieval, adaptation and verification.

Due to the Description of Work of the COMPAS project [DoW] this deliverable also employs this investigation to identify the requirements for classification and specification of reusable process artefacts for prospective deliverable D4.3 [D4.3].

FP7-215175 COMPAS D4.1v2.0


1.2. Document overview This report reflects the state-of-the-art of the existing approaches to improving reusability of processes and service compositions. In the beginning of this document the used terminology and abbreviations are addressed. The main part of the document is Section 2, where the state-of-the-art of approaches for improving reusability of processes and service compositions is discussed. The section starts with a description of the criteria which are employed for the analysis and discussion of the approaches. Afterwards the current approaches for improving reusability are introduced. In Section 3 a comparison based on the prior introduced criteria is drawn. In Section 4 the results of this literature research concerning reusability of processes and service compositions are summarized. During these conclusions the applicability of the presented approaches in the field of compliance is discussed, and also the relation and application of the presented approaches to the COMPAS project are discussed.

1.3. Terminology The most important terminology concerning the COMPAS project is listed on the public COMPAS Web-Site [D7.1] available at http://www.compas-ict.eu section terminology. This helps to make the overall COMPAS approach more comprehensive for the general public.

1.4. Abbreviations and acronyms AOP Aspect-Oriented Programming

API Application Programming Interface

BPEL Business Process Execution Language

BPEL4WS

BPM

Business Process Execution Language for Web Services

Business Process Management

BPML Business Process Modeling Language

BPMN Business Process Modeling Notation

CASE Computer-Aided Software Engineering

CORBA Common Object Request Broker Architecture

CTL Computational Tree Logic

EPC Event Process Chain

EPR Endpoint Reference

ESB Enterprise Service Bus

LTL Linear Temporal Logic

OASIS Organization for the Advancement of Structured Information Standards

OCL Object Constraint Language

QoS Quality of Service

SOA Service Oriented Architecture

UDDI Universal Description, Discovery and Integration

http://www.compas-ict.eu/�

FP7-215175 COMPAS D4.1v2.0


WfMC Workflow Management Coalition

WfMS Workflow Management Systems

WS Web Service

WSCI Web Service Choreography Interface

WSDL Web Services Description Language

XML Extensible Markup Language

XPath XML Path Language

XSD XML Schema Definition

XSLT Extensible Stylesheet Language Transformations

YAWL Yet Another Workflow Language

FP7-215175 COMPAS D4.1v2.0


2. State-of-the-art

2.1. Definition of criteria for reusability In the following sub-sections we present a set of criteria that support the classification and examination of the approaches that enable, foster and improve the reusability of processes and service compositions. The rationale for the selection of the criteria we propose is manifold. We wanted to account for the specifics of this field of research and technology. Thus, we have included criteria concerning the actual subject that is being reused, because in the field of processes and service compositions the artifacts that are reusable are not limited to processes. Furthermore we took the life cycle of processes into account and formulated criteria out of it in order to classify the approaches according to the phases in this life cycle. Research in literature [Jin03, KS97] also showed common techniques that are employed for allowing reuse, we have also considered this as criteria. Moreover we find it useful to investigate, in which domains an approach may be applied, what its requirements are, and which scenarios it covers.

2.1.1. Subject of reuse In the context of this deliverable the focus is set on processes and service compositions, thus this criteria group addresses which of the related artefacts are reused. This includes in general services and their implementation, policies, annotations and metadata, processes and parts thereof, interface descriptions, message exchange formats and other artefacts. Policies for example can on the one hand be used during the creation of a reusable artefact in order to describe its variants and capabilities, on the other hand those policies can also be reused themselves. This also applies to any kind of annotation or related metadata. Processes can be reused in a whole, as a template for a new process, as a sub-process with different levels of autonomy or by using parameterization.

2.1.2. Used techniques This criteria group sets the focus on the fundamental idea and the used technique behind the approach. The approaches that are discussed in the following sections differ in the techniques that are used for creating reusable artefacts. Typically, they include a certain kind of generalization and specialization for tailoring the artefact to the needs within a special usage context. We also discuss, where automation is being applied, although for some approaches the used techniques are just a textual documentation of how to create or use such an artefact. Techniques going beyond the mere abstraction and parameterization mentioned above include algorithms for certifying compatibility of reusable artefacts and analysis of their behaviour in a composition. Furthermore, we inspect the level of abstraction of the approaches that reach from code-reuse over business rules up to usage patterns. Finally we inspect whether and in which manner transformation techniques are applied.

2.1.3. Phase in process life cycle This set of criteria addresses the phase in the process life cycle in which the reuse actually takes place. In the context of processes some approaches may touch more than one phase, yet most of them can be found at design time. Design time refers to the modelling of processes and the implementation of services, and is also related to the verification of a composition.

FP7-215175 COMPAS D4.1v2.0


Some approaches for reuse touch the field of adaptability, such as parameterization and dynamic service binding or the extraction of Business Rules, those approaches are mostly settled in run time. The life cycle of a process does also include monitoring, where reuse can also take place. Although there are just few approaches that cover this phase we include it for completeness. Another criterion in this group could be seen as a criterion that is vertical to the phases, as it inspects the retrieval mechanism that is employed.

2.1.4. Application domain and coverage This criteria group indicates, whether the described approach is applicable to various scenarios and technologies or if it is only feasible for a restricted set. Some approach might for example require a special infrastructure like a repository or certain tools, other approaches are applicable to a larger set. We will discuss, what scenarios are covered by an approach and whether they are bound to a specific domain or not.

2.2. Approaches In this section, we review some of the approaches dealing with issues related to reusability. We identified a few categories of approaches. Each category focuses on specific issues (e.g., parameterization, declarativeness, constraint-based, etc.). Each category is illustrated by at least one approach. We selected an approach we believe it representative of its category. Many references are left out even if they are as relevant as the one used to illustrate the approach. The approaches discussed in the following are ordered alphabetically. Each approach is discussed according to the following features:

• Description: it summarizes the objectives of the approach.

• Example: when necessary, we give examples to illustrate the approach.

• Advantages / Disadvantages: we discuss the strength and weakness of the approach.

• Challenges: we identify challenges to accommodate other relevant issues for reusability.

• Technical difficulties: when possible, we mention the technical difficulties underlying the proposed approach.

• Area of application: we identify the application domains (e.g., monitoring, verification, etc.).

2.2.1. Ad-hoc Workflows / Case Handling In ad-hoc workflow, there is no predefined workflow model for the business process. The business process is built ad-hoc as it is enacted using distributed services (activities). Business rules, which capture invariant inter-service logic, are associated with the services and are used to determine the next activities to be performed on behalf of the business process.

FP7-215175 COMPAS D4.1v2.0


Description Traditionally, cases in workflows are handled according to a fixed definition of the tasks to be performed and their order. Tasks are characterized by a high frequency and a high level of standardization. The flow of cases can be monitored closely and the occurrence of bottlenecks and slack can be identified and acted upon. There are applications that support less structured cooperative work. Here the tasks within a case and their order are not fixed, but can be added and modified as the case proceeds within the organization. The added flexibility has its price, though, as it becomes harder to support and control the ongoing work. To summarize, ad-hoc workflows are about adding flexibility to traditional workflow Examples [VA97] discusses the term ad-hoc workflow for processes. Each case is derived from a template process that can be modified to meet specific needs. The templates do not state in detail how cases are to be handled, but allow a certain degree of flexibility. The paper focuses on how ad-hoc workflow, mobile-agents and service brokering participate synergistically in realizing the e-business processes. Figure 1 contains two subnets. Prospective customers enter the acquisition subnet (acq). They then either leave through the file transition or become customers upon entering the cons subnet. After leaving this subnet, the clients have a web site and guidelines that can be maintained (maint) for some time, until the case is closed.

Figure 1 An example of top level template [VA97]

Case-specific variations appear on the lower levels. Figure 2 gives the construction (cons) subnet template (A) with modifications (B, C). The template prescribes a guidelines creation phase, followed by guidelines maintenance and release, after which web pages are constructed, maintained and released. The modification B allows page construction to start after the initial guidelines creation to get a site on the web as soon as possible. C has a negotiation phase for the inclusion of material belonging to third parties before guidelines release.

FP7-215175 COMPAS D4.1v2.0


Figure 2 (cons) template and modifications [VA97]

[MHS00] proposed an architecture where ad-hoc workflows and mobile agent technologies can be integrated to enable e-business processes over loosely coupled web-based services. Advantages / Disadvantages The main advantage of ad-hoc workflow systems is that the business process can be built dynamically and flexibly. Another advantage is the ability of ad-hoc workflow to cope with dynamic changes in business rules and service definitions, implementations, and/or locations. The service providers taking part in the ad-hoc workflow are not required to be dedicated services. They could be cooperative services in an organization’s Intranet, or could be loosely coupled services. Challenges How to derive high level templates? Technical difficulties How to synthesise cases from templates?

Area of Application Business process design and monitoring.

FP7-215175 COMPAS D4.1v2.0


2.2.2. Approaches from Programming Component-based systems achieve flexibility by clearly separating the stable parts of systems (i.e. the components) from the specification of their composition. In order to realize the reuse of components effectively, it is required to measure the reusability of components. However, due to the black-box nature of components where the source code of these components is not available, it is difficult to use conventional metrics in component-based development as those metrics require analysis of source codes. Software programming is a hard design task, mainly due to the complexity involved in the process. This complexity is increasing to levels in which reuse of previous software designs is very useful to short cut the development time.

Example The main idea of software reuse is to use previous software components to create new software programs. Some authors investigated a way to build reusable components from operating systems. For example, [NEK93] describes a software re-engineering technique, called program segmentation which supports the recovery of reusable assets from old code. This technique consists of a focusing step, which helps the analyst to localize, understand, and combine functional pieces in large programs, and provides a factoring step, which extracts the focused functional pieces and packages them into independent reusable modules.

Advantages / Disadvantages The main advantage is re-engineering legacy systems. For example, legacy systems run on an outdated hardware platform and cannot be migrated easily to a new platform. But the system may contain critical business rules and other reusable assets that are not explicitly documented anywhere else. Thus, the recovery of reusable assets from old code can help in migrating the system to new platforms.

Challenges The main problem with the extraction of reusable components from program codes is the localization and combination of pieces into large components. This asks for advanced static analysis techniques.

Technical Difficulties How to abstract program codes so that static analysis techniques can be applied.

Area of Application Legacy systems.

2.2.3. Aspect-Oriented Programming Aspect-oriented programming (AOP) was introduced as a programming technique that addresses the problem of integrating cross-cutting concerns, e. g. logging, into applications. In [KLM+97] the authors stated that without this technique important design decisions “are scattered throughout the code, resulting in ‘tangled’ code that is excessively difficult to develop and maintain.” The properties, that these decisions address, are called aspects. The authors furthermore describe, that AOP “makes it possible to clearly express programs

FP7-215175 COMPAS D4.1v2.0


involving such aspects, including appropriate isolation, composition and reuse of the aspect code.”

Description First we want to inspect the general principles of AOP, before discussing its application in process engines. In [KLM+97] the term aspect is differentiated against the term component: While a component can be cleanly encapsulated in a generalized procedure (i.e. object, method, procedure, and API) an aspect cannot: “Aspects tend not to be units of the system’s functional decomposition, but rather to be properties that affect the performance or semantics of the components in systemic ways”. So-called aspect weavers process the component and the aspects, composing them properly to produce the desired total system operation. Depending on the specific implementation the aspect weaving can be performed at compile time (static) or run time (dynamic), the latter one being more powerful, but also more complex [Cha07].

The essential to the aspect weaving is the concept of join points, which are points in a program, where additional functionality can possibly be weaved in, like a method call etc. [CM04]. These points can be addressed in pointcuts that declare that additional functionality, called advice, should be integrated. The advice is a piece of code that is executed whenever a join point in the set, identified by the respective pointcut, is reached. [Cha07] describes, that the advice can be executed before, after, or instead of, the join points that are selected by that pointcut, however this described functionality is implementation dependant. Technically speaking an aspect is thus made up of pointcuts and advices. The join point model defines the set of points in the execution, which can be captured by the pointcut of an aspect-oriented language. Applied to process engines the join point model might be based on the execution of activities and transitions between them.

Examples The work presented in [HC05] makes use of the AOP technique for extending an open source BPEL process engine, yet not in order to support AOP on the level of processes. However, their work shows in a comprehendible way how the support for monitoring could be seen as a cross-cutting concern and is thus worth mentioning. In [Cha07] (see Listing 1) an example for a counting aspect in BPEL is presented. The approach uses XPath (see Appendix A.1) as pointcut language, BPEL code for advices, and run time weaving.

<aspect name="Counting">

<partnerLinks><partnerLink name="JavaExecWSLink" …/></partnerLinks>

<variables><variable name="invokeMethodRequest" …/></variables>

<pointcutandadvice type="after">

<pointcut name="Lufthansa Invocations">

//process//invoke[@portType ="LufthansaPT" and

@operation ="searchFlight"]

</pointcut>

<advice>

<sequence>

<assign>

FP7-215175 COMPAS D4.1v2.0


<copy> <from>increaseCounter</from>

<to variable="invokeMethodRequest" part="methodName"/>

</copy>…

</assign>

<invoke partnerLink="JavaExecWSLink" portType="JavaExecPT"

operation="invokeMethod"

inputVariable="invokeMethodRequest"/>

</sequence>

</advice>

</pointcutandadvice>

</aspect>

Listing 1 A counting aspect in BPEL [Cha07]

Advantages / Disadvantages AOP allows untangling concerns and thus providing for better flexibility and also improved reusability as the aspects that are weaved in represent additional functionality that is not necessarily required in any scenario. The authors of [CF04] state, that by employment of aspect weaving, processes can be customized to meet new requirements - features can be added such as debugging, execution monitoring. The other side of the coin is that programming mistakes or even intended changes of the component or an aspect might easily lead to unexpected behaviour of the total application. This requires strict programming guidelines that need to be carefully defined.

Challenges A major challenge in successfully implementing and applying AOP is to identify, for which requirements this approach is feasible, also referred to as “quantitative assessment of the utility of AOP” in [KLM+97]. Two examples mentioned in the description above are logging and monitoring, but what about compliance constraints, can these requirements be seen (and implemented) as cross-cutting concerns using AOP?

Technical Difficulties The flexibility in dynamic AOP comes along with increased difficulty of achieving type-safety and making verification almost impossible. Furthermore, debugging is becoming more complex, even more with respect to the complexity of debugging a SOA application, therefore special tooling support would be required. And after all, there is no complete open source implementation of an AOP-ready BPEL engine available.

Area of Application In [KLM+97] the identification of possible application areas is declared as an open issue: “Can we develop measures of which applications it will be more or less useful for?” So far there is no definitive answer to this question. Thus, whether AOP can be employed in order to weave in compliance concerns into processes, and in how far, would need to be investigated. However, we can conclude that this technique provides for improved reusability of both, the process models and the aspects, because of their untangling and the clear separation of concerns.

FP7-215175 COMPAS D4.1v2.0


2.2.4. Business Process Variants The authors of [LS06b] argue that it is often the (constrained) variance from best practice process templates (often also referred to as reference models, see 2.2.11), that “provide organizations with intellectual capital and competitive differentiation.” In [LS06b] process variants are described as “individually tailored process instances […], each of which represent the preferred work practice, but are also valid in terms of process constraints.” So from their point of view a variant is a process that complies with constraints defined in the process template, without requiring the same structure. In [HBR08] the main challenge in managing variants, also referred to as reference model configurations, is described as how to manage the relation from the reference model to the variants: “fundamental process changes (e.g. changes of legal regulations) often require the adjustment of all process variants derived from the same process.” In [ADG+05] it is even stated, that configurable process models should be the basis for reference modelling. In [Aal99] a family of variants of the same process is denoted as a generic process model, yet with the focus on dynamic change instead of reusability.

Description As already noted in the introduction, there is a direct relationship of process variants and reference models. Basically, process variants can be seen as the result of configuring certain reference models. The authors of the PESOA project [BBG+05] also refer to the term “process family engineering”, when discussing the methodological foundations for the management of variant-rich processes. The significant variability mechanisms related to modelling variant-rich business processes investigated in [BBG+05] are summarized in the following:

• Encapsulation of sub-processes: By defining an interface containing input and output of an activity, alternative implementations can be used in the variants.

• Parameterization: Attributes and values can be parameterized to support “optional, alternative, or range variation points”, depending on the specific case and domain.

• Inheritance: Inheritance allows modifying an “existing (default) sub-process by adding or removing elements regarding to specific rules. This allows for realizing alternative variation points.”

• Extension Points: “Extension points use a combination of encapsulation and null sub-processes to realize optional variation points.”

In other research on process variants, as for example in [HBR08], the configurations are defined by operations on the reference model, such as INSERT, DELETE, MOVE or MODIFY, using a certain set of options. It is essential to point out, that the described approaches were not applied to BPEL (see appendix A.1), the standard language for orchestrating Web Services.

Examples In [HBR08] several examples for this approach are brought up, for instance in the product creation, change management and release management in the automotive industry. In the following we discuss a different example presented in [HBR08], a product change request process. The reference process model is shown in Figure 3 (a). The process starts with a change request with a subsequent collection of comments coming from departments that

FP7-215175 COMPAS D4.1v2.0


might be affected by the request. Afterward the comments are compiled to a single document by the project leader. Then the decision board either approves or rejects the requested change. If and only if the change is approved, the implementation of the change is executed by the development department. The process completes by documenting the change request.

Figure 3 Variants of a standardized product change process [HBR08]

The first variant adds additional quality assurance, as shown in Figure 3 (b). For shortening the overall process duration the second variant Figure 3 (c) adds the implementation activity in parallel to the collection of comments. The former implementation step is replaced in this variant by an activity that takes care of undoing the implementation in case of rejection by the decision board. Finally the third variant shown in Figure 3 (d) constitutes a combination of the previous variants, including both quality assurance and process duration speedup.

Advantages / Disadvantages A significant benefit of this approach is that it provides for straightforward reusability of reference models by making the reference model configurable and thus more easily adaptable to specific requirements of the user. Yet the increased effort that is required for creating a configurable reference model may not be neglected, also special tooling is necessary for the management of configurations, their validation and also the management of changes.

Challenges This approach contains several challenges, namely how to keep the relation of a variant to the reference model alive, which includes how to propagate changes from the reference model to the variant. Another challenge for when this approach shall be applied in practice is to define guidelines and gain experience on which parts of a process should be configurable in order to be flexible enough with respect to finding a balance between reusability, flexibility and usability.

FP7-215175 COMPAS D4.1v2.0


Technical Difficulties The technical difficulties in this approach are to provide a clear syntax and semantics for the configurations of processes, as for example proposed in [RRA+05] for EPC. Another technical issue is how to manage model configurability and configurations in terms of data structures and an according tool support. Although, there is some work related to this issue, e. g. the one proposed in [HBR08], there are only few approaches dealing with variant management that could be employed. In [BBG+05] the technical difficulty of providing a more tightly coupling of a variant model and it reference model is investigated. Finally, the authors also recognize that there is currently no support for (semi-)automatically combining existing variants in order to create a new one.

Area of Application The approach is basically anywhere applicable, where companies are dealing with several processes with a significant similarity or to put it in others words, are having several processes that belong to a process family.

2.2.5. Constraint-Based Workflows When dealing with business processes, there is an objective of controlling processes and avoiding incorrect or undesirable situations. In general, users want flexible processes that do not constrain their actions. The approaches of this category make use of constraint-based models to support ad-hoc and dynamic changes.

Description Traditional workflow languages require the designer to over-specify issues related to processes. For example, one can model all kinds of choices, but it is difficult or even impossible to state that two activities should never occur together. To do that, the designer has to provide a strategy to accommodate this requirement. This approach is called imperative. In contrast, a declarative approach brings more flexibility in workflow management. One of the paradigms that allow providing a declarative approach is that of constraint-based models.

Examples [PSS+07] presented an approach dealing with changes in constraint-based workflow models. A constraint-based model is used to restrict the behaviour of workflows. The model allows to represent activities and constraints on activities. It also allows to specify whether constraints are optional or mandatory. Traces of all running instances of the corresponding process model are evaluated and, if necessary, the instances are transferred to the new model. Figure 4 (taken from [PSS+07]) displays an example. Figure 4 (a) shows four instances of which i1, i2, i3 are instances of constraint model cm1, i4 is an instance of cm4. Constraint model cm2 has no instances and cm3 is not part of the constraint workflow. There is a mapping from model identifiers (CMid) to constraint models in UCM. If, for example, we would like to perform a change on instance i3 and we want this instance to use constraint model cm2 instead of cm1 (Figure 4 (b)), then we proceed as follows: if the trace of instance i3 does not violate the constraints of the new model cm2, then the instance i3 is remapped to identifier 2.

To summarize, the approach supports both ad-hoc and evolutionary changes. Ad-hoc changes are needed to handle an exceptional situation. Evolutionary changes occur when there is a change in the process itself.

FP7-215175 COMPAS D4.1v2.0


Figure 4 Changes for constraint workflows [PSS+07]

[SOS04] investigated a set of constraints for flexible workflow specification. In this case, the specification consists of: (1) identifiable workflow activities and control dependencies that form the core process, and (2) a special workflow activity called the build activity and consisting of:

• set of workflow fragments where a fragment consists of a single activity or a sub-process,

• set of constraints allowing to concretize the special activity with a valid composition of fragments

Two main classes of constraints are proposed: structural class and containment class.

• The constraints of the structured class impose restrictions on how fragments can be composed in the templates. Three constraint types are provided: serial, order and fork.

• The constraints of the containment class identify the conditions under which fragments can or cannot be contained in the resulting templates. This is similar to the usage of integrity constraints in databases.

Given those constraints, the paper describes a procedure for achieving a minimal and conflict-free specification.

Advantages / Disadvantages Constraints allow a declarative style of modelling ad-hoc and evolutionary changes and more flexibility. Doing this way, we avoid over-specification used in traditional procedural styles. The use of constraints also allows avoiding unnecessary changes.

FP7-215175 COMPAS D4.1v2.0


Challenges Challenging issues are:

• How to deal with heterogeneous constraints?

• How to deal with workflows which are partly procedural and partly declarative?

• How to accommodate, in a single framework, static (pre-defined) and dynamic business process requirements?

Technical difficulties One of the main difficulties is how to allow individual instances to determine their own processes. In other words, it is difficult to perform semantic matching of two models (instances and models) based on underlying sets of constraints. Given an instance and a model, how to relate the instance to the model?

Area of Application Workflows design and deployment

2.2.6. Declarative Processes In this section, we review some approaches that complement imperative business process specifications with declarative specifications. A declarative specification enables designers to describe the actions that a business process needs to contain, but not their sequence. Description An important issue is to have business processes that comply with business strategy. This alignment can be made easier if an adequate level of abstraction for business process representation is used. A business process can be defined as a set of partially ordered activities aimed at accomplishing a well-defined goal. A business process may be subjected to many conditions in which this order cannot be identified at design time. The exact sequence of activities is sometimes impossible to predict. Modelling techniques, such as Business Process Modeling Notation (BPMN), encourage modelling details at an early stage. As a result, in many situations, an organization will commit to one of the execution paths. If the number of exceptions is important, one can face serious problems. As a consequence, the alignment between the strategy of the organization and its detailed business processes is not apparent. Also, the flexibility of the processes themselves is limited because they become difficult to manage and change. Examples [PA06] investigated a language, called ConDec, for modelling and enacting dynamic business processes. ConDec rests on temporal logic. It can be used to build a wide range of models: (1) ‘strict’ models that define the process in detail, and (2) ‘relaxed’ models that state only what should be done, without specifying how to do it. A ConDec model consists of a number of tasks, which are the possible tasks that can be executed. Then, relations between tasks can be defined. They are considered as constraints. In the case of ConDec, a constraint represents a policy (or a business rule). At any time during the execution of the model, each constraint has a boolean value ‘true’ or ‘false’, and this value can change during the execution. If a

FP7-215175 COMPAS D4.1v2.0


constraint has the value ‘true’, the referring policy is fulfilled and vice versa – if a constraint has the value ‘false’, the policy is violated. Figure 5 shows an example consisting of three tasks: A, B, and C. Tasks A and B are annotated with a constraint specifying the number of times the task should be executed. The arc between A and B is a constraint stating that task B is executed after task A, but not necessarily as the next task after A. This constraint allows that some other tasks are executed after task A and before task B.

Figure 5 A simple example of a ConDec model [PA06]

[KEF00] proposes a rule-based methodology to provide a uniform modelling approach at different abstraction levels. This approach requires transforming a rule-based description of a business process in one or several refinement steps into a rule-based workflow specification. The business rule approach can serve as an integration platform for different process modelling techniques and different target systems that implement the workflow or parts of them. To represent business rules the authors use the ECA1

Figure 6

notation and the selection construct; the resulting constructs are enhanced with different constructs for representing static components of business processes, i.e., organizational units, roles, actors, and entity relationship-models.

shows an example of rule which is a part of a process of a special health insurance claim (SHIC) at the context level.

Figure 6 Business rule at context level [KEF00]

Advantages / Disadvantages A declarative approach avoids the specification of the control flow between the actions leading to process design which is independent from the constraints imposed by an environment in which this process will be implemented. The control flow (specific to a given environment) is later modelled in an imperative specification. A declarative approach includes verification issues. Flexibility may also be enhanced because alternative paths are modelled as separate business processes conforming to an overall process. 1 Which is based on events, conditions, actions.

FP7-215175 COMPAS D4.1v2.0


Challenges Checking the conformance of the imperative and the declarative specifications. It may happen that in some cases, for some services the behaviour is specified by means of imperative languages and for others by means of declarative languages. The problem is then how to check whether the two services can be composed?

Technical difficulties Checking the completeness of the constraints. When constraints are used to constrain services independently of the environment, it becomes difficult to check whether the set of used constraints is complete or not. By complete we main the possibility of capturing all the situations.

Area of Application Business process design.

2.2.7. Extending BPEL for Runtime Adaptability In [KHC+05] an approach is presented for supporting adaptability of Web Service Flows (WS-flows) on a per-instance basis in order to improve process flexibility and reusability by dynamic binding of Web Services (WS) to WS-flow instances at run time. WS-flows are orchestrated Web Services implemented using a process-based approach. Similar to the traditional workflows WS-flows definitions specify collections of tasks executed by the participants in a process, but unlike the traditional workflows, the WS-flows involve only WS as participants. BPEL [OASIS07] is the de facto standard for specifying WS-flows, but does not support adaptability of WS-flows at run time. BPEL supports exchanging port by allowing assignment of endpoint references from messages, but this assignment must be foreseen at process modelling [WCL+05].

Description

In [ACD+03] BPEL was extended for supporting the so-called find and bind mechanism. Hence, BPEL was enhance to support runtime adaptability, and thus, increasing reusability, flexibility and enabling the selection of specific ports at runtime (in contrast to the static binding supported by pure BPEL). A new extension element to the BPEL language version 1.1 (BPEL4WS) [ACD+03], representing a mechanism called “find and bind”, has been introduced. The procedure behind this mechanism is the look up, selection and binding of services compliant with a port type defined in an activity in a WS-flow definition. The mechanism has been proposed before, but has not been specified or represented by language construct in BPEL. The three main steps comprised by the “find and bind” mechanism are as follows [KHC+05]:

1. Find a list of all available WSs compliant with the port type specified in an activity of a process;

2. Select a port from that list according to user defined selection criteria (QoS, semantics);

3. Bind the activity of the process instance to the selected port. This port is the one that is going to perform a task on behalf of the process instance under consideration.

FP7-215175 COMPAS D4.1v2.0


For illustration these before mentioned steps are shown in Figure 7.

Figure 7 “Find and bind” mechanism [KHC+05]

The <find_bind> construct has been chosen to represent the mechanism in terms of a common process definition language and to make it explicit in a unified WS-flow meta-model. So the process developers and users do not have to care how the find and bind mechanism is performed. They only should care and know about the selection criteria and specify them within the <find_bind> construct. This extension element is designed to express the requirements towards a WS port in terms of selection policies. Therefore users can specify default values of selection criteria that are to be used at runtime as a substitute of those criteria given at deployment time of the process or as their extension and refinement.

There are three activities standing in BPEL version 1.1 for interaction with Web Services; <invoke>, <receive> and <reply>. These are exactly the elements to be extended with the <find_bind> extension element. Note that this additional element is included into the set of standard elements of the activity.

Examples Looking at Listing 2 you see, that the find and bind mechanism is mapped to a separate extension element of an interaction activity, including a “selection_policy” attribute. <process name=”ConvertCurrencyBP”>...

<invoke

name=”ConversionRequest”

partnerLink=”converter”

portType=”CurrencyConvService”

operation=”usd2eur”

inputVariable=”C_and_Rate”

outputVariable=”result”>

<find_bind Selection_policy=”selection_policy_ID”/>

</invoke>...

FP7-215175 COMPAS D4.1v2.0


</process>

Listing 2 An example representation of the <find_bind> extension in BPEL [KHC+05]

The value of the <selection_policy> attribute can either directly specify the selection policy as a list of criteria or it can be a name of a selection policy. Thus, this name uniquely identifies a selection policy and can additionally be used to reference policies stored in a separate infrastructure component, e.g. in a repository.

Advantages / Disadvantages The <find_bind> element contains no implementation-specific features – no reference to an implementation language, platform or discovery component to be used for look up. In Figure 7 an UDDI [OASIS05] registry is shown , but in general, any other discovery component supported in a service environment would do. While users are allowed to prescribe default selection policies, they depend on the availability of appropriate tools for modifying the selection criteria at run time.

Challenges An important challenge of the approach was to gain the flexibility and reusability while simplicity is preserved. The detection of a failure of a WS instance in the case of asynchronous communication means that the previous actions must be compensated for and (status) data resent to the newly selected WS instance. Failure handling and compensation in an asynchronous interaction mode between processes and participants concerning the presented approach is the most important part of future work.

Technical Difficulties The infrastructure must incorporate a module or component to handle policy match-making and WS selection. The “find” step of the mechanism requires calls to a discovery component to get the list of WS instances.

Area of Application The area of application of the approach is neither explicitly stated nor restricted in. The introduction of the explicit <find_bind> language element allowing deployment-independent service selection at runtime on a per instance basis and increasing reuse and flexibility of processes is independent from the application area and thus applicable in every domain of business processes.

2.2.8. Extraction of Business Rules A business rule can be used in many ways. In this case the following questions come in mind:

• If a computer is used to apply business rules the way business people do, is it also able to re-use rules, the way business people do?

• If a computer is used to model the business and its rules, is it also able to re-use these models?

FP7-215175 COMPAS D4.1v2.0


This section is concerned by this issue. We will review some approaches related to business rules extraction and reuse. Description Business domains are increasing in complexity and it will be helpful to explicitly capture business processes and policies as business rules. A business rule could be considered as a specification that constrains some aspect of the business. Business rules tend to evolve more frequently than the core application functionality, and hence it will be interesting to decouple them from the rest of the application. However, in order to achieve configurable and reusable business rules, it will be necessary to separate the code that connects the business rules with the core application. In this case, business architecture can be considered as a set of resources that interact under defined rules through a set of well defined processes to achieve a desired goal. These rules are called business rules. Examples [HF05] proposes an approach for developing business architectures and their business rules. The proposed approach allows for both managing and reusing business rules. The authors have proposed an approach that views the business architecture as a hierarchical structure. They adopted software stability approach [FA01] to design their approach. Doing this way, when a business is changed or updated, the impact could be easily identified: change structure only, change business rules only, and change business rules and objects. [Cha06] investigates a technique for extracting business rules from legacy systems into components. The authors focus on business rules extraction and transformation of the extracted code corresponding to a business rule into a Common Object Request Broker Architecture (CORBA) component. Traditional CORBA components yield high coupling between the components and the CORBA ORB. The proposed approach generates CORBA components with low coupling so the components can be reused across different applications. In addition, the components built in different programming languages can run on different platforms and communicate with each other across different network systems seamlessly in a heterogeneous object-oriented computing environment.

FP7-215175 COMPAS D4.1v2.0


Advantages / Disadvantages By extracting business rules and representing them in a separate component, it becomes easy:

• To manage their evolution within a business architecture • To reuse of business rules since they are completely independent of a given

implementation. Challenges

• How to synthesize business rules from data? • How to combine business rules (capturing relations between business rules)? • How to transform business rules? • How to characterize quality of extracted business rules?

Technical difficulties How to deal with heterogeneous formats for extracting business rules, and how to integrate this approach in a service-oriented application, as discussed in [RD05].

Area of Application Business applications and business process design.

2.2.9. Goal-Orientation The trend toward more flexible ways of working, and shorter organizational reaction times are constraints that business processes should accommodate. Current approaches for Business Process Management (BPM) do not address those issues in a satisfactory way. The evolution of business processes management in order to take into account those constraints led to goal-oriented autonomic BPM. Description Using a goal-oriented approach allows to separate what the desired system behaviour is devoted to, from the possible ways to perform such behaviour. The expected result is described by achievement conditions to make true and as maintenance invariants whose violation must be avoided: achievement goal and maintenance goal, respectively. The possible ways to obtain a result are represented by plans: process graphs decorated with the conditions where they are applicable and the results they obtain when successful. Example [Whi07] proposed a goal-oriented approach. The phases to perform goal-oriented business process modelling are: (1) expressing the intentions and requirements of the process through goals and sub-goals, connected as necessary, (2) organizing processes into plans by attaching them the statement of what they require and what they achieve, and grouping them when they achieve the same goals in different ways, and (3) decomposing processes into tasks by specifying their aggregation structure. Once these steps are considered, business processes in an enterprise can be modelled as a set of related goals to be achieved or maintained. One or many plans are attached to these goals,

FP7-215175 COMPAS D4.1v2.0


and each plan has its own feasibility requirements. Attributes such as expected completion time or resource cost can also be associated to plans. Advantages / Disadvantages Adopting goal-oriented BPM could lead to several benefits, such as:

• Business user empowerment. Users can work at the goal level, expressing what is to be achieved as the defining core of the business process. The details are left out.

• Increased process understandability. The goal level alone already shows what the business process is supposed to achieve (main goal) and which are the intermediate goals.

• Improved process tracking and monitoring. The goal level allows tracking of business process evolution independently of operational details.

• Lowered maintenance costs. The use of declarative specification reduces the dependence on details and makes the business process models, and their implementation, both more stable and easier to change.

Challenges How to accommodate in a single environment both methodological and technological aspects Technical difficulties How to handle changes given the different levels of abstraction.

Area of Application Business process design and monitoring.

2.2.10. Parameterization of Web Service Flows

The reusability and flexibility of Web Service flows (WS-flows) are restricted by hard-coding the portType and operation in the process definition. The approach described in this section improves flexibility of WS-flows, while reusability is enhanced, through parameterization and substitution [KLB05, KLN+06]. By extending the meta-model for enabling run time evaluation of parameter values, the dynamic determination of potential partner service types at run time is possible, instead of defining them statically during process modelling. Moreover the meta-model extension enables changes of portType values at run time.

Description The approach is based on the concept of parameterized processes aiming at increasing the degree of freedom of WS-flows by representing portTypes and operations employing parameters and defining run time parameter substitution policies. This requires the computation and determination of parameter values at run time. The evaluation of parameter values is performed on a per instance basis by using an algorithm that selects a Web Service (WS) type out of a set of WS types that meet a set of imposed requirements. When a parameter value is calculated it is substituted in the activity, which then initiates the interaction with the WS. This is based on the assumption, that the messages constrain the

FP7-215175 COMPAS D4.1v2.0


choice of appropriate portType and operation values. Every parameterized activity must have the ability to resolve the parameter values, because alternatively the current execution of the concrete process instance will be blocked and waiting for the intervention of the administrator for resolving unknown values or engine faults manually.

The following four alternative strategies are specified in [KLB05] for determining the value of a portType or operation parameter in an interaction activity:

• Static provision of portTypes and operations: Here concrete parameter values are specified, which can be supplied at process modelling time or upon process deployment.

• Prompt (the user) strategy: This strategy allows users to provide a process instance with parameter values. Prompts can be demanded from the user at the time of process instantiation for all parameterized activities, or may be issued to the user every time the execution of a process instance reaches an activity with parameterized service type.

• Query: The query strategy employs in-line or referenced query definitions, which are to be executed against a Web Service discovery component. Queries contain service type selection criteria including the messages it must accept and return, semantics, and Quality of Services. The result of the query against the Web Service discovery component is ranked, non-empty list of compliant portTypes/operations. One of these service types in the result list is chosen and employed in the concrete WS-flow instance.

• From variable: The procedure of from variable strategy is that the concrete value for the parameter, specifying the concrete portType/operation, is to be copied from a variable defined in the process. The value of this variable may be set by assigning it after receiving the value from a partner in a previous message exchange.

Besides the different strategies, mentioned in the classification above may also be combined, meaning, that for example the query definitions, which are to be executed against a Web Service discovery component, can be provided by the user employing prompt strategy.

In the following the parameterization of processes in the Business Process Execution Language (BPEL) is explained. The current BPEL specification [OASIS07] does neither cover portTypes nor operation parameters. The portTypes and operations of orchestrated Web Services are hard coded in the activities defining interactions with Web Services within the process. PortTypes and operations are specified by activity attribute values of the following three types of interaction activities in BPEL, namely <invoke>, <receive> and <reply> activities. All portTypes and operations in BPEL definitions are strings, because BPEL definitions are representations of a WS-flow model in text. Therefore the substitution of any attribute value in the WS-flow model by a String is possible.

The BPEL meta-model is extended to enable the required parameter value evaluation at run time. Concretely an <evaluate> extension to the standard element section of the <invoke> activity is defined. This new introduced meta-model element enables the mechanism for evaluating and computing parameter values at run time. In Listing 3 an example for the code of an <invoke> activity elements section, containing an <evaluate> extension is shown.

<process name=”Process_name”>...

<invoke name=”activity” partnerLink=”partnerLink” portType=”portType”

FP7-215175 COMPAS D4.1v2.0


operation=”operation” inputVariable=”...” outputVariable=”...”>

<evaluate activated=”yes|no” changeType=”static|

portType/operation|query|fromVariable” substitute=”value”/>

</invoke>...

</process>

Listing 3 An example representation of the <evaluate> extension in BPEL [KLN+06]

The attribute of the <evaluate> element and their meaning are as follows [KLB05]:

• activated: has the values “yes” or “no” and states whether the evaluation is enabled; “yes” means that the calculation has to be performed

• changeType: specifies the evaluation strategy

• substitute: used for parsing input/output parameter values for strategy computation mechanism

An overview of the mapping of evaluation strategies on BPEL is given in Table 1.

Strategy activated changeType substitute Static “no” Any alternative Substitute value for another

alternative “yes” “static” Concrete portType and operation

Prompt “yes” “portType / operation” portType, operation names provided by user

Query “yes” “query” Query identifier / In-line query (string)

From variable “yes” “fromVariable” Expression pointing to variable containing parameter values

Table 1 Mapping the evaluation strategies to BPEL constructs – an overview [KLN+06]

Example On the basis of the following example the difference between a State-of-the-art WS-flow and a parameterized process and its instances is pointed out. In Figure 8 a process model with port types of two suppliers of hard disk drives (HDD) is shown. The portTypes of the suppliers are fixed, that means the process modeller has decided at modelling time, which providers can be invoked alternatively at execution time of the process instances. So the consideration of providers, that could possibly exposed as Web Services at a later point in time is impossible. The involvement of other providers requires modification of the process model and redeployment. This is not efficient for long running processes, so the solution is to postpone the determination of the type of participants till run time.

FP7-215175 COMPAS D4.1v2.0


Figure 8 State-of-the-art WS-flow [KLB05]

A parameterized WS-flow is shown in Figure 9. Contrary to the example shown in Figure 8 the portTypes and operation names of the two alternative HDD suppliers, namely WS_pT1 and WS_pT2, are substituted by the parameter WS_pT=X. So the parameterized process instances at execution time are not only able to comprise the service types of the example in Figure 8, but also involve other service types, e.g. WS_pT-N, actually if they have been unknown at process modelling time.

Figure 9 Parameterized process and its instances [KLB05]

Advantages / Disadvantages Reflecting of alternative portTypes can also be achieved by modelling alternative control flow paths during process modelling, but contrary to the approach presented in this section this increases the complexity of process models extensively. Besides the presented approach

FP7-215175 COMPAS D4.1v2.0


avoids the fact that the modeller should know during modelling which concrete providers exist at execution time of the process. In long running processes this procedure would be inefficient, because this decision has to be postponed until the execution of every process instance, so that the process is able to consider services, which are unknown at modelling time of the process. Another disadvantage of the approach is the assumption regarding high availability of alternative services.

Challenges Missing semantic description standard and incomplete Quality of Services (QoS) model have an effect on the search and discovery of Web Service types and make the implementation of an adequate realisation and application of the approach presented in this section difficult. Compensation and fault handling in parameterized processes are one of the most important challenges, because the fault and compensation handlers can not be configured and customized completely at modelling time without knowing all the faults that can occur during process execution time, because the set of orchestrated Web Services possibly involved in the process instance in unclear. Moreover monitoring and mining of parameterized processes most important for retracing the actual execution of a parameterized process instance during and after execution time.

Technical Difficulties Parameterized activities enable both the modelling of synchronous and asynchronous communication modes, but the asynchronous communication mode holds difficulties concerning expressing guaranteed delivery of functionality on behalf of the partner [KLB05].

Area of Application The area of application of the approach is neither explicitly stated in [KLB05], nor in [KLN+06]. The increasing of degree of freedom of WS-flows and the improvement of flexibility and reusability by employing parameterized processes is independent from the application area.

2.2.11. Reference Models The term Reference Model, in present often labelled as “best practice” as depicted in [PA05], has in the area of process engineering already been coined in the early 90s. In [Sch94] to name one example, the author used the term to denote an architecture that has been proven to solve problems of a certain category. The Workflow Management Coalition (WfMC), an organization that defines standards for workflow management systems, has defined a Workflow Reference Model [WFMC95] that specifies a high-level architecture and a set of interfaces for supporting the construction of specific models. A recent project that aims at creating reference architecture for service based systems is NEXOF-RA [NEXOF08]. All those works have more or less the common understanding, that a reference model can be seen as a starting point for the development of specific models and implementations, that it represents a category of applications and that the model needs to be proven in practice. This does also apply to the specialization of the term into business process reference models.

Description In [Tho05] a brief review of the history and the formation of the term are presented. The most important findings are that a reference model is basically a recommendation, a set of artefacts

FP7-215175 COMPAS D4.1v2.0


that represent trustworthy information concerning a certain category of problems. This recommendation is based on whether the model has proven in practice or not. It is thus of fundamental importance to include the users in the development of reference models, “the developer’s assertion that he has constructed a universally valid and recommendable model remains meaningless for the time being”, unless there is no consensus between the developer and the user. In [FLZ05], it is summarized that there is no prescribed size that a reference model should have, thus every model that may support the development of other models can be seen in this sense as a reference model, independent of the number of diagrams and views that are contained therein. For the management of reference models the annotation with metadata and their storage and retrieval using a repository is feasible. According to [FLZ05], such repositories in the context of reference models are typically called “reference model catalogs”, for example in [TS06] feasible tooling support for this is shown. In [FLZ05] also a set of criteria (see Figure 10) for describing and classifying process reference models is introduced that is helpful for clarification.

Reference Model

PK No

Name Related Literature

General Characterization

Origin Responsibility for Modeling Access Tool Support

Construction

Domain Modeling Language(s) Modeling Framework Size Construction Method Evaluation

Application

Application Method(s) Reuse and Cusomization Use Case(s)

Figure 10 Criteria for describing process reference models [FLZ05]

Examples Various examples are presented in [FLZ05], yet with regard to the limited space and the focus of this deliverable we will briefly inspect an example related to business processes. According to [KKR06], the business process reference models usually cover the whole range of solution components such as process models, business rules, data models and service models. They capture processes and data at an abstract level and provide reusable and high-quality content. The example presented in [KKR06] is the improvement of a claim handling process by using a process reference model for claim handling. The authors distinguish between a revolutionary approach, in which the reference model is taken as the initial “TO-BE” model that is iteratively customized by integrating parts of the “AS-IS” model, and a conservative approach, which is summarized in the following. The approach basically consists of two main steps for improving a given process using a pre-selected process reference model. In the first step the AS-IS model and the reference model are compared, optionally preceded by a process configuration step as described in [ADG+05]. This includes the detection of similarities and differences, with regard to tasks, sub-processes and their organization. The second step is to derive a TO-BE model from this comparison by iteratively improving and

FP7-215175 COMPAS D4.1v2.0


refactoring, as described in [KKR06]: “Task contents are adapted, additional tasks and sub-processes are introduced or removed, the hierarchical structure is reorganized and the control flow is adjusted.”

Advantages / Disadvantages The primary advantage in contrast to other approaches presented in this deliverable is that it is not bound to a specific technology and can thus be applied to various areas of application. An advantage and also the main drawback is however that there is no common standard or format that has to be used to describe a reference model. Thus the people and the guidelines they applied to the development of the reference models are the linchpin of the quality and effective reusability.

Challenges In [KKR06] the authors state that process merging is one of the most challenging techniques, in order to get the most out of business process reference models. The computer-aided comparison of an AS-IS model with a reference model and the derivation of an improved TO-BE model out of this comparison are also challenging objectives. The authors also point out, that the tracking of changes during the refactoring and also the creation of migration plan with corresponding tool support needs to be elaborated.

Technical Difficulties Many technical difficulties arise when this approach is applied in the area of service compositions and processes and hence its application in BPEL. As mentioned in [KKR06], it is difficult to merge different process models. Given the complex semantics of BPEL, this is a difficulty of its own. Another one is the relation of this approach and the service implementation in terms of granularity and functionality that one single service provides. If a company does only run five services, then also the resulting reference models are impacted by this circumstance. One last difficulty, which is of less technical nature, is what exactly a reference model for a certain category should contain in order to be “just right”, which languages should be used and which guidelines need to be followed for the best result, i.e. efficient reuse.

Area of Application The approach of using reference models can basically be applied in any area touching business, for example in [ADG+05] the application of configurable reference models in form of Event-driven Process Chains (EPC) on basis of the SAP reference model is discussed. With respect to the effort that is necessary in order to obtain a high-quality reference model and the difficulties in adapting existing models with such reference models, the area of application seems to be limited, though. Yet the decision whether a certain process, choreography or even beyond is feasible for the creation of a reference model, requires again domain-specific knowledge and user experience.

2.2.12. Sub-Processes The extension to WS-BPEL [OASIS07] namely BPEL-SPE outlined in [KKL+07] allows the definition of sub-processes, which can be reused within the same or across multiple WS-BPEL processes. The design of large and complex business processes requires a mechanism

FP7-215175 COMPAS D4.1v2.0


to support modularization in interoperable manner for increasing reusability at design and runtime of business processes.

Description First of all we want to clarify and state an essential problem regarding business processes in WS-BPEL and sub-processes. WS-BPEL 2.0 [OASIS07] defines the aggregation of existing Web Services into new Web Services and consequently a model for services compositions. WS-BPEL does not cover the explicit definition of sub-processes, which can be invoked from within the business process, in which it is defined, or from another business process. The intended purpose for employment of sub-processes in practise is to modularize large and complex business processes and to increase the reuse of process functionality. Therefore, concerning their lifecycle sub-processes are generally tightly coupled to the invoking parent process. The only way to imitate similar behaviour in WS-BPEL is by defining a complete business process as an independent service and invoking it via an <invoke> activity. Notwithstanding the <invoke> activity of the parent process will be interrupted and terminated, WS-BPEL does not support the propagation of the termination to the invoked Web Service (sub-process).

For usability as a sub-process, a process have to comply with a few restrictions, so in the following the features required to provide sub-process capabilities are described.

A sub-process is an artefact of WS-BPEL code that can be reused within a process or across multiple processes. Besides it may be a long-running process, which includes interactions with other partners. The interaction of a sub-process with its parent process is generally limited to the initiating request message and the final reply message. A sub-process can be defined either locally within another WS-BPEL process and reused only within that process or as a WS-BPEL process and reused across other WS-BPEL processes.

Sub-processes are executed in the context in which they are defined, meaning that a sub-process can access variables from the scope where it is defined. The relation between a sub-process and its parent process extends on the error handling model and the compensation model introduces in WS-BPEL, for details see [OASIS07, KKL+07].

In BPEL-SPE two different types of sub-processes are distinguished, standalone sub-processes and inline sub-processes.

A standalone sub-process is defined as WS-BPEL process implementing exactly one activity. From the calling process’ perspective the sub-process is like an operation of a service that consumes a message and that may return a message as response.

Inline sub-processes are defined as part of the definition of another process either within the process scope or a nested scope.

Activities of an inline sub-process have access to all variables, correlation sets and partner links defined in scopes enclosing the sub-process definition.

An inline sub-process can not be instantiated as a standalone process, so it can not be a business process on its own. Inline sub-processes are typically not defined via a complete WS-BPEL process model, thus they may omit certain constructs otherwise being mandatory for a correct standalone process, e.g. own variables, own partner links, or without an initial receive activity.

Examples

FP7-215175 COMPAS D4.1v2.0


BPEL-SPE supports two different mechanisms by which a sub-process can return a response either via a <reply> corresponding to the starting <receive> activity see Figure 11 or via a one-way <invoke> that is logically related to the starting <receive> activity see Figure 12. In Figure 11 the parent process employs a WSDL request-response operation provided by the sub-process. The sub-process consumes the input message via its starting <receive> activity and returns the response message via the corresponding <reply> activity. The parent process does not necessarily have to provide a port type in the corresponding myRole in the partner link, because the sub-process does not further interact with the parent process.

Figure 11 Invocation of a sub-process via receive-reply pattern [KKL+07]

In Figure 12 the parent process includes a partner link where the associated partner role’s port type contains the operation corresponding to the initial <receive> activity of the sub-process. The myRole of the partner link contained within the parent process references a port type, which contains the operation to be employed by the sub-process to return the response message.

Figure 12 Invocation of a sub-process via receive-invoke pattern [KKL+07]

A new activity type for calling sub-processes is introduced in BPEL-SPE namely the <call> activity. This activity specifies its implementation by referring to the sub-process to call. For local sub-processes, that are sub-processes managed by the same infrastructure as the parent

FP7-215175 COMPAS D4.1v2.0


process, including inline sub-processes, the reference can be done via the qualified name of the sub-process. An example is shown in Listing 4. [call xmlns:s="http://stuff-is-us.com"

process="s:myProcess"

inputVariable="var1"/]

Listing 4 Call activity in pseudo-syntax, without output and faults [KKL+07]

Advantages / Disadvantages Employing sub-processes in the area of WS-BPEL enables modularization of large and complex processes and increases reusability. In the case the logical request-response operation of a sub-processes provided as two one-way operations, returning application faults is not possible, because the BPEL-SPE extension is based on WSDL 1.1 [CCM+01]. The WSDL 1.1 model does not support the specification of fault messages on one way operations or notification operations. Moreover a language specification, which defines the precise syntax and semantics of BPEL-SPE is not available right now but its following is announced. Challenges The goals and challenges concerning the employment of sub-processes in the area of business processes in WS-BPEL are as follows [KKL+07]:

• Allow for the invocation of a business process as a sub-process of another business process, such that its lifecycle is tightly coupled to the lifecycle of the parent process.

• Allow for the definition of a business process within the context of another business process, so it can be used (and reused) within that other process

• Allow a sub-process defined within the context of another business process to access data from its parent process.

• Allow for the invocation of sub-processes across BPEL engines so that a process running on one BPEL engine can invoke a sub-process on another BPEL engine.

Technical difficulties There are two important difficulties when hosting the parent process and the sub-process on different process engines and employing the receive-invoke pattern shown in Figure 12. Please note the process engine hosting the parent process need to be informed which operation to use to receive the response message. Therefore the <call> activity employed to call a sub-process requires the specification of the corresponding port type and operation in the myRole of the partner link wiring the parent process and the sub-process. These are completely new to BPEL, because WS-BPEL [OASIS07] only supports a single port type and operation in activities communication with the outside.

For the parent process the port type of the partner link that corresponds to the sub-process can be bound to the associated service endpoint at deployment time of the parent process, but this can not be done for sub-processes in the same manner. A sub-process may be called by many different parent processes with possibly different endpoints to which the sub-process must return the response message. Thus, the endpoint of the concrete parent process must be made known to the sub-process engine hosting the sub-process at the time the response message is sent back.

http://stuff-is-us.com/�

FP7-215175 COMPAS D4.1v2.0


Area of Application The area of application of the approach is neither explicitly stated nor restricted. The modularization of large and complex business processes and increasing of reuse of processes by employing sub-processes is independent from the application area and thus applicable in every domain of business processes.

2.2.13. Temporal Logic Temporal logic has been proposed to be one of the useful tools in workflow modelling. In the following sections, we will give an overview of some approaches which present different temporal logic based models.

Description Existing languages such as Business Process Execution Language for Web Services (BPEL4WS) [ACD+03], Web Service Choreography Interface (WSCI) [W3C02], and Business Process Modeling Language (BPML) [A02] for describing Workflow model show limited support for modelling and representation of time constraints associated with the processes. The need to give support for formal temporal constraint representation in the workflow model is well recognized as an important aspect. So, relevant researches on workflow often focus on this issue and try to introduce temporal constraints in process modelling.

Examples Authors in [M03] propose a formal workflow model based on temporal logic (TLWS). This model provides a formal way to represent different properties, such as the abstraction of activities, the synchronization among activities, and the step-wise refinement design procedure of a workflow. Based on this model, authors propose an interactive workflow design environment based on XYZ system, which is a powerful CASE environment and whose kernel is based on a temporal logic language XYZ/E [TZ94]. This environment supports not only the specification of various objects in workflow system, but also the specification of the workflow service, activities, concurrent processes, and so on. As an extension to this work, [DM08] use the previous temporal logic based Workflow specification (TLWS) to design a new workflow management system. This workflow management system not only has some excellent features of specifying workflow service, but also provides well support for the flexibility of workflow, by providing a formal means for the specification of workflow process. In another approach [YTT+04], the concept of temporal workflow is proposed, through extending and modifying the Workflow Management Coalition (WfMC) basic process definition meta-model. Primary elements in workflow are formalized, and time is introduced into workflow as a dimension. [CPK03] present a temporal formalism for representing indeterminacy to workflow specifications, and try to show that integrating workflow with temporal database can enhance the workflow specification. They propose a new framework for representing and querying a temporal workflow schema and the evolution of its states over the time. Another interesting approach is presented in [AP06]. In this approach, authors propose a declarative language (DecSerFlow) grounded in temporal logic, which can be used for the enactment of processes, or the specification of a single service or a complete choreography. Also, they provide a graphical syntax for some typical constraints in service flows. Moreover, this graphical syntax can be extended by the user, who can add user-defined constraint templates by simply selecting a graphical representation and providing parameterized semantics in terms of Linear Temporal Logic (LTL).

FP7-215175 COMPAS D4.1v2.0


Advantages/Disadvantages The most important advantage of temporal logic based models is that they provide formal way to specify the workflow process with a well defined semantics. So, analysis and reasoning about workflows is made easier, which are difficult to be supported by the previous XML-based models. Also, we think that this kind of model based on temporal logic can provide important properties to improving reusability of processes and service compositions. So, for instance, extraction of process fragments from a repository can be improved by using of temporal constraints.

Challenges One of first challenge for this kind of works is the choice of a powerful logic in term of expressivenesses. For example, the temporal logics such CTL or LTL have not the same expressivenesses (see a comparison table between CTL and LTL in [D2.2]). Another challenge is the number of patterns that can be represented in each proposed model. [AHK+03] proposes a list of patterns, which can serve to compare various models.

Technical difficulties Probably, each model needs its own workflow editor and may be its own workflow engine, with support for temporal constraints checking, which requires a lot of effort in its development.

Area of Application Temporal logic based approaches provide another way to design workflow models. They promise the improvement of flexibility and reusability of workflow models.

2.2.14. Workflow Patterns Workflow patterns provide a means to categorising recurring problems and solutions. They constitute a fundamental element in the workflow based technologies, and were attracted significant interest in the research field. We introduce them in this section for their important factor to improving reusability of processes and service compositions.

Description Workflow patterns provide an effective means to improve the reuse of software, particularly in the design phase. But also, they help to increase understanding of the workflow model. On the other hand, workflow patterns can be used to evaluate the strengths and weaknesses of different existing approaches to develop workflow, including languages and industrial development tools. Workflow patterns are increasingly attracting more and more interest and many research works focused on defining and identifying different patterns in workflow. In the next section we present some of them.

Examples Various workflows pattern are presented in different research works. [AHK+03] provide a number of workflow patterns, considering the workflow modelling language and routing capabilities. As an example of identified patterns: The synchronization pattern (see the figure 12) which represents the convergence of several parallel activities into a single thread of control, thus synchronizing the threads. The figure 13 shows an Exclusive choice pattern. In this pattern, a condition determines which branch is eligible to be executed. Then, on the basis

FP7-215175 COMPAS D4.1v2.0


of these identified workflow patterns authors give a comparison of some of commercially available workflow management systems.

Figure 13 Synchronization pattern [AHK+03]

Figure 14 Exclusive choice pattern [AHK+03]

In [TIR07] authors have identified a set of 9 patterns. Each identified pattern describes a recurrent business function frequently found in business processes (e.g., notification, decision, and approval). These patterns are classified into 3 categories: workflow patterns based on organizational structural aspects (related to one or more organizational aspects); specific application domain patterns (e.g. financial patterns and logistic patterns); and workflow patterns based on recurrent functions (such as notification pattern, and decision pattern). The following figure shows an example of an identified pattern (unidirectional performative message pattern). This pattern shows that an activity execution request results in a work item being assigned to a receiver. After that, the process may continue execution without waiting for a response.

Figure 15 Unidirectional performative message pattern [TIR07]

FP7-215175 COMPAS D4.1v2.0


In [MRV02] administrative workflows patterns are identified. They combine dynamic, procedural knowledge, captured in UML activity diagrams with structural knowledge, modelled in UML class diagrams. Also, their primary purpose is to visualize workflows and associated artefacts in order to understand, compare and to evaluate them prior to the provision of automated support.

An example of administrative workflows is illustrated by the following figure (Activities in the "validate" pattern).

Figure 16 Activities in the "validate" pattern [MRV02]

This pattern describe that any validation process tends to involve criteria that have to be checked, in order to decide whether they are met.

Advantages / Disadvantages Workflow patterns provide an efficient way for the reusability of processes and service compositions. Allow more flexibility in the design, and the development process is made faster because they provide generic solutions to recurring problems. On the other hand, they help in making the process model more understandable.

Challenges The following questions should be considered when identifying new patterns:

1. Check that an identified pattern is not a simple combination of other identified patterns.

2. Is it possible to prove the completeness of the set of identified workflow patterns?

Technical Difficulties [TIR07] recognised that, the main difficulty for identifying workflow patterns was the non-availability of tools for automatically mining the workflow patterns, which could reduce the

FP7-215175 COMPAS D4.1v2.0


mining time and the human effort significantly. Also, it is possible that integrating an identified set of workflow patterns with existing workflow system is not an easy task.

Area of Application Workflow patterns constitute a fundamental element in the workflow based technologies. They are mainly used in workflow design. But, also, they provide a means to evaluate different existing approaches to develop workflow.

2.2.15. Worklets In this section, we present an approach that addresses the problematic of giving support for dynamic flexibility and evolution in workflow systems. Description Current workflow systems show their limits when one wants to model the subtlety of cooperative interactions as they occur in interactive or creative processes, typically co-design and co-engineering processes [GCG06]. So, they give limited capabilities for supporting (i) dynamic evolution (i.e. modifying process definitions during execution) following unexpected or developmental change in the business processes being modelled; and (ii) deviations from the prescribed process model at runtime. Several research directions are investigated to provide solution for this issue. The authors of [AEA+05, AEA+06] have addressed this problematic and tried to give an effective way to ensure flexibility, supporting dynamic change and process evolution in workflow system. So, the concept of worklet was introduced. Examples To provide flexibility and supporting evolution in workflow system, the approach presented by the authors suggests linking each task of a process instance to an extensible repertoire of actions, one of which is contextually chosen at run time to carry out the task. The extensible repertoire of action and a particular mechanism of selection defined by the authors form the base of the concept introduced into their approach, namely, Worklet, which was defined as: a small, self-contained, complete workflow process which handles one specific task in a larger, composite process.

Indeed, worklet is a standard process defined in the YAWL [AH05] language, which refers to a predefined repertoire of actions that can be applied in a variety of situations. At the execution time, only one action will be selected from this repertoire depending on the context of the particular work instance.

The figure 9 shows a simple example specification for a casualty treatment process. In this process, the treat task is to be substituted at run time with the appropriate worklet based on the patient data collected in the Admit and Triage tasks. That is, depending on each patient’s actual physical data and reported symptoms. An example of a worklet probably selected is showed in the figure 10.

FP7-215175 COMPAS D4.1v2.0


Figure 17 Casualty treatment process [AEA+06]

Figure 18 Treat fever worklet process [AEA+06]

So, unlike existing workflow management systems which impose certain rigidity on process definition, authors approach regards the process model as a guide to an activity's objective, rather than a prescription for it; which find its foundation in the well defined theory, named: Activity Theory [N96].

Advantages / Disadvantages The main advantages of this approach are:

1. To enhance workflow flexibility by providing dynamic repertoire of tasks, and dynamic tasks selection mechanism.

2. To handle dynamic exception by allowing contextual choices to be made for appropriate exception handling techniques, using the same selection and invocation mechanism such as for tasks selection.

3. To allow reusing of existing process components and aids in the development of fault tolerant workflows using pre-existing building blocks.

Challenges The mains challenges in this approach are on one the hand, how to enhance the efficiency of the defined mechanism for capturing the context of an execution of a workflow, and on the other hand, how to improve the tasks selection method.

Technical Difficulties Technically, integrating worklet with existing workflow system is not an easy task, but, in theory, it remains possible with any workflow system.

Area of Application

FP7-215175 COMPAS D4.1v2.0


Worklet provide a means to design flexible workflow. They may be used to configure and control the execution of workflow at design time or at run time, by using a specific rules language. Worklet are integrated in YAWL workflow system, but, may be applied in any workflow system.

FP7-215175 COMPAS D4.1v2.0


3. Comparison of Approaches This section contains the application of the criteria concerning reusability described in Section 2.1 to all approaches presented in Section 2.2. So the following tables give an overview of the different approaches and allow comparing the approaches. The following three tables Table 2, Table 3 and Table 4 give an overview of the approaches presented in this deliverable. Each table contains the application of the criteria concerning reusability of five approaches.

3.1. Comparison Ad-hoc

Workflows / Case Handling (2.2.1)

Approaches from Programming

(2.2.2)

Aspect-Oriented Programming (2.2.3)

Business Process Variants (2.2.4)

Constraint-Based Workflows (2.2.5)

Subject of reuse

Services Yes No Yes Yes No

Service Implementation No Yes Yes (AOP can be applied at different levels of abstraction, yet infrastructure and tooling support is required)

Yes No

Policies No No No Yes No

Processes Yes No Yes, reusability and flexibility is increased by separation of concerns

Yes Yes, reusability and flexibility made easy by making use of constraints and performing satisfiability check.

FP7-215175 COMPAS D4.1v2.0


Patterns No No No No Yes, mainly fragments for re-configuration

Documentation No No No Yes No

Relationships between artefacts No No No Yes Yes, captured by constraints

Used techniques

Description of mechanism, functional requirements, non-functional requirements

Various Weaving in of additional functionality, either statically at compile time or dynamically at run time.

Configuration of a reference model (also referred to as process family model) by inserting, modifying or removing activities

Constraint-based mapping

Level of abstraction Process level Program codes Up to processes and down to service implementation

Processes Processes

Mechanism of verification No No No No Yes. Constraints satisfiability: syntactic verification, structural verification, template verification

Standardization A set of operations No No, but several implementations for various programming languages exist, e.g. AspectJ

No standard or common guideline available, yet some scientific proposals for describing configurations

No

Automation No Semi-automated Automated support by compilers and aspect

Semi-automated support in commercial tooling,

Yes. Automation during run time

FP7-215175 COMPAS D4.1v2.0


weaver components no open automation solution available

by migrating process instances

Transformation No No Yes, by applying a configuration to a reference model and deployment of the resulting variant

No

Mechanism of extraction or creation of reusable artefact

Adaptation/ specialization

Segmentation technique

Best practice and experience

Best practice and domain-specific expert knowledge

No

Phase in the process life cycle

Design time At design time by specifying templates

Yes, by analysing program codes and extracting reusable components

Yes, the separation of the component and the aspect is planned during design time

Yes, the configuration is accomplished at design time

Run time No No Yes, by dynamically integrating functionality to running process instances

Yes, by deploying services that are contained in the reference model or by using services that are bound in the reference model

Yes, by transferring instances to a new model

Monitoring No No No (But monitoring could be supported by aspects)

No Yes, by evaluating traces of all running instances

Retrieval mechanism No Yes, using source code repositories

Yes, for aspects of the usage of a source code repository is reasonable (But this is not explicitly

Yes, by using a repository that is integrated with a framework for

No

FP7-215175 COMPAS D4.1v2.0


required in the approach) managing variants

Application domain and coverage

Applicability Any area requiring specification of business processes

Approach is independent from an application area

Requires further investigation

The approach is applicable when processes with a significant similarity, in other words, process families exist

Yes, with YAWL

Domain Processes Software engineering Software engineering, process modelling

Process (Re)Engineering

Processes

Table 2 Comparison of approaches 1 - 5

FP7-215175 COMPAS D4.1v2.0


Continuation of the comparison: Declarative

Processes (2.2.6) Extending BPEL for Runtime Adaptability (2.2.7)

Extraction of Business Rules (2.2.8)

Goal-Orientation (2.2.9)

Parameterization (2.2.10)

Subject of reuse

Services No No No No No

Service Implementation No No No No No

Policies Yes. If expressed as rules.

Yes, selection policies for service selection

Yes No

Processes Yes. Reusability in different contexts made easy. Only the control part has to be specified.

Yes, reusability, flexibility and adaptability of processes are increased by enabling service selection on a per instance bases at runtime

No Yes. Plans can be reused

Yes, reusability and flexibility of processes is increased by making service selection mechanism more dynamic

Patterns No No No No No

Documentation No No No No No

Relationships between artefacts Yes. Captured by rules.

No No No No

Used techniques


Rule and constraint paradigms

Increasing flexibility, adaptability and reusability by introducing a new <find_bind> language construct for enabling dynamic service selection

Generalization through determination of portTypes and operations by parameterization

FP7-215175 COMPAS D4.1v2.0


at runtime

Level of abstraction Processes Process level Processes Processes Processes

Mechanism of verification Yes. Constraint satisfiability for conformance

No No No No

Standardization No No No No Yes, standard-conform BPEL extension with sub-elements for communication activities (receive, invoke, reply)

Automation Yes. Conformance checking for reusing in different environments

Yes Semi-automatic extraction

No Automation during run time by discovering new services using a service directory and semi-automatic during design time by changing of values for parameters using tools

Transformation No No Yes. To generic codes CORBA for example

No No


No Enabling service selection on a per instance bases at runtime.


Yes. Decomposition of goals into sub-goals.

Parameterization


Design time Rules and constraints specified at design time

No Yes Yes The reusable artefact is prepared during design time in the IT refinement and reused during run time.

Run time Conformance checking

Yes, dynamic service selection at run time by definition of selection

No Yes, by querying a directory for determining service selection

FP7-215175 COMPAS D4.1v2.0


policies

Monitoring No No Yes No

Retrieval mechanism No No No No No


Applicability Applicable to all business processes design

Approach is independent from an application area and thus applicable in every domain of business processes.

Yes. Design phase Yes. Design phase of business processes

Mechanism is applicable in all WS-flows independent from language employed for specification. The approach is implemented in BPEL

Domain Processes Processes Processes Processes Processes


FP7-215175 COMPAS D4.1v2.0


Continuation of the comparison: Reference Models

(2.2.11) Sub-Processes (2.2.12) Temporal Logics

(2.2.13) Workflow Patterns (2.2.14)

Worklets (2.2.15)

Subject of reuse

Services Yes No No No No

Service Implementation Yes No No Yes No

Policies Yes No No No No

Processes Yes Yes, reusability of processes is increased by modularization

Yes Yes Yes

Patterns No Invocation patterns Yes Yes Yes

Documentation Yes No No No No

Relationships between artefacts Yes No Yes Yes No

Used techniques


Semi-automatic adaption of a given model according to a reference model that provides a high-quality solution for a certain category of applications.

Modularisation of large and complex business processes by introducing an BPEL extension for sub-processes namely BPEL-SPE

Temporal logic constraints

Definition of patterns Tasks definition and contextual selection method.

Level of abstraction Up to systems and down to processes and services

From process level to sub-process level

Processes Processes Processes

Mechanism of verification None No Model checking No No

FP7-215175 COMPAS D4.1v2.0


Standardization No standard or common guidelines for reference models on service compositions and processes

No, language specification, which defines the precise syntax and semantics of BPEL-SPE is announced to follow but still not available.

No No No

Automation Semi-automated support in commercial tooling, no open automation solution

No No No No

Transformation Yes, by iteratively integrating of parts from the reference model and recurring refactoring

No No No No



No No, but these temporal logic based models, facilitate a possible method of extraction

Yes, process mining is sometimes used to extract recurrent definitions in workflow.

Yes, define a repertoire of reusable tasks.


Design time Yes, by adapting a given model or system, or by refining the reference model and tailoring it to the specific needs

Yes, modularization of processes into sub-processes

Process/workflow definition

Yes Tasks, worklets and selection rules definition.

Run time Yes, by deploying services that are contained in the reference model or by using services that are

Yes, a sub-process may be called by several different parent processes.

Yes, temporal logic give support for checking execution

No Tasks can be created at run time

FP7-215175 COMPAS D4.1v2.0


bound in the reference model

Monitoring No No Yes No No

Retrieval mechanism Yes, using a repository, also called “reference model catalog” in this area

No No No Yes, a selection method depending on the context of the workflow execution.


Applicability The approach can basically be applied in any area touching business, at the technical level it is applicable to processes and implementation, independent of the used languages

Approach is independent from an application area and thus applicable in every domain of business processes.

Each model requires a specific workflow framework

May be used in any workflow framework

May be used in any workflow framework

Domain Business (Re)Engineering

Processes Processes Processes Processes


FP7-215175 COMPAS D4.1v2.0


3.2. Analysis We have presented the state-of-the-art of approaches improving the reusability of processes and service compositions. The comparison allows us to inspect their character and essence, in order to arrive at conclusions of their feasibility and applicability in the field of compliance and in the scope of COMPAS.

The presented tables allow distinguishing between stand-alone concepts and techniques that can be applied also in other approaches described in this deliverable. The techniques we refer to are parameterization (see 2.2.10), extraction of business rules (see 2.2.8) and aspect-oriented programming (see 2.2.3). For example, parameterization can be applied to process variants to increase the reusability and simplify the configuration. Hence, it would be conceivable to apply these techniques in any approach for improving reusability.

A criterion, in which the stand-alone concepts differ, is their application in practice. The approaches for sub-processes (see 2.2.12), reference models (see 2.2.11) and process variants (see 2.2.4) come from industrial requirements for reusing systems (and processes) and are thus near to execution with according, typically semi-automated tooling support, while many other approaches that are coming from research, such as temporal logic (see 2.2.13) or constraint-based workflows (see 2.2.5) do not provide a completely “execution-ready” concept and hold challenges that go beyond the scope of COMPAS, for example the execution of declarative processes (see 2.2.6).

There is no ultimate approach, but some are more or less applicable, depending on the specific requirements. So, in COMPAS not all of the presented concepts are applicable, yet they are very useful for identifying common techniques in the field of reusability. One aspect, that most of the approaches have in common, is the relaxation of constraints. It is argued, that processes tend to be over-specified and that such specification is often too rigid for allowing efficient reuse. This aspect can be taken into account when designing new concepts for reusable units.

3.2.1. Subject of reuse Which artefacts are actually reused in the described approaches ranges from code within the service implementation, whole services, policies and rules within a process, recurring patterns, sub-processes, over complete processes and process families, up to whole systems containing multiple processes and other information. Irrespective of the subjects that are reused in an approach, there is already some basic work in all areas available that can be built on, when designing a new concept for reuse in the field of processes and service compositions.

3.2.2. Used techniques When comparing the techniques used in the presented approaches it stands out, that having good experience and best practice in the application domain, in addition to having experience with the used techniques, seems to be a typical requirement in order to be able to successfully apply the approach. Besides, support via automation seems to be technically possible overall, but also challenging. The lack of standardizations could be interpreted in many ways, for example that the approaches are not yet elaborated enough or that they have unsolved issues in their concepts or implementations. But it could also be interpreted in a positive way, which is that this field of research is in current flux, with many possible directions to go, but without an outstanding approach that satisfies all needs.

FP7-215175 COMPAS D4.1v2.0


3.2.3. Phase in the life cycle Not all of the concepts cover all phases in the life cycle of a process, most notably monitoring is disregarded in many approaches. A continuous approach for improving reusability should account not only for design time, but also for run time and monitoring, this should consequently be taken as a requirement when designing new types of, and concepts for, reusable units. It can also be pointed out, that a repository (or any other component that provides for efficient management of the reusable artefacts) can be taken as appliance when designing a holistic solution concept for improving reusability.

3.2.4. Application domain and coverage All of the presented approaches and techniques can be applied to processes and service compositions in general, each with its own advantages and shortcomings. Whether the concepts can successfully be applied in the field of compliance and in the context of COMPAS can not be concluded by this comparison. We will elaborate on this in the conclusions section (see Section 4) and the sub-section on the relation of these approaches to the COMPAS project (see 4.3).

FP7-215175 COMPAS D4.1v2.0


4. Conclusion

4.1. Summary Business processes are considered as important bricks of successful organizations. Business processes modelling becomes relevant because organizations need to communicate and transfer processes in the business world. Companies put more effort on the evaluation, verification and optimization of their processes. Also, the focus is on automating most of the aspects of business processes in order to reduce the time and the costs of human resources. Processes reuse can be considered as a realistic way to improve service engineering productivity and quality. Assistance for software reuse involves the modelling, classification, retrieval and adaptation of processes/components. The representation and retrieval are important to processes reuse. Most of the proposed techniques ignore the semantic information about processes, so it is often difficult to retrieve the fragments that satisfy user’s requirements. In this report we concentrate on how processes/services reuse can be exploited in the service composition process for developing more rapid and efficient SOA-based applications. First, we identified a set of criteria that we use for the classification and analysis of the existing approaches. The different approaches are categorized based on some dimensions (e.g., declarativeness, parameterization, annotation, etc.) or concepts (e.g., patterns, business rules, etc.).

4.2. Relation to Compliance When dealing with business applications, many issues have to be considered. Among them business policies: business process, business rules, etc. The challenge is then to be able to guarantee the compliance of internal business policies (implementation) with external regulations. This requires avoiding hard-coding policies and regulations directly in control-flow based process models. One can note that flexible business applications require declarative formalisms to capture the semantics of policies and regulations. In the following, we highlight the impact, on compliance, of issues we described so far:

• Parameterization: it can help in achieving compliance checking by making use of substitution mechanism.

• Constraint based approach: it can be used to specify parts of policies and parts of regulations for example. In this case, the compliance checking problem can be seen as a constraint satisfaction problem.

• Declarative approach: it enables designers to describe the actions that a business process needs to contain, but not their sequence. As a consequence, it becomes easy to perform compliance checking by reasoning on high-level description of policies rather than on codes associated to policies.

• Business rules: they constitute the main component in a business application. Compliance to regulations is the main concern of business rules. The way business rules are extracted and represented will have a significant impact on compliance checking.

FP7-215175 COMPAS D4.1v2.0


• Annotation: it can be considered as a means to relate artefacts. Annotations can play an important role in checking compliance by discovering possible mappings (through annotations) between considered components. This is in the line of semantic-based approaches to compliance checking.

• Transformation: it happens that components involved in a compliance checking are described in different languages. Transformation can be considered as a pre-processing step where checking will be performed on statements specified in a common language.

• Patterns: they present solutions for recurring requirements in a specific context. Patterns allow bridging the gap between experts and developers. Since patterns are used to capture solutions at a high-level of abstraction, they can be used in the process of compliance checking for those issues that require abstraction.

4.3. Relation to COMPAS COMPAS is about compliance in all components of the SOA. In this state-of-the-art we investigated different issues related to reusability of processes and service compositions. Most of the covered issues are also relevant to compliance checking: modelling, annotation, transformation, patterns, etc. For example, checking compliance of internal business policies (implementation) with external regulations requires performing checks at different levels of abstraction. This State-of-the-art provides a good basis for providing reference techniques for compliance checking at different levels, including design time, analysis time and run time. The focus will be on reusability of processes and service composition.

4.3.1. Drawbacks of the existing approaches to improving reusability Each of the approaches presented in this deliverable has certain advantages, but also drawbacks in its application in practice. Sub-processes allow reuse on the level of application and business logic, yet this concept is rather rigid and monolithic, see Section 2.2.12. Reference models can even contain the reusable description and implementations of a whole system, which is a quite heavyweight concept for reuse. Process variants cover reusability and customizability for whole process models. Reusing only a part or an artefact of a process model may be required in some case, but this is not covered by this approach, see Section 2.2.4.

None of the approaches is, on its own, capable of solving the difficulty of compliance in COMPAS, as stated in the case studies [D6.1]. We therefore need an approach that combines the advantages of the presented works, and modifies and extends the given concepts with the goal to define a solution for reusability and compliance in the area of processes and service compositions.

In the following we will outline a solution concept, that we call process fragments. The approach combines concepts from some of the presented approaches, such as sub-processes, parameterization, workflow patterns and possibly AOP as integration mechanism.

4.3.2. Concept of process fragments A process fragment [ML08] is a connected sub-graph of a process graph. Applied to BPEL [OASIS07], it can also contain additional artefacts, such as variables, references to related Web Services orchestrated within the process, annotations (which are very important for

FP7-215175 COMPAS D4.1v2.0


stating compliance) etc. Some parts of a fragment may be subject to parameterization, or explicitly stated as opaque, in order to mark points of variability and degree of freedom for reuse. Thus, in contrast to a sub-process, a process fragment is not necessarily directly executable. Initial work has been done by the BPEL2.0 specification [OASIS07]: abstract processes have been specified for templating purposes and for modelling visible behaviour of processes that take part in a globally coordinated choreography. Yet, a process fragment is not necessarily self-contained, and many customization steps are required when fragments shall be integrated into a process. This is a disadvantage compared to sub-processes. However, the usage scenarios of process fragments, that we propose, compensate this drawback.

4.3.3. Usage scenarios for reusing process fragments We can distinguish three different usage scenarios for process fragments. The first one is that a process fragment can be employed for reuse of functionality (in the case of COMPAS business logic and compliance requirements in form of Web Service orchestrations). Second, it can be attached as a constraint to a process, for example to state that this process implements the functionality stated by the fragment. So, process fragments can be utilized for the annotation of process models and thereby describing their (required) behaviour, i.e. compliance constraints. This information can be reused in the third usage scenario. After transformation the fragment can be used during monitoring to check, if a running or finished process instance is compliant with the constraints described by the fragment, or not. Those usage scenarios are sketched below.

Usage scenario 1: reuse of business logic For improving the reusability of processes the concept of process fragments means a fundamental advancement, as it fills a gap that none of the presented approaches for reuse covers. The first usage scenario is describing reuse of business logic using process fragments. This scenario can be divided into four distinct phases:

1. Identification: A process fragment is a meaningful part of a process that has the potential to be reusable in various different process models. Note, the implementation of a specific compliance constraint might be such a part, which is essential for the usage in COMPAS. The identification can either be achieved using mining techniques to find often repeating execution patterns, or by a domain expert who inspects already implemented process models and extracts one or more process fragments from its parent process model. Also the creation of fragments from scratch might be reasonable in some cases.

2. (Re-) Design: Certain adaptations are necessary when a process fragment has been extracted from a process model; activities may need to be reordered, attributes on such activities may need to be omitted in order to mark freedom or to hide confidential information. Parameterization techniques and also the extraction of business rules could be applied in this phase to increase the reusability of the fragment.

3. Storage: In order to be able to efficiently find process fragments they need to be annotated with metadata that state their semantics, usage domain, functionality, requirements, interfaces etc. After the process fragment has been accordingly annotated, it is being stored in a repository that provides management functionality (search/query/store/…) for process fragments.

4. Composition: The integration of a process fragment into a process model and also the composition of multiple fragments is a challenging task. Before the integration into a

FP7-215175 COMPAS D4.1v2.0


process model can take place the fragment may need to be tailored to the needs, depending on the concrete process model in which it is reused. In this phase it might be feasible to employ the AOP approach (see Section 2.2.3) for achieving maximum reusability.

Usage scenario 2: annotations for describing behaviour Basically, there are two possible ways to annotate compliance information to a process model (cf. Figure 19): The first one is textual annotation (“Attached Annotations”), and the second is the annotation by process fragments (“Attached Fragments”). The annotation of textual compliance constraints via an attachment mechanism is necessary for all compliance constraints that cannot be expressed by process fragments. Such compliance constraints can basically be stated in any language, such as a constraint language like the Object Constraint Language (OCL) [OMG06] or also WS-Policy [BBC+06], see also appendix A.1. In some cases it might be feasible to use natural language, yet with the drawback that this is not machine-readable. The second annotation mechanism is the attachment of compliance constraints in form of process fragments. This allows describing certain parts of the required behaviour like control flow of a process model in a way feasible for further machine-processing, as we show in the third usage scenario. If new compliance requirements should be implemented and described as process fragments compliance experts will be required for assisting a company to interpret e.g. legislations or regulations regarding compliance in order to define, what compliance legislation mean in the concrete case of a company. Even if the process fragments already exist and should be reused, the help of compliance experts will be required for indentifying the process fragments for concrete compliance concerns before annotating the processes.

Usage scenario 3: application of process fragments during monitoring The approach of employing process fragments during monitoring mainly consists of the challenge to transform the process fragments, and hereby also taking their annotation into account, into statements that can be mapped to execution events, and hence can be checked during monitoring. Any information that is required in order to properly check compliance of the execution needs to be contained in the process fragment or its annotation. The constraints that have to be satisfied in order to be “compliant” are manifold and not limited to control flow, for example also data flow or even encryption protocols might also be taken into account. The concrete mapping of process fragments to statements, which can be checked during monitoring, is future work in the COMPAS project and will be concretely specified and defined in prospective deliverables. One requirement for near-real time monitoring and mining is the retrieval of process fragments. This is shown by connections between the process (-fragment) repository and the monitoring and mining components in the overall COMPAS architecture, for details see mapping table in [D1.1] and the according figure.

FP7-215175 COMPAS D4.1v2.0


Figure 19 Annotations for describing behaviour

4.3.4. Identification of requirements for classification and specification of reusable process artefacts

Due to the Description of Work of the COMPAS project [DoW] this deliverable identifies the requirements for classification and specification of reusable process artefacts for a prospective deliverable.

The state-of-the-art and the approach of process annotation with process fragments and textual annotation, described in this deliverable, point to the following list of identified requirements for classification and specification of reusable process artefacts:

• Distinction, classification, definition and specification of types of process artefacts for employment for reusing business logic and annotation for describing behaviour, see Section 4.3.3

• Description of procedures for employment of process artefacts for integration into BPEL processes when reusing business logic, annotation of process fragments to BPEL processes, etc.

• Specification and definition of transformation mechanism of process fragments to statements, which are processable during monitoring and mining.

• Management of reusable artefacts in a repository, e.g. storing, retrieving, querying, etc.

FP7-215175 COMPAS D4.1v2.0


5. Reference documents

5.1. Internal documents [DoW] “Description of Work” for COMPAS, final version of 2008-02-01

[D1.1] “Model-driven integration architecture for compliance”, final version of 2008-12-31

[D4.3] “Classification and specification of reusable process artefacts”, 2010-07-31

[D6.1] “Use Case, Metrics and Case Study”, final version of 2008-07-31

[D7.1] “Public Web-Site”, http://www.compas-ict.eu

5.2. External documents

[A02] A.Arkin: Business Process Modeling Language (BPML). BPMI.org, 2002.

[Aal99] W.M.P. van der Aalst: Generic Workflow Models: How to Handle Dynamic Change and Capture Management Information? In: Proceedings of the Fourth IECIS International Conference on Cooperative Information Systems (COOPIS'99). IEEE Computer Society, 1999.

[ACD+03] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic and S. Weerawarana: Business Process Execution Language for Web Services Version 1.1. Second public draft release of the BPEL4WS specification, May 2003, http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf.

[ADG+05] W.M.P. van der Aalst, A. Dreiling, F. Gottschalk, M. Rosemann and M.H. Jansen-Vullers: Configurable Process Models as a Basis for Reference Modeling. In: Proceedings of the Workshop on Business Process Reference Models, BPRM 2005.

[AH05] W.M.P. van der Aalst and A.H.M. ter Hofstede: YAWL: Yet Another Workflow Language. Information Systems, 30(4):245-275, 2005.

[AHE+05] M. J. Adams, A.H.M. ter Hofstede, T. D. Edmond, and W.M.P. van der Aalst: Facilitating flexibility and dynamic exception handling in workflows through worklets. In Orlando Bello, Johann Eder, Oscar Pastor, and Falcao, editors, 17th International Conference on Advanced Information Systems Engineering (CAiSE’05) Forum, pages 45–50, 2005.

[AHE+06] M. Adams, A.H.M. ter Hofstede, T. D. Edmond and W.M.P. van der Aalst: Worklets: A service-oriented implementation of dynamic flexibility in workflows. pages 291–308. 2006.

[AHK+03] W. M. P. Van Der Aalst, A. H. M. T. Hofstede, B. Kiepuszewski and A. P. Barros: Workflow Patterns, Distributed and Parallel Databases, v.14 n.1, p.5-51, July 2003.

http://www.compas-ict.eu/�

http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf�

http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf�

FP7-215175 COMPAS D4.1v2.0


[AP06] W.M.P. van der Aalst and M. Pesic: DecSerFlow: Towards a Truly Declarative Service Flow Language, International Workshop on Web Services and Formal Methods No3, Vienna , AUTRICHE (2006) 2006.

[BBC+06] S. Bajaj, D. Box, D. Chappell, F. Curbera, G. Daniels, P. Hallam-Baker, M. Hondo, C. Kaler, D. Langworthy, A. Nadalin, N. Nagaratnam, H. Prafullchandra, C. v. Riegen, D. Roth, J. Schlimmer (Editor), C. Sharp, J. Shewchuk, A. Vedamuthu, Ü. Yalçinalp and D. Orchard: Web Services Policy 1.2 - Framework (WS-Policy), W3C Member Submission, April 2006, http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/.

[BBG+05] J. Bayer, W. Buhl, C. Giese, T. Lehner, A. Ocampo, F. Puhlmann, E. Richter, A. Schnieders, J. Weiland and M. Weske: PESOA - process family engineering - modeling variant-rich processes. PESOA Report TR 18/2005, Hasso-Plattner-Institut, Potsdam, September 2005.

[Cha06] C.-C. Chaing: Extracting Business Rules from Legacy Systems into Reusable Components. Proceedings of the 2006 IEEE/SMC International Conference on System of Systems Engineering Los Angeles, CA, USA, April 2006.

[CCM+01] E. Christensen, F. Curbera, G. Meredith and S. Weerawarana: Web Services Description Language (WSDL) 1.1. W3C Note, March 2001, http://www.w3.org/TR/wsdl.

[CF04] C. Courbis and A. Finkelstein: Towards an aspect weaving BPEL engine. In: Third AOSD Workshop on Aspects, Components, and Patterns for Infrastructure Software (ACP4IS), Lancaster, UK, 2004.

[Cha07] A. Charfi: Aspect-Oriented Workflow Languages: AO4BPEL and Applications. Dissertation, Darmstadt, 2007.

[CPK03] P. Chountas, I. Petrounias and V. Kodogiannis: Temporal Modelling in Flexible Workflows, ISCIS, 2003.

[CM04] A. Charfi and M. Mezini: Aspect-Oriented Web Service Composition with AO4BPEL. In: Proceedings of the European Conference on Web Services ECOWS 2004, LNCS 3250. Erfurt, Germany, September 2004.

[CMR+07] R. Chinnici, J-J. Moreau, A. Ryman and S. Weerawarana: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C Recommendation, June 2007, http://www.w3.org/TR/wsdl20/.

[DM08] Y. Duan and H. Ma: Modeling flexible workflow based on temporal logic, The 9th International Conference on Computer Supported Cooperative Work in Design Proceedings, 2005.

[FA01] M. E. Fayad and A. Altman: Introduction to Software Stability. Communications of the ACM. Vol. 44, N°. 9, September 2001.

[FLZ05] P. Fettke, P. Loos and J. Zwicker: Business Process Reference Models: Survey and Classification. In: Proceedings of the Workshop on Business Process Reference Models, BPRM 2005.

[GCG06] D. Grigori, F. Charoy and C. Godart: Enhancing the Flexibility of Workflow Execution by Activity Anticipation. International Journal of Business Process Integration and Management Publisher Inderscience Enterprises Ltd. 1, 143-155, 2006.

http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/�

http://www.w3.org/TR/wsdl�

http://www.w3.org/TR/wsdl20/�

FP7-215175 COMPAS D4.1v2.0


[HBR08] A. Hallerbach, T. Bauer and M. Reichert: Managing Process Variants in the Process Lifecycle. In: 10th Int'l Conf. on Enterprise Information Systems (ICEIS'08), Barcelona, Spain, June 2008.

[HC05] A. Houspanossian and M. Cilia: Extending an Open-Source BPEL Engine with Aspect-Oriented Programming. In: Proceedings of the Argentinean Symposium on Software Engineering (ASSE’05), Rosario, Argentina, 2005.

[HF05] H.S. Hamza and E. Fayad: A novel approach for managing and reusing business rules in business architectures. In proceedings of the 3rd ACS/IEEE International Conference on Computer Systems and Applications. Pages 973- 978. 2005.

[Jin03] L. Jingyue: A Survey on Reuse: Research Fields and Challenges, 2003 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.107.1020.

[KEF00] G. Knolmayer, R. Endl and M. Farer: Modeling Processes and Workflows by Business Rules, Business Process Management, LNCS 1806, pp 16-29, 2000.

[KHC+05] D. Karastoyanova, A. Houspanossian, M. Cilia, F. Leymann, and A. Buchmann: Extending BPEL for Run Time Adaptability. In Proceedings of EDOC 2005. Enschede, The Netherlands, September 2005.

[KKL+07] M. Kloppmann, D. Koenig, F. Leymann, G. Pfau, A. Rickayzen, C. Riegen, P. Schmidt, and I. Trickovic: WS-BPEL Extension for Sub-processes – BPEL-SPE. White Paper, September 2007.

[KKR06] J. Küster, J. Koehler and K. Ryndina: Improving Business Process Models with Reference Models in Business-Driven Development. 2nd International Workshop on Business Process Design, BPM 2006.

[KLB05] D. Karastoyanova, F. Leymann, and A. Buchmann: An Approach to Parameterizing Web Service Flows. In Proceedings of ICSoC2005. Amsterdam, The Netherlands, December 2005.

[KLM+97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier and J. Irwin: Aspect-oriented Programming. In ECOOP'97, LNCS 1241, pp. 220-242, 1997.

[KLN+06] D. Karastoyanova, F. Leymann, J. Nitzsche, B. Wetzstein, and D. Wutke: Parameterized BPEL Processes: Concepts and Implementation. In Proceedings of BPM 2006. Vienna, Austria, September 2006.

[KN05] E. Kindler (ed.), M. Nüttgens (ed.): Business Process Reference Models. Proceedings of the Workshop on Business Process Reference Models, BPRM 2005.

[KS97] Yongbeom Kim and Edward A. Stohr: Software reuse: survey and research directions. In J. Manage. Inf. Syst. volume 14, number 4. Pages 113-117. 1998.

[LS06a] R. Lu, S. Sadiq: On Managing Process Variants as an Information Resource. Technical Report, No.TR-464, School of Information Technology and Electrical Engineering, The University of Queensland, Australia, 2006.

[LS06b] R. Lu and S. Sadiq: Managing Process Variants as an Information Resource. In: Proceedings of the 4th International Conference on Business Process Management (BPM2006), Vienna, Austria, 2006.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.107.1020�

FP7-215175 COMPAS D4.1v2.0


[Ma03] H. Ma: A workflow model based on temporal logic, Temporal Logic Based Workflow Service Modeling and Its Application, The 8th International Conference on Computer Supported Cooperative Work in Design Proceedings. 2004.

[MHS00] J. Meng, S. Helal and S. Su: An Ad-Hoc Workflow System Architecture Based on Mobile Agents and Rule-Based Processing. Proceedings of The International Conference on Artificial Intelligence, pp. 245-251, Nevada, USA, June 2000.

[ML08] Z. Ma and F. Leymann: A Lifecycle Model for Using Process Fragment in Business Process Modeling. In: Proceedings of the 9th Workshop on Business Process Modeling, Development, and Support (BPDMS 2008).

[MRV02] R. Motschnig-Pitrik, P. Randa and G. Vinek: Specifying and Analysing Static and Dynamic Patterns of Administrative Processes. ECIS 2002.

[Nar96] B.A. Nardi: Context and Consciousness: Activity Theory and Human-Computer Interaction. MIT Press, Cambridge, Massachusetts, pages 7–16. 1996.

[NEK93] J. Q. Ning, A. Engberts, and W. Kozaczynski: Recovering Reusable Components from Legacy Systems by Program Segmentation. Proceedings of the Working Conference Reverse Engineering, 1993.Volume , Issue , 21-23, Page(s):64 – 72. May 1993.

[NEXOF08] NEXOF-RA: NESSI Open Framework Reference Architecture. 2008, http://www.nexof-ra.eu/

[OASIS05] OASIS: UDDI Version 3 Specification. OASIS Standard, 2005, http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm.

[OASIS07] A. Alves, A. Arkin, S. Askary, C. Barreto, B. Bloch, F. Curbera, M. Ford, Y.Goland, A. Guízar, N. Kartha, C.K. Liu, R. Khalaf, D. König, M. Marin, V. Mehta, S. Thatte, D. van der Rijn, P. Yendluri, and A. Yiu: Web Services Business Process Execution Language Version 2.0. OASIS Comitee Specification, April 2007. http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf

[OMG06] Object Management Group: Object Constraint Language. OMG Available Specification, Version 2.0, May 2006, http://www.omg.org/docs/formal/06-05-01.pdf.

[PA05] M. Pesic and W.M.P. van der Aalst: Towards a Reference Model for Work Distribution in Workflow Management Systems. In: Proceedings of the Workshop on Business Process Reference Models, BPRM 2005.

[PA06] M. Pesic and W.M.P. van der Aalst: A Declarative Approach for Flexible Business Processes Management. In BPM 2006 Workshops: International Workshop on Dynamic Process Management (DPM 2006), Lecture Notes in Computer Science.Springer-Verlag, Berlin, 2006.

[PSS+07] M. Pesic, M.H. Schonenberg, N. Sidorova and W.M.P. van der Aalst: Constraint-Based Workflow Models: Change Made Easy. Proceedings of the OTM 2007. Pages 77-94.

http://www.nexof-ra.eu/�

http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm�

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf�

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf�

http://www.omg.org/docs/formal/06-05-01.pdf�

http://www.omg.org/docs/formal/06-05-01.pdf�

FP7-215175 COMPAS D4.1v2.0


[RD05] F. Rosenberg, S. Dustdar: Business Rules Integration in BPEL – A Service-Oriented Apporach. In: Proceedings of the 7th International IEEE Conference on E-Commerce Technology (CEC’05), 2005.

[RRA+05] J. Recker, M. Rosemann, W.M.P. van der Aalst and J. Mendling: On the Syntax of Reference Model Configuration – Transforming the C-EPC into Lawful EPC Models. In: Proceedings of the Workshop on Business Process Reference Models, BPRM 2005.

[Sch94] A.-W. Scheer: Business Process Engineering. Reference Models for Industrial Enterprises. Berlin, Springer, 1994.

[SOS04] S. W. Sadiq, M. E. Orlowska and W. Sadiq: Specification and validation of process constraints for flexible workflows. Information Systems 30 (2005). 349-378.

[Tho05] O. Thomas: Understanding the Term Reference Model in Information Systems Research: History, Literature Analysis and Explanation. In: Proceedings of the Workshop on Business Process Reference Models, BPRM 2005.

[TIR07] L.H. Thom, C. Iochpe and M. Reichert: Workflow Patterns for Business Process Modeling, 8th Workshop on Business Process Modeling, Development, and Support (BPMDS'07), 2007.

[TS06] O. Thomas and A.-W. Scheer: Tool Support for the Collaborative Design of Reference Models – A Business Engineering Perspective. Proceedings of the 39th Hawaii International Conference on System Sciences 2006.

[TZ94] Z.S. Tang and C. Zhao: A temporal logic language oriented toward software engineering, Journal of Software, Science Press, 5(12) (1994) 1-12.

[VA97] M. Voorhoeve and W.M.P. van der Aalst: Ad-hoc Workflow: Problems and Solutions. Proceedings of the Eighth International Workshop on Database and Expert Systems Applications, 1997.

[W3C02] W3C. Web Service Choreography Interface (WSCI) 1.0. Accessed November 2002 from www.w3.org/TR/wsci/, 2002.

[WCL+05] S. Weerawarana, F. Curbera, F. Leymann, T. Storey, and D.F. Ferguson: WebServices Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging and More. Prentice Hall PTR Upper Saddle River, NJ, USA, 2005.

[Whi07] Whitestein Technologies: Goal-Oriented Autonomic Business Process Management. White paper. 2007.

[WFMC95] Workflow Management Coalition: Workflow Reference Model. 1995. http://wfmc.org/reference-model.html.

[YTT+04] Y. Yu, Y. Tang, N. Tang, X. Ye, and L. Liang: A Meta-model of Temporal Workflow and Its Formalization, GCC 2004, LNCS 3251, pp. 987–992, 2004.

http://wfmc.org/reference-model.html�

FP7-215175 COMPAS D4.1v2.0


Appendices

A. Appendix A

A.1. Related standards and technologies

Standard Description BPMN The Business Process Modeling Notation is meant to be a higher

level, graphical language for modelling business processes. Existing versions are 1.0 and 1.1, version 2.0 is in progress.

WS-BPEL The business process execution language for web services has been adopted by industry as the standard for service orchestration. Version 1.0 and 1.1 (BPEL4WS) have been driven by companies such as IBM, Microsoft and SAP and it has been standardized by OASIS and released as version 2.0, WS-BPEL.

WS-Policy S. Bajaj, D. Box, D. Chappell, F. Curbera, G. Daniels, P. Hallam-Baker, M. Hondo, C. Kaler, D. Langworthy, A. Nadalin, N. Nagaratnam, H. Prafullchandra, C. Riegen, D. Roth, J. Schlimmer, C. Sharp, J. Shewchuk, A. Vedamuthu, Ü. Yalçinalp and D. Orchard. Web Services Policy 1.2 - Framework (WS-Policy), W3C Member Submission, 25 April 2006.

XPath W3C. XML Path Language (XPath). Version 1.0, W3C Recommendation 16 November 1999, http://www.w3.org/TR/xpath

Table 5 Related standards and technologies

http://www.w3.org/TR/xpath�

d4 - cordis · d4.1 version: 2.0 date: 2009-06-08 dissemination status: pu document reference: d4.1...

Documents