UML 2.0 Profile for WS-BPEL with Mapping to WS-BPEL

Institut für Architektur von Anwendungssystemen

Universität Stuttgart Universitätsstr. 38 70569 Stuttgart

Diplomarbeit Nr. 2345

Thomas Ambühler

Studiengang : Softwaretechnik

Prüfer : Prof. Dr. Frank Leymann Betreuer : Michael Friess, IBM Deutschland Entwicklung GmbH Begonnen am : 01.05.2005 Beendet am : 31.10.2005

CR-Klassifikation : D.2.2, D.3.2, D.2.12

Abstract

UML 2.0 is the de-facto standard for graphical notation and modelling in software engineering and has a wide variety of usage scenarios. The Business Process Execution Language for Web Services (BPEL4WS) is an XML-based language for specifying business processes, both abstract and executable, but does not include a graphical representation. This thesis specifies a UML 2.0 profile which enables the graphical representation of BPEL processes with UML 2.0. It also details the implementation of this profile using the Rational Software Modeler and furthermore, the transformation of these UML 2.0 models to BPEL by means of transformation rules implemented as an Eclipse plug-in using a transformation engine. The results of this thesis include the specified profile and a specific implementation (with some adaptations). It also includes the mapping rules and shows how they can be used to implement a mapping tool.

Credits

I would like to thank Prof. Dr. Frank Leymann for his support and this interesting topic.

Special thanks go to Michael Friess. Without his support, experience, and input this thesis would not have been possible.

I would also like to thank Tracy Gardner for her valuable input on this thesis, especially regarding UML, and Catherine Griffin for her help and support throughout the implementation.

Moreover, I would like to thank my mother. Without her, I would not be where and what I am to- day.

Table of Contents

1. INTRODUCTION ...... 11

1.1. Motivation...... 11

1.2. Scope ...... 11

1.3. Structure of the Thesis ...... 12

2. BUSINESS PROCESS EXECUTION LANGUAGE FOR WEB SERVICES 13

2.1. Service Oriented Architecture (SOA) ...... 13 2.1.1. Web Services ...... 15 2.1.1.1. Web Service Description Language (WSDL) ...... 15

2.2. Business Process Execution Language for Web Services...... 16

2.2.1. History of BPEL ...... 16

2.2.2. BPEL Technical Overview ...... 17 2.2.2.1. Process Life Cycle and Types ...... 17 2.2.2.2. Partner Links and Communication ...... 17 2.2.2.3. Data Handling, Properties and Correlation ...... 18 2.2.2.4. Basic Activities ...... 19 2.2.2.5. Structured Activities ...... 19 2.2.2.6. Scopes and Handlers ...... 21

2.3. BPEL 2.0 ...... 22

3. UNIFIED MODELING LANGUAGE (UML)...... 23

3.1. History of UML ...... 23

3.2. UML Diagrams...... 24 3.2.1. Structural Diagrams ...... 24 3.2.1.1. Class Diagrams ...... 25 3.2.1.2. Composite Structure Diagrams ...... 25 3.2.1.3. Other Structural Diagrams ...... 28 3.2.2. Behavioural Diagrams ...... 29 3.2.2.1. Activity Diagrams ...... 29 3.2.2.2. Other Diagrams ...... 37

3.3. UML profiles...... 39

3.4. UML 1.4 Draft Profile for BPEL 1.0...... 41 3.4.1. Dependency Management and packages ...... 41 3.4.2. Data Types and Interfaces ...... 42 3.4.3. Properties and Correlations ...... 42 3.4.4. Partner Link Types ...... 43 3.4.5. Process, State, and Ports ...... 44

3.4.6. Data Handling ...... 44 3.4.7. Basic Activities ...... 45 3.4.8. Structured Activities ...... 45 3.4.9. Error Handling ...... 46 3.4.10. Issues ...... 46 3.4.11. Reusable Profile Concepts ...... 47

4. UML 2.0 PROFILE FOR BPEL 1.1 ...... 48

4.1. Concepts adapted from previous Profile ...... 48

4.2. New Concepts...... 52

5. PROFILE IMPLEMENTATION ...... 60 5.1. Rational Software Modeler ...... 60 5.1.1. Relevant Restrictions in Rational Software Modeler ...... 60

5.2. Implementation Details ...... 61

5.3. Considerations for BPEL 2.0...... 67

6. MAPPING BETWEEN PROFILE AND BPEL ...... 71

6.1. Relation and Transformation Rules...... 71 6.1.1. BPEL Process ...... 72 6.1.2. Standard Activities and Elements for BPEL activities ...... 74 6.1.3. BPEL basic activities ...... 75 6.1.4. BPEL Structured Activities ...... 78 6.1.5. WSDL/XSD elements ...... 81 6.1.6. Approach to Overall Mapping ...... 82

6.2. Transformation Technologies...... 85

6.3. Realisation of Prototype ...... 87

7. CONCLUSION...... 90

7.1. Future Work...... 90

LIST OF LITERATURE ...... 91

APPENDIX A - UML 2.0 PROFILE FOR BPEL...... A - 1

Table of Figures

FIGURE 1: SOA COMPONENTS (FROM [21]) ...... 14 FIGURE 2: WSDL INFORMATION MODEL ...... 16 FIGURE 3: LINK EXAMPLE ...... 21 FIGURE 4: UML 2.0 DIAGRAM TYPE , OVERVIEW ...... 24 FIGURE 5: SAMPLE DIAGRAM WITH CLASS DIAGRAM ...... 25 FIGURE 6: SAMPLE DIAGRAM WITH STRUCTURED CLASSIFIER (FROM [2]) ...... 26 FIGURE 7: “S ALE ” COLLABORATION (FROM [2])...... 26 FIGURE 8: “B ROKERED SALE ” COLLABORATION (FROM [2]) ...... 27 FIGURE 9: SAMPLE CLASS WITH PORT ...... 28 FIGURE 10: ACTIVITY PACKAGE DEPENDENCY [2]...... 30 FIGURE 11: ACTIVITY GROUPS ...... 32 FIGURE 12: SWIMLANE , EXAMPLE ...... 33 FIGURE 13: ALTERNATIVE NOTATION ...... 33 FIGURE 14: MULTI -DIMENSIONAL PARTITION GROUP ...... 34 FIGURE 15: EXAMPLE WITH INTERRUPTIBLE REGION ...... 35 FIGURE 16: STRUCTURED ACTIVITY NODE , WITH CONTROL AND OBJECT FLOW ...... 35 FIGURE 17: STRUCTURED ACTIVITY NODE WITH OUTGOING FLOW FROM INSIDE ...... 36 FIGURE 18: STEREOTYPES SAMPLE DIAGRAM (FROM [19])...... 40 FIGURE 19: PROFILE PACKAGE , ABSTRACT SYNTAX (F ROM [2]) ...... 40 FIGURE 20: PACKAGE IMPORT STRUCTURE ...... 41 FIGURE 21: MESSAGE WITH DATA ...... 42 FIGURE 22: PROPERTY AND PROPERTY ALIAS DEFINITION ...... 42 FIGURE 23: CORRELATION SET ...... 43 FIGURE 24: SAMPLE PROTOCOL ...... 43 FIGURE 25: SAMPLE PROCESS WITH PORTS ...... 44 FIGURE 26: A CLASS , STEREOTYPED “DATA ”...... 48 FIGURE 27: A CLASS , STEREOTYPED “MESSAGE ” ...... 49 FIGURE 28: DOCUMENT /LITERAL WRAPPED STYLED MESSAGE ...... 49 FIGURE 29: AN INTERFACE , STEREOTYPED “INTERFACE ”, WITH OPERATION ...... 50 FIGURE 30: A MODELLED BPEL PROCESS ...... 51 FIGURE 31: A COLLABORATION , STEREOTYPED “PARTNER LINK TYPE ”, DEGENERATE CASE ...... 53 FIGURE 32: CALL BEHAVIOR ACTION , STEREOTYPED “RECEIVE ”, WITH INPUT VARIABLE ...... 62 FIGURE 33: CALL BEHAVIOR ACTION , STEREOTYPED “REPLY ”, WITH OUTPUT VARIABLE...... 62 FIGURE 34: CALL OPERATION ACTION , STEREOTYPED “INVOKE ”, WITH INPUT AND OUTPUT VARIABLES .... 63 FIGURE 35: CALL BEHAVIOR ACTION , STEREOTYPED “ASSIGN ”, WITH FROM - AND TO -SPEC VARIABLES .... 64 FIGURE 36: A SAN, STEREOTYPED << FLOW >>, WITH TWO INVOKE ACTIVITIES ...... 65 FIGURE 37: SAMPLE SHOWING PROBLEM WITH LINKS IN RSM...... 65 FIGURE 38: A FAULT HANDLER , WITH ACTIVITY ...... 67 FIGURE 39: MAPPING OVERVIEW ...... 71 FIGURE 40: SAMPLE RECURSION OVER ACTIVITIES ...... 83 FIGURE 41: SIMPLIFIED UML MODEL STRUCTURE ...... 85

1. Introduction

1.1. Motivation

The Business Process Execution Language for Web Services (BPEL4WS, or BPEL for short) [16] is a language for the specification of business processes. It does not include a generic graphical notation; business processes in BPEL are specified in a textual language based on the eXtensible Markup Language (XML). This is suited as interchange format but it is not very intuitive and requires some in-depth knowledge to specify a process. A graphical notation is desirable, if not needed, to allow an easier way to specify BPEL processes. Commercial BPEL editors are available, such as IBM WebSphere Integration Developer or Oracle BPEL Process Manager. UML is a modelling language and became a widely used language for graphical representation and notation. It is used in many areas of software engineering and thus mostly known to people with a software engineering background. It also offers methods (UML profiles) to tailor it specifically to a certain field of application. Using UML, the BPEL profile can be integrated into the modelling of a complex software system (e.g. with use cases, etc.). It also allows designers to specify BPEL processes using existing UML tooling, which support UML 2.0 and pro- filing, so they would not need BPEL editors for this. UML also could potentially function as a commonly accepted visual language – a lingua franca – for representing BPEL processes. The adaptability of UML is also a deciding factor. New developments (BPEL for People 1, BPEL SPE 2) could be included in a profile and modelled with it. Thus, UML is the language of choice to achieve the goal of graphical modelling of BPEL. This thesis will formulate a UML profile, which supports the modelling of BPEL processes with a UML modelling tool together with the mapping to BPEL. A prototype of the UML profile is implemented for Rational Software Modeler (RSM) with experiences in mapping this profile to BPEL using a transformation framework.

1.2. Scope

The thesis encompasses three aspects. The first aspect is the design of the UML profile itself. With it, we define what UML constructs are used, and how they map to BPEL concepts. This profile should be faithful to the BPEL specification and model all BPEL concepts while also conforming to the UML semantics as completely as possible.

1 http://www-128.ibm.com/developerworks/webservices/library/specification/ws-bpel4people/ 2 http://www-128.ibm.com/developerworks/library/specification/ws-bpelsubproc/

- 11 -

The second aspect is the exemplary implementation of this profile in Rational Software Modeler, a UML modelling software tool by IBM. The profile should be implemented as close to the herein specified profile as possible. Finally, the third aspect is to develop a set of transformation rules to transform the BPEL processes created in UML using the profile into BPEL, and a mapping tool that will implement these rules. The profile in itself is isolated and of limited usefulness. Combined with the transformation it becomes a useful tool to design BPEL processes in a UML-centric environment. The mapping and transformation rules are covered first. They will be defined in an abstract way, so that the they can be reused and implemented in other tools and languages. Then their implementation is covered using a transformation framework.

1.3. Structure of the Thesis

Chapter 2 and 3 give an overview of the relevant technologies. In Chapter 2 BPEL (in versions 1.1 and 2.0) is detailed while Chapter 3 highlights UML. Chap- ter 2 will additionally give a brief overview of technologies surrounding BPEL, such as web services, service oriented architecture, as well as the web service description language (WSDL). Chapter 4 details the specified UML 2.0 profile. This covers the stereotypes, stereotype attributes and constraints of the stereotypes necessary to reflect BPEL. Chapter 5 describes the implementation of the profile from Chapter 4 in the Rational Software Modeler. Chapter 6 specifies the transformation rules for the mapping from UML to BPEL and give implementation details of these rules in a transformation framework. Chapter 7 will give conclusions, summarise the achieved work, and cover future work, including ideas beyond the scope of this manuscript.

- 12 -

2. Business Process Execution Language for Web Services

Previously, there often had been no formally defined, machine-readable business processes in a corporation and no commonly accepted standard had existed for defining them. Over the years, the importance of business processes and the ability to explicitly define and specify them dawned on many corporations. Busi- ness processes were becoming an important part in the workings of businesses, and efficient processes became unique selling propositions that set a business apart from its competition. Increasing co-operation between businesses also necessitated a means of defining business processes across business boundaries. The ever-increasing pervasiveness of computers (and a need for business processes) nurtured the desire to not only define business processes, but also to implement them in software systems. This necessity, combined with technological advancements, paved the way for web service architecture and a common language to describe that architecture. Languages to describe business processes based on this architecture sur- faced, and soon merged to form an open language, the Business Process Execu- tion Language for Web Services (BPEL4WS, WSBPEL as of version 2.0) and is currently being standardised in the OASIS Web Services Business Process Exe- cution Language (WSBPEL) Technical Committee 3.

This chapter describes the underlying concept of web services and a service oriented architecture, then gives an overview of BPEL and a brief outlook to version 2.0 of BPEL.

2.1. Service Oriented Architecture (SOA)

Service Oriented Architecture is a relatively new approach to software architecture. Instead of tightly coupled software systems and components, it focuses on loosely coupled software components – services – that interact with each other over a network. Thus it is not simply a dependent component in a tightly coupled software system, but an independent service that performs a given operation (or set of operations) when this operation is requested. These services form a dis- tributed software system and need not be present on the same computer. Using web services principles, the service could be (physically) located anywhere. [20] [22]

That leads to several concepts. SOA is platform-independent. Using XML as the language of choice does not make any restrictions on the platform services run on.

3 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

- 13 -

SOA services are highly reusable, as they are not part of a rigid structure. They can be combined into complex systems “on demand”. SOA is network-oriented. By its very definition, SOA does not make restrictions where services must be located. They only must be accessible over a network. SOA services are anticipated to be coarse-grain. The number of operations services use is relatively small, but each operation itself can be large and quite complex. [21]

Service Registry

publish find

Service Provider Service Requestor bind

Figure 1: SOA components (from [21])

A Service Oriented Architecture specifies three roles that interact with each other (shown in Figure 1):

• Service provider • Service requestor • Service registry

A service provider offers a service to the world that other services can use. To use a service, the requestor binds to that service. A requestor needs a full service description of that service: what the service offers, how to reach it, and lo- cate that service. When the requesting service only knows what type of service it wants to request, without having the description, it needs to have a way to search for and find a service able to accept its request. This is the purpose of a service registry. The service provider publishes a description of its services through a standardised interface to the service registry; the service requestor then can access the service registry and search for a service provider that fits its demands. Once it locates a service, and has that service’s description, it can bind to that service and use it. Companies provide their own service registries in-house when embracing SOA, as they can be easily fitted to a precise usage scenario for that company. Public registries are available, hosted by several companies such as IBM or Microsoft, and allow the realisation of SOA solutions across business boundaries. [20][21]

- 14 -

2.1.1. Web Services

Web services are a concept that represents a realisation of the abstract concept of Service Oriented Architecture. Various definitions of what a web services are in use. The World Wide Web Consortium (W3C) offers the following definition:

“A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL).” [23]

A web service defines the functionality it provides and the required information that must be met to perform its function. The functionality of the web service can be implemented in any number of ways and languages, but has to conform to the assured functionality; its implementation is completely transparent to the outside. [21] [23]

2.1.1.1. Web Service Description Language (WSDL)

The Web Service Description Language (WSDL) [24] is a W3C recommendation and an XML-based language to describe web services. It is currently available in version 1.1, though version 2.0 is being drafted. It subsumes two previous approaches of description languages by IBM and Microsoft, IBM’s Network Accessible Service Specification Language (NASSL) and Microsoft’s SOAP Contract Language (SCL) ([21]).

A web service definition has several concepts: What a web service offers (port types and messages), how to access it (bindings), and where it is located (ports).

WSDL separates between the abstract interface of a web service and a concrete interface of this specification. The abstract specification consists of port types. A binding then makes these port types concrete.

A port type defines what a web service can offer. It contains a number of (abstract) operations. An operation has input and output and WSDL can realise four transmission primitives, request-response, solicit-response, one-way, and notifi- cation, with them. These inputs and outputs are defined in turn by (abstract) messages. The abstract message defines the format of data a web service accepts and uses XML Schema for type definition.

A binding makes these abstract concepts concrete by binding them to real concepts. It specifies how the web service interacts with its environment. WSDL 1.1 defines possible bindings for SOAP, HTTP, and Multipurpose Internet Mail Ex- tensions (MIME); other bindings are possible, as well.

A port defines endpoints and address, where the web service can be accessed. How this happens is defined by the binding. Service elements offer a grouping mechanism for (related) ports.

- 15 -

Figure 2 shows the WSDL information model and how the WSDL elements are related.

Figure 2: WSDL information model

2.2. Business Process Execution Language for Web Services

The Business Process Execution Language for Web Services [16] is an XML- based language to specify complex business processes for execution based on web services. The language enables a company to specify business processes in a clear and explicit way. They can be implemented and executed with BPEL engines such as WebSphere Process Server by IBM. The advantage of BPEL is that business process definitions can be easily in- terchanged between different tools and runtimes, as the processes are not written in a proprietary language of a vendor. Any BPEL engine will be able to process the process. By explicit definition in a well-defined language and a framework for executing them, business processes can be centrally stored, controlled, and executed.

2.2.1. History of BPEL

BPEL 1.1 [16] is the current version since March 2003. There have been predecessor languages to describe and specify business processes using web services, namely XLANG [26] by Microsoft and Web Ser- vices Flow Language (WSFL) [27] by IBM. BPEL represents an approach to create a unified standard and to coalesce the ideas and concepts of both languages into a commonly accepted language. BEA Systems, IBM, and Microsoft [15] first

- 16 -

proposed BPEL in July 2002 with the initial version 1.0. Currently, WSBPEL 2.0 [17], the successor of BPEL 1.1, is being drafted.

2.2.2. BPEL Technical Overview

The main concept of BPEL is the BPEL process. It uses several concepts. Part- ner links, handlers, variables, correlation sets, and activities for the process logic, which are outlined in the following sections. A process definition does not give any detail about specific location or binding, though, which are necessary before operations can actually be used. This happens at the deployment stage of the process, but is not part of the BPEL specification [16].

2.2.2.1. Process Life Cycle and Types

BPEL processes are typically long-lived and have state. A process is initiated through an initial receive of a message. When the process completes its behaviour, its life cycle ends and is terminated. It can also be terminated by uncaught faults which reach the process scope, or explicitly by the terminate activity.

BPEL can define two kinds of processes: abstract processes (which can be used to specify a business protocol) and executable processes. The BPEL specification defines its core concepts without separating between the two kinds of processes. The specification defines the differences of abstract and executable processes in an additional section. Executable processes are meant to be executed and define a process logic, which will run on a BPEL runtime. Abstract processes specify the external view of a BPEL process, without defining the process logic. If companies would want to share processes, they only need the external specification of the process, but not the exact process logic details.

2.2.2.2. Partner Links and Communication

BPEL processes communicate with partners via web services. The process offers services and uses services from other partners. WSDL port types specify the interfaces between partners. Relationships with partners are defined through partner links, which are typed by partner link types.

Partner Link Type The partner link type specifies bilateral dependencies between two partner roles, but not a real interaction between two partners. Each partner link type defines one or two roles, which are performed by the partners. Each role is typed by a WSDL port type.

- 17 -

Partner link types are a WSDL extension, and defined within the scope of the WSDL definitions for the process.

Partner Link Partner links specify the services the business process interacts with. Each partner link is typed by a partner link type. A partner link defines at least one of the optional “myRole” and “partnerRole” elements. “MyRole” specifies the role that the process itself plays in the relationship; “partnerRole” defines the role the partner plays.

Partners Partner links define a relationship between the process and its partnering services. Complex processes normally encompass more than one relationship between partners. “Partners” is an optional grouping method for partner links to express constraints on “the functionality that a (…)partner is required to provide” [16]. A partner link grouped by a “partners” element may only be grouped by one partner definition.

Endpoint Reference Endpoint references are a concept from outside of BPEL to exchange and communicate dynamically between services using port-specific data. BPEL uses endpoint references to dynamically select a service and use its operations.

2.2.2.3. Data Handling, Properties and Correlation

A stateful process needs means to maintain this state. BPEL introduces variables for this purpose, as well as concepts to query and manipulate them. Variables hold the data that together form the state of the process. They can be scoped and are typed either by an XSD type, XSD element or WSDL message type. To manipulate the variables BPEL has an assignment activity. It specifies copy elements that define the exact copy statement. A copy statement can specify to copy from a variable to a variable, for instance.

Expressions BPEL recognises four types of expressions. General expressions for general computations, Boolean expressions for conditions, deadline and duration expressions for time related issues. BPEL relies on external languages for its expressions. The default language is the XML Path Language (XPath) [28], but other languages can also be specified. If XPath is used, BPEL offers extensions that provide the process designer access to process specific information such as variable content.

Properties and Property Alias Properties are a way to specify globally unique names, which are typed by XSD schema simple types. They do not create a new type, but give an existing type a

- 18 -

specific significance within the process. For instance, an integer itself has no special meaning of itself. But an integer named “account number” has a meaning. Properties are often used in combination with correlations. Property aliases are a way to give part of a message meaning as a property. The property alias specifies the message and part where the property is located, and a query, how that property is extracted.

Correlation A BPEL process can have multiple instances. Whenever multiple instances of a process are running concurrently, there must be a way to identify which of the instances the message belongs to, because the endpoint is the same for the BPEL process (and for all process instances). Therefore, the BPEL runtime must correlate the message to a specific instance. This is the purpose of correlation sets. In a correlation set, a set of properties is listed, which forms a unique identifier for a process instance that can be used by partner activities.

2.2.2.4. Basic Activities

Basic activities cover the fundamental activities a BPEL process can use to specify processing steps.

Partner Activities A process interacts with partners. This is facilitated by the partner activities: invoke, receive, and reply. Invoke activities call operations of partner links, synchronously or asynchro- nously, to perform some work. Receive activities receive requests and start the processing. In a request-response web service, a matching reply sends a result (or fault if the processing was not successful) back to the caller.

Other Activities Wait activities halt the processing for a given time or wait for a specific date before executing. Throw activities explicitly throw a fault. In certain situations, an empty activity may be needed for syntactical reasons or where BPEL syntax requires an activity – and no activity needs to be performed.

2.2.2.5. Structured Activities

BPEL has structured activities that can be used to structure business processes. There are two styles: A flow style with concurrency – the flow activity, and a sequential style of processing.

Switch The Switch statement allows programmers to specify conditional branching. It contains case statements that each realise a different branch of activity and are evaluated in the order they are listed. An “otherwise” statement can be specified that is executed when no case statement was taken.

- 19 -

While The while statement realises loop functionality. It loops as long as its condition holds true.

Pick The pick concept defines a set of events. It awaits the occurrence of one of these events, and then executes the activity associated with it. This is non-deterministic behaviour and cannot be predefined by designers. It can also be used to create new process instances upon receipt of such an event with “createInstance” set to true. It defines two types of events, onMessage and onAlarm events. OnAlarm defines events that occur after a given time or at a given date. OnMessage events await the arrival of a given message.

Sequence A sequence is a construct that will process each of the elements within it sequentially, i.e. one after the other.

Flow Flows realise concurrency of activity, and offer a means of synchronisation. When a flow starts, each activity within it is started concurrently. Links are used for synchronisation of concurrent flows. “Source” and “target” elements denote the start and endpoints of links. As long as the source activity has not yet completed, the target activity cannot start. It is also possible to give the source activity an optional Boolean transition condition. A transition condition determines the state of a link. A transition condition can, for instance, perform a credit check in an ordering process, before the activity to perform the order starts. If the condition is evaluated to true, the link status is positive. If not, it is negative. Join conditions can be specified in all activities that are the target of a link. It checks the status of incoming links (the implicit join condition is the logical OR over the incoming links).

The following example shows a simple flow with links.

- 20 -

flow

someSequence

link invoke AtoB name=“B” invoke … name=“A” …

Figure 3: Link example Figure 3 shows the above example graphically.

Dead Path Elimination In business processes, which use links extensively, large networks form. When a join condition evaluates to false in those cases, the normal interpretation would be that this activity is skipped (the thrown join failure is considered to be locally caught) and outgoing flows get a negative status. The negative status then flows through the net until a join condition evaluates to true or the process completes or terminates. This behaviour is triggered by the attribute “suppressJoinFailure” set to “yes”. The default value of “suppressJoinFailure” is “no”, though. That means that the join failure is thrown and not implicitly caught. This has been done to avoid confusion for users that design processes without such large networks and have no or limited experience with the semantics of links.

2.2.2.6. Scopes and Handlers

Another concept of BPEL is the scope and handlers that are defined for that scope.

Scope A scope is an activity that encloses others to provide a set of variables, correlation sets, event, fault, and compensation handlers for the enclosed activities, to give activities inside it a common context. The BPEL process element itself can be considered a global scope, in which all other scopes are nested.

- 21 -

Fault Handlers As long-living processes, which deal with various services outside the control of the process itself, as well as a complex inner structure, fault handling is of vital importance for the process. BPEL has fault handlers, which are responsible for catching faults occurring in the scope they are defined in and specify activities that should be performed when the fault occurs. When faults have not been caught in the scope, the fault is handed over to the enclosing scope. If it is not caught there, it will be handed over to the enclosing scopes until either a scope catches the fault, or it reaches the process scope and terminates the process.

Compensation Handlers A long-running business process needs a transaction concept that reflects the time scale involved. ACID 4 [31] transactions would not be practical for this. BPEL introduces another concept of transaction to support this: the Long Running (Business) Transactions (LRT). When a process faults, and some steps of work have already been completed successfully, it is necessary to undo these steps – to compensate them. Most steps of work require a dedicated activity, which performs another step of work to undo the already performed task. A compensation handler allows to define such activity.

Event Handlers Event handlers can be defined in a scope to deal with certain events that may happen during execution and are handled in parallel to the normal execution. BPEL knows two kinds of events, onAlarm and onMessage.

2.3. BPEL 2.0

The drafting for the next version of BPEL, WSBPEL 2.0, is currently under development. [17] The current version of BPEL 2.0 has some changes from version 1.1 that are worth mentioning here. For this thesis, and the profile, BPEL 1.1 is the main focus, but the changes and how they influence the profile are discussed in detail in section 5.3 to help outline a possible profile for BPEL 2.0. Among these changes are: • A clarification of the syntax throughout the specification. • Business Partners have been dropped completely in version 2.0. • Scopes can now define their own partner links. • It introduces new activities: repeatUntil, rethrow, and validate.

4 Atomicity, Consistency, Isolation, and Durability

- 22 -

3. Unified Modeling Language (UML)

UML is a graphical language for the modelling of software systems and applicable to many other domains, such as systems engineering, or real-time software, for instance. Over the years, the scope of UML has evolved from a language focused on modelling object-oriented software designs to a powerful design language that enables designers to integrate design with implementation and the modelling of semantically correct models. If modelled precisely enough, a UML model can be used to create code for the modelled system in a programming language, e.g. Java. It is based on the Meta-Object Facility (MOF) 5. MOF is a layered meta- modelling architecture to define modelling languages based on a common foundation. It offers a standard (XML Metadata Interchange (XMI)) to exchange data between models based on MOF. UML in particular is one meta-model instance based on MOF. The UML metamodel specifies the semantics to represent UML models. It also has a graphical notation (including diagrams) associated with it. In this section, the origins of UML and history will be highlighted, as well as the different diagram types. The activity and composite structure, and class diagrams will be described in detail, as they used extensively in the mapping to BPEL. [13]

3.1. History of UML

UML emerged around the time object-oriented software design (OO) came into the focus of software designers. With this new programming paradigm, a need for tooling support of the OO paradigm arose. Starting in the 1970s modelling languages for OO design began to surface, until at one time more than 50 different languages where on the market. When Grady Booch and Jim Rumbaugh unified their respective modelling approaches (the Booch method and OMT (Object Modeling Technique) inside of Rational Software Corporation in 1994, the first foundation had been laid down. When Rational bought the Objectory company, Ivar Jacobson and his method, OOSE (Object-Oriented Software Engineering), where integrated in the approach of Booch and Rumbaugh. This lead to the creation of UML 0.9 and 0.91 in 1996. Several large corporations were quite interested in the UML method, and joined together to submit a response to a Request for Proposal (RFP) the Object Management Group (OMG) issued. This lead to UML 1.0, which upon further clarification and improvements, was accepted by OMG as UML 1.1 in the fall of 1997. UML 1.3 followed 1999, UML 1.5 in 2001. UML 1.5 is an update of UML 1.4, but it did not influence any diagrams. UML 2.0 is the most current state of UML. [12] [13]

5 http://www.omg.org/technology/documents/formal/mof.htm

- 23 -

3.2. UML Diagrams

UML offers several kinds of diagrams to the designer, each with a different focus. Diagrams are grouped into structural and behavioural diagrams.

Diagram

Structural Behavioural

Class Activity

Composite Structure State Machine

Deployment Interaction

Component Use Case

Figure 4: UML 2.0 Diagram Type, overview

Figure 4 gives an overview of the high-level diagram types of UML 2.0. These diagrams are more than just drawings of a software system that have no further meaning. Diagrams are just a way to represent the underlying UML model and each diagram type offers a specific view of this underlying model. Thus, designers can work on the same model, while only concentrating on one aspect of it. Structural diagrams will only give structural information and hide any behavioural information of the model and vice versa. [2] [11]

3.2.1. Structural Diagrams

Structural diagrams model the static structure of a system or component. The static structure describes the relations between objects. They include class, composite structure, component, and deployment diagrams. [2]

- 24 -

3.2.1.1. Class Diagrams

Class diagrams are the diagram types most designers and software engineers are familiar with. Their origin is in the design of object-oriented software systems, their static structure, and the modelling of related object-oriented concepts such as inheri- tance, generalisation, associations, and composition. Class diagrams offer means of modelling classes and interfaces with attributes and operations, as well as the relationships between classes and interfaces. [2]

3.2.1.2. Composite Structure Diagrams

A composite structure diagram allows the designer to give additional structural meaning to classifiers such as class, subsystem etc. It shows the relationship between different parts of a class – its internal structure. It can be used as a standalone diagram type, but also in conjunction with a class diagram. The class diagram has been expanded by the structuredClassifier accordingly to hold additional structural information.

The main elements of composite structure diagrams are collaborations, collabo- rationUses, Parts, Ports, Property, and role bindings.

The parts of a collaboration can connect to each other through connectors. These connections give information about the relationship of the parts. Multiplic- ities can be given on parts and connectors to form complex structures. Addition- ally, parts can be typed with interfaces. A collaboration specifies a complex interaction between elements – the parts – to achieve a given goal. It only focuses on the how, and may leave details out.

Figure 5: sample diagram with class diagram

- 25 -

As an example, consider the following. A car has one engine, and has axles, with a rear part having two wheels. Additionally, an engine can have any number of wheels attached to it. Figure 5 shows a sample diagram of this simple example from the UML superstructure specification using a UML class diagram. Figure 6 expresses much the same, but here the “car” class is a class, which shows information about the inner structure of the class. It has two parts. The “Engine” part specifies a part that is not owned by the class, but only referenced; in UML 2.0, it should be a dashed rectangle, but Rational Software Modeler does not support this. Like the diagram above, it shows a car that has an engine and wheels, but “rear” and “e” are parts of the class “car” – they are forming the inner structure of the “car” class. This specification is only valid for instances of wheels and engine which are part of the car, not for wheels and engines in general. It gives more constraints than the sample in the previous example [2].

Figure 6: sample diagram with structured Classifier (from [2])

A CollaborationUse is a concept, which denotes the use of a collaboration. In earlier drafts of the UML 2.0 specification this was called collaborationOccur- rence. This name does still appear in some other places, such as Rational Soft- ware Modeler.

When a designer wants to apply a collaboration to a specific context, a collabora- tionUse is taken that references the collaboration. The designer has to bind elements to the collaboration parts – the role bindings. For the CollaborationUse to be semantically correct, each part of the referenced collaboration has to be bound by a role binding.

Figure 7: “Sale” collaboration (from [2])

- 26 -

Figure 7 shows a simple collaboration between two parts from the UML specification. It specifies a sales transaction between a seller and a buyer; each sale instance will have a buyer interacting with a seller (additional information about the sales transaction is not shown).

Figure 8: “Brokered Sale” collaboration (from [2])

Figure 8 shows another collaboration, the brokered Sale collaboration. This specifies a more complex sales transaction. It details the relationship between wholesale and retail, both given as collaborationUse of the sale collaboration type. The broker acts as a buyer in the role binding with the wholesale and as seller in the role binding with the retail.

Ports are elements that can be added to classes to define interaction points with the outside. They can specify required and provided interfaces. A required interface is one that the class needs. Without it, it cannot perform its designed task. A provided interface is one that the class offers. It can act as a required interface for other classes.

- 27 -

Provided Class X Interface Port p

Required Interface

Figure 9: Sample class with port

Figure 9 shows a sample class, Class X, which has a port. The port has a provided interface, shown by the so-called “lollipop”-notation, and a required interface, shown by the socket-like notation.

3.2.1.3. Other Structural Diagrams

The other structural diagrams are listed below.

Component Diagrams Component diagrams model component-based software systems of arbitrary size by building a system using components. A component is a classifier, but can also encapsulate other concepts like a package. That makes them complex to model. The component’s internal structure is transparent to the outside; only the interfaces (represented by ports, for instance) are important. The component is re- placeable as long as the provided and required interfaces are unchanged. Thus, the overall system design can be defined on a high level and leaves the design of the actual structure inside a component (as an autonomous unit) to other designers. [2] [3]

Deployment Diagrams Deployment diagrams model the (static) architectural composition of a system at run-time. Deployment means the process of installing a software (system) on a target platform. Its core concepts are nodes, artefacts, and deployment. Nodes represent hardware and/or software resources and can form network structures with the help of communication paths between nodes. Artefacts represent actual piece of information (documents, source code, binary files,…) that are the result of development or the deployment of a system. In deployment, these artefacts are deployed – allocated – on a node. [2][4]

- 28 -

3.2.2. Behavioural Diagrams

Behavioural diagrams allow the modelling of the dynamic behaviour a model expresses. They include activity, state machine, use case, and interaction diagrams. [2]

3.2.2.1. Activity Diagrams

Activity diagrams were introduced to facilitate the explicit modelling of control and data flow independently of objects. Designers can thus model behaviour of a class using that type of diagram. Activity diagrams in UML 2.0 have evolved drastically from their UML 1.5 counterparts. In UML 1.5, an activity diagram was based on the concepts of a state machine that was adapted to allow for a flow-like notation. However, there have also been some problems with activity diagrams in UML 1.5. According to Conrad Bock, “(…)the underlying state machine semantics restrict expressive- ness and is confusing to users. Especially those not using an OO approach per- ceive UML 1.x activity models as not working for them. There is also concern that UML 1.5 has multiple models for control and data flow.” [5]. Conceptually, a state machine is in one specific state at a given time. By its very definition, it does not support parallelism, but the modelling of control flow includes parallelism in many domains. With these problems in mind, the focus was given to the actual modelling of flows and was integrated with the action concept of UML 1.5. With UML 2.0 activity diagrams are based on a Petri-net-like semantic and support parallel execution. [5] [11] Activity diagrams support a range of domains. This is facilitated by a fine- grained composition of packages, each covering a different domain, which designers can choose as they need them.

- 29 -

Activity package structure

Figure 10: Activity Package Dependency [2]

Figure 10 shows the packaging structure and the various sub-packages, which make up the activity-modelling package.

The Fundamental Activities package is the root of the different design approaches and “defines activities as containing nodes, which include actions” [2]. From that point on, the package branches into two different concepts of activity diagrams. Structured activities on the one side, which offer correspondences for structured programming concepts, and basic, intermediate and complete activities on the other side. They offer concepts for a more general programming approach, especially dealing with the control of flows. These different concepts are all orthogonal, meaning that they can be used independently from each other, or used together to make use of several concepts. [2]

The individual concepts are outlined below. Basic activities add control and data flow and simple sequencing of flows between actions. Intermediate Activities include decisions and allow for a concurrent modelling of data and control flow. They support modelling along the lines of traditional Petri-nets with queuing. Complete Actions further add methods to augment the lower model levels, such as edge weights and streaming. Structured activities are used to model a structural design approach, like in programming languages. It adds programming constructs (sequences, loops, conditional statements) to structure activities.

- 30 -

Complete structured activities add data in- and output pins for the above- mentioned programming constructs; thus, they depend on the basic activities package and its flow concept. Extra structured activities further add exception handling and behaviour invocation.

3.2.2.1.1. Activity concepts

The main purpose of activity diagrams is the modelling of behaviour, that is, how a behaviour reacts to input and interacts with its environment and its dynamic processing. Activity diagrams use three different concepts: activities, actions, and flows between actions.

Activities

Activity diagrams describe the behaviour of a system by defining the logic of the system and how information flows through it. To facilitate this, tokens are used. A token is a conceptual representation of data or control information. Activities allow the designer to specify behaviours. Each activity can contain actions and invoke other activities through call actions. It is important to note that this behaviour modelling is based on a Petri-net like semantics. That means that the tokens determine when an activity starts and when it ends. An activity must have a token at its starting point to start. The activity is finished, when the token reaches a defined end state, called a final state. Tokens flow along so-called flows. Control flows transport control tokens (tokens that tell an action it can start) and object flows transport objects and data to actions. Only when both the control tokens and the object tokens are available for an action can it execute. [2] Two types of nodes allow to control the flow of control and data tokens. Control nodes offer basic flow manipulation methods: Join and forking, decision and merging, and initial and final nodes that mark the beginning and end of a flow. Data nodes offer means to hold (store) data tokens. One data node is the data store node and models a copy-like semantic. When a token leaves the data store node, it is copied. Without this, the token would exit the data store node and leave it empty. Another type of data node are pins. They are important because they act as input and output for actions. The action needs input pins to accept the data and output pins to move the manipulated data further onward. Pins also have a buffering capability, where they can hold multiple tokens that wait for processing, and they can be used for the modelling of streaming in- and outputs. [2] [7] [8]

Actions

Activities are just a method of defining behaviours. To actually perform some work (call other behaviours, write to a variable…), they must be resolved to ac-

- 31 -

tions. Actions are only allowed in the context of activity diagrams. There are several groups of actions. [2] [6]

Invocation actions These actions are used to invoke other behaviours. CallBehaviorAction directly calls other behaviour – another activity. CallOperationAction calls operations of classes or interfaces, which in turn can trigger the invocation of other activities. Another part of invocation action is the sendAction. It sends objects – signals – to listeners, which upon receipt of this signal execute.

Read/Write actions These actions make it possible to read from and write to concepts such as objects, links, variables, and manipulate the structure of a classifier. Objects can be created and destroyed by object actions, variables can also be manipulated by these kind of actions.

Computation actions Computation actions transform inputs to outputs by invoking a function. These functions’ behaviours are self-contained.

Activity and Actions A note about naming confusion between UML and BPEL: UML and BPEL both have the term “activity”, but UML and BPEL mean different things. The concept of BPEL “activities” translate to UML 2.0 “actions”. UML itself adds another compli- cation between versions. UML 1.5 has “activities”; the semantic of those is now covered by “actions” in UML 2.0.

Activity groups

Figure 11: Activity groups

ActivityGroup is an abstract class that groups activity nodes and edges.

- 32 -

Nodes and edges can be contained in more than one activity group. This is constrained, though, so that no node or activity is contained transitively by the group’s containing group or sub-group. Another constraint is that groups can only be contained in other activities and groups; all elements within a group must also belong to the activity the group as a whole belongs to. As abstract class, activity group does not get instantiated itself. It also has no inherent semantics of its own. Semantic meaning is added by its three children concepts (cf. Figure 11): activity partition, interruptible activity region, and structured activity node [2].

Activity Partition Activity partitions are one way to group nodes and edges. The most common notation is the swimlane.

A doX

… B doY

Figure 12: swimlane, example

Figure 12 shows an example with two activity partitions, or swimlanes. A common usage scenario is the specification of an organisational structure. A and B could be departments in a company and the actions are part of a workflow, in which these two departments interact.

(A) (B) … doX doY Figure 13: alternative notation

Figure 13 shows an alternative notation for partitions that UML 2.0 offers. Instead of distinct “swimlanes”, the partition is included in the node itself. This helps in situations where swimlane notations are difficult to superimpose on the behaviour. Activity partitions simply offer an additional layer of information for a given behaviour; they do not impose restrictions on control and object flow. In the above example, “doY” would still depend on input from “doX” to start; the partitions just give additional information. UML 2.0 also supports the notion of dimensional partitions. These partitions group other partitions. A dimension “Departments” for instance might group parti-

- 33 -

tions of different departments of a company. UML 2.0 puts a constraint on dimension partitions that way that it is not allowed for dimensional partitions to be contained by other partitions; it acts as a super-partition for all its sub-partitions. The concept is further expanded into multidimensional partitions, which group partitions according to more than one dimension. Figure 14 shows an example of a two-dimensional partition group, where two dimensional partitions, department and location, group the sub-partitions. A person is hired in the HR department in Munich, does some work in the R&D department, which is completed in Berlin, where he leaves the corporation again.

Location

Munich Berlin

Write spec Implement R&D Finish spec Department Hire Fire HR

Figure 14: Multi-dimensional partition group

An activity partition can also explicitly represent an element, such as classifiers and classifier instances, parts, and attribute/value constructs, where the super- partition is the attribute and the nested partitions its values. [2] [9]

Interruptible Activity Region Another specialisation of activity groups is the InterruptibleActivityRegion. It defines a region containing nodes, which can be interrupted. When a token leaves an edge – the “interrupting” edge – all behaviours and tokens in that region are terminated. It can model an exception handling for flow-centric models. An action accepts a signal (the fault to be thrown) and then a token traverses the interrupting edge and by that terminating the faulted section, the interruptible region. Figure 15 shows an example of an interruptible region, albeit a very simple one. Whenever a “Cancel Order” is received, the token will leave the region via the interruptible edge (marked with a lightning bolt), and the whole region is terminated. [2] [10]

- 34 -

Cancel Undo Order order

Receive Process invoice Order Order

Figure 15: Example with interruptible region

Structured Activity Node The structured activity node (or SAN) is the third specialisation of an activity group. It also inherits from Action and ExecutableNode; thus, a SAN is an executable node, which can have nested actions and other SANs. Other node types may not contain nested nodes, so the SAN is unique in that perspective. It is notated as a dashed rounded rectangle with <> written inside it. A SAN starts when all its incoming edges hold tokens, just as a normal action does. The actions inside the node start as soon as the enclosing SAN starts. Ex- plicit initial nodes are not necessary. UML specifies that all actions without incoming edges get a control token as soon as the enclosing behaviour or activity starts.

Figure 16: Structured activity node, with control and object flow

Figure 16 shows a SAN with incoming and outgoing object and control flow. The inner details of the SAN are not shown. Semantically, this means that the SAN as a whole may only start when the control and object tokens arrive, and when it has completed, it will offer tokens to the next action in the processing. There are explicit semantics for control and object flows reaching and leaving the SAN as a whole. But should a designer feel it necessary to have outgoing or incoming flows (cf. Figure 17) to actions inside the SAN (a go-to like semantic), the UML 2.0 specification offers no definite ruling.

- 35 -

? doX doY

Figure 17: Structured activity node with outgoing flow from inside

The opinion on the semantics of cases as the above seems to be wide open, and the UML 2.0 specification may be ambiguous out of choice rather than neglect. Conrad Bock says in [10], that “SANs do not enforce well-nested flows.” That means to say that it is fully permissible to have flows going out from within SANs, as well as flows targeting actions within the SAN. The author goes along with this school of thought, as exactly this semantic capability will be of importance in the modelling of BPEL links.

SANs also support the concept of isolation. By setting the property "mustIso- late" to true, conflicting access to objects within the SAN by actions outside of it is forbidden. Atomicity is not covered by this property, though.

To support programming structures, UML introduces concepts, which inherit from structured activity nodes. These are sequence nodes, conditional nodes, and loop nodes. Unfortunately, the UML 2.0 specification does not offer any graphical notation for these constructs. [2] [6]

Sequence node Sequence nodes are simple concepts. They implement a sequential processing of ordered activity nodes contained therein.

Conditional node Conditional nodes enable the designer to model conditional concepts like if-then- else of programming languages. They contain at least one clause, which consists of a test section and a body section. When the conditional node starts, the test sections are evaluated. The test section thus determines whether a body section is executed or not. If more than one test section evaluates to true, it is non-deterministic which body section will ultimately be executed. To avoid this and enforce a deterministic behaviour, the clauses can be ordered (using predecessorClauses) so that the clauses are

- 36 -

checked one after another. Else-clauses can also be specified using a test clauses that always evaluates to true and is successor to all other clauses. It may be the case that no test evaluates to true and thus no body section is executed. This is a problem should following nodes require an output from the conditional node. To avoid this, the isAssured property can be specified, which assures that at least one test section will always evaluate to true. The isDetermi- nate property assures that the conditionalNode is determinate, meaning that at most one body section is evaluated. Note however, that these are only assur- ances by the modeller. They are not enforced by the model.

Loop node Loop nodes make it possible to model repeating concepts, like repeat-until, for, or while of programming languages. It consists of three parts: the setup part, the test section, and the body part. The setup part is used to prepare data for the loop, initialises data and other setup processing; it is called only at the first execution of the loop node. The test section decides if the loop is to be executed or not; it is called repeatedly after each execution until it evaluates to false. The body section finally holds the actions that are executed with each loop and offers command and/or object tokens to its successors at each repetition. The test section can appear before or after the body section. This is specified by the isTestedFirst attribute. If it is true, the loop node has a while-like semantic, whereas the attribute realises a repeat-until-like semantic when set to false.

Expansion Regions An Expansion Region is a special kind of structured activity node, which realises a “for each” semantic. It has a special kind of input and output pins – expansion nodes – that hold collections of inputs and outputs. The region is executed for each element in the collection and offers three types of execution: parallel, where execution happens in a parallel way; iterative, where an execution must complete before the next can start and thus work its way through the collections iteratively, and finally streaming mode, where the region accepts data in a stream, and will create a stream as output.

3.2.2.2. Other Diagrams

Apart from activity diagrams, there are other diagram types for dealing with behavioural modelling. They do not feature in this profile and are outlined shortly.

Use Case Diagrams

Use cases are a widely known methodology to specify the actual usage of a software system.

- 37 -

The main concepts are the actor and the use case. An actor represents an entity (a human user, external hardware…) that interacts with a use case. The actor is not a physical unit but a representation of a role that entity plays. A use case details how a desirable result, which are of interest to the actor, can be achieved through a set of actions. For instance, the closing of a software is a (simple) use case, where the person closing the software is the actor. [2]

Interaction Diagrams

Interaction diagrams specify how elements interact with each other. It might model the sequence in which operations are called, or what classes exchange messages with each other. UML 2.0 provides a set of sub-types of diagrams that are tailored for certain aspects of interactions. These are sequence diagrams, interaction overview, communication diagrams, and timing diagrams. Sequence diagrams model how a given system operates; that is, a sequence of events and messages sent between objects to facilitate the goal of the system. Interaction overview diagrams have some semblance of activity diagrams, but focuses on events instead of actions. It models complex interactions by looking at control flows, i.e. flows for normal processing, alternative flows, and error cases. Communication diagrams were known in UML prior to version 2 as collaboration diagrams. They model the message flow between instances: who sends what to whom and in what order. Timing diagrams are used to show and model timing issues of objects. They model how long objects are in a given state, and when the state changes. [2]

State Machine Diagrams

Finite State Machines (FSM) 6 originated in the automata theory and are a method of modelling behaviour using transitions and states. With the State Machine Diagrams, UML 2.0 offers a way to model state machines. The main concepts of a state machine are the states and transitions. The state is a distinct condition the state machine is in at a given time. Transitions are direct relations between states. When a transition fires, the state machine moves from a state through the transition to a follow-state. When the “exit” button is clicked in a software system for instance, a transition fires in a fictive underlying state machine and the state machine moves from a “wait for commands” state to an “exit” state (a final state in this case, after which the state machine terminates). There are two sub-types of diagrams: protocol and behavioural state machines. [2] Behavioural state machines model the behaviour of a system. Protocol state machine only model a usage protocol; it deals with legal transitions and what are permissible sequences - what happens in the state is of no concern. [2]

6 http://en.wikipedia.org/wiki/State_machine

- 38 -

3.3. UML profiles

With profiles [2], UML offers a way to tailor the language for use in a specific domain. It subsets and extends the UML metamodel and allows to customise UML with stereotypes, stereotype attributes, and constraints. Any number of profiles can be applied to a UML model. The profile for software services [19] introduces a profile tailored to the design and specification of software services; there are also profiles tailored for .NET or J2EE, or real-time system design.

A profile defines a set of stereotypes and the UML elements they extend. Stereo- types can also use generalisation and specialisation, but only between stereotypes. Additionally, stereotypes can have attributes to further enrich the stereotype with information (also referred to as “tag definitions”). Stereotype attributes are part of the stereotype and applied to a UML element every time the stereotype is applied (when they are applied, they can be referred to as “tagged values”). They are linked to the stereotype and when this is removed, the stereotype attributes will also be removed. Further semantic is added by constraints which can model additional restrictions or conditions that the stereotyped element must conform to (e.g., a constraint might say that a class must have exactly one attribute). Constraints can be given through the Object Constraint Language (OCL) [14], which is a language for specifying constraints and relationships between UML elements and is integrated into UML. Tools can also offer additional methods to define constraints, such as Java classes in Rational Software Modeler. Each constraint is applied to the UML element alongside the stereotype and can be used to validate the model.

There are three ways to give the stereotype attribute types (non-typed attributes are ignored in some tools, like Rational Software Modeler): • Imported “simple” types from model libraries (uml, ecore, Java simple types). • Enumerations of custom-defined types in the profile itself. • And classes defined in the profile.

- 39 -

Figure 18: Stereotypes sample diagram (from [19])

Figure 18 shows a section of the software service profile diagram [19]. Service Partition and Service Provider both are stereotypes, and extend the metaclass Class. A constraint is defined as well, and restricts the Service Partition to the inclusion of Service Providers. The Service Provider stereotype also shows two stereotype attributes associated with it.

Figure 19: Profile package, abstract syntax (From [2])

Figure 19 shows the abstract syntax of UML profiles. A profile is a specialised package and can import other profiles if necessary. A profile contains Stereo- types. Each stereotype references a class. That is the metaclass the stereotype extends; it also may have an icon, so that a stereotype can have a unique icon in a graphical tool, which sets it apart visually from the underlying class.

- 40 -

3.4. UML 1.4 Draft Profile for BPEL 1.0

A draft UML profile for BPEL [1] was published in June 2003. It was based on UML 1.4 and mapped to BPEL 1.0, though it already included some changes to BPEL 1.1 (such as the using “variables” for the naming of variables, and not their BPEL 1.0 equivalency as “containers”). While it was based on UML 1.4, it did also include some hints to changes UML 2.0 would bring and how they might be used to replace the UML 1.4 concepts in the draft profile. The profile covers most of the BPEL 1.0 specification. The mapping will be outlined here according to the mapped BPEL constructs. After that, its issues and missing parts will be highlighted, as well as the parts that still are applicable.

3.4.1. Dependency Management and packages

To support namespace management, the profile uses packages. A package hierarchy maps to an XML namespace hierarchy. The model name itself as the top- level package contributes to the namespace. The target namespace is given at deployment. Packages that contain WSDL or XSD concepts are mapped to files of the corresponding .wsdl and .xsd types. For each BPEL process, a BPEL file is created and there typically is one BPEL process per package. If there are multiple BPEL processes in a folder, multiple BPEL files are created. If models depend on elements, such as data types for instance, that are already defined outside of the model itself, they are referred to as “external” packages and no artefacts are generated from these.

Figure 20: package import structure

Figure 20 shows such an import scenario. The PurchaseOrderProcess package contains the BPEL process, and imports the package purchase, where messages and such are defined. This package in turn imports the package Purchase- DataTypes, which contains the data types used in the scenario.

- 41 -

3.4.2. Data Types and Interfaces

Data types and messages are modelled using classes, which are stereotyped <> and <>. Each <> class maps to an XSD type, the attributes making up the types the complex type is constructed of. <> classes are mapped to WSDL messages. Complex data types are connected to the message using a composition aggregation; in case of purely simple types, the WSDL part name and type can be given as an attribute of the message.

Figure 21: Message with data

Figure 21 shows a message, scheduleMessage, which consists of one WSDL part. The name of the part is given as the role of the composition; the type is given by the class name of the data class.

WSDL port types are mapped using interfaces. Each operation of the interface results in a WSDL operation.

3.4.3. Properties and Correlations

BPEL properties are modelled using classes, which are stereotyped with <>. That class acts as a container for the properties and has no additional meaning; it can be named arbitrarily. The attributes of that class make up the BPEL properties. Property aliases are modelled as operations in that class. The name of the operation is the property alias name, and takes the message to extract the property as input parameter. The extraction query is added to the operation as an XPath expression.

Figure 22: Property and Property Alias definition

- 42 -

Figure 22 shows a set of properties and two property aliases for each of the properties.

Correlations sets are modelled as classes stereotyped with <>. The name of the class is the name of the correlation set, and the attributes specify the properties the correlation set uses.

Figure 23: Correlation Set

Figure 23 shows such a correlation set, CorrelationSet1, which uses two properties to correlate a message. How correlation sets are used by processes, see the Process section.

3.4.4. Partner Link Types

The profile maps partner link types using packages, stereotyped <>. The roles of a partner link type are modelled by using <> stereotyped classes.

<> Protocol1

Interface1 <> <> <> Role1 Role2

<> Interface2

Figure 24: Sample protocol

Figure 24 shows a sample protocol from the profile. The protocol – the partner link type – consists of two roles, Role1 and Role2, and two interfaces, interface1 and interface 2, where role1 provides interface1, and role2 interface2, accordingly.

- 43 -

3.4.5. Process, State, and Ports

A BPEL process is modelled as a class stereotyped <>. Its state, i.e. the variables, are modelled as attributes of that class. As the profile only supports executable processes, the attribute abstractProcess is set to “no”. Partner links of a process are modelled as composition associations, stereotyped <>. The role offered by that port is modelled as a class, stereotyped <>, which is the target of the association. Each of the role/port combina- tions are mapped to BPEL 1.0 partner constructs. In the modelling of process logic, referenced partner links are modelled as partitions (“swimlanes”) and the activities (see below) are located in the swimlanes accordingly.

Figure 25: sample process with ports

Figure 25 shows the BPEL purchaseOrder example in the notation of the profile. This way of modelling can obviously get more complex the more partners a process has.

3.4.6. Data Handling

The profile uses XPath exclusively as language to model data handling. As XPath is used, it takes advantage of the special extensions for XPath BPEL offers. General expressions in the model are mapped thusly. Boolean, deadline-, and duration-valued expressions are mapped one on one from XPath to XPath. Assignment is represented as a “:=” operation between general expressions. The assign activity is mapped to an <> stereotyped UML 1.4 activity, its entry action specifying the intended copy action.

- 44 -

3.4.7. Basic Activities

Basic activities are modelled using the UML 1.4 activity concept. The Invoke activity is mapped as an <> stereotyped UML activity, and has an entry action that specifies the operation to be invoked and an attribute specifying the input message. In case of a two-way message, the attribute that is updated with the reply message is given using the assignment notation (see above). The receive activity is mapped as a <>stereotyped activity; its entry action specifies the operation that is expected to be called, and an attribute defining where to put the input message. The reply action is mapped accordingly, stereotyped <>. The entry action of the reply activity has the same operation, but instead of an attribute to specify the input message, it uses the assign notation to specify the message that is being sent as a reply. BPEL throw activities are mapped as stereotyped <> UML activity, with its entry action specifying the fault name that is thrown. Additional exception data – the fault variable - can be given as an attribute. Terminating processing is mapped as a UML final state. BPEL waiting is mapped to a UML activity, as well. The stereotype is <> and the entry action specifies the time expression, either for or until.

3.4.8. Structured Activities

Control flow is mapped with UML (optionally guarded) control links. To model a hierarchical structure, activities can be nested inside other activities. To determine complex control structures, such as sequence or flow, the profile introduces a heuristic approach. Activities with a common direct parent that have interactions with the same partner and can be placed in a sequence, are placed in a sequence. Other elements, which are not grouped in a sequence, become top level activities in the flow. This heuristic is performed anew for each level of nesting; an explicit notation for sequence or flow is not supported by UML. BPEL switch statements are modelled using a combination of decision nodes and corresponding merges. The guards on the outgoing links from the decision node select the path to be taken, that is, which switch case is executed. A named otherwise models the otherwise statement of switches. After the decision node (the cases) has selected one and executed it, all links merge and “exit” the switch; the next activity is called. A BPEL loop statement is modelled as an activity stereotyped <>. It contains one decision node, which has one outgoing link to an (nested) activity, which has a guard specifying the loop condition. A BPEL pick is modelled by using a decision node, which is stereotyped <>. Its outgoing links connect to activities stereotyped either <> or <>. The profile does support a notation using nested activities to model a pick statement.

- 45 -

3.4.9. Error Handling

The profile also deals with BPEL error handling. Fault handlers are modelled by <> stereotyped activities and their entry action specifying the error, which is caught, and an optional attribute specifying the fault variable. The action to be taken in case of an error is either nested inside the <> activity, or pointed to by a control link if using a hierarchical structure to model control flow. Compensation handlers are modelled by using <> stereotyped activities. The activities that are performed in case of a compensation are nested inside the handler. Compensation is called by a <> stereotyped activity.

3.4.10. Issues

As a draft version, it is natural that the profile still has some open issues left. These issues are addressed in this profile.

The profile leaves out several important BPEL concepts. It has neither a defined mapping for BPEL scopes, nor an explicit way to specify scopes. Enclosing activities can be considered such scopes, when they contain fault or compensation handlers, but this is not further specified by the profile. Moreover, while there is a notation given for compensation handlers, no mapping details are given for them in the draft. Another missing concept is events, as well as event handlers, which were introduced with 1.1. In cases where events are needed, like in the pick concept, there should be onMessage and onAlarm events rather than receive and while activities in the draft profile. Although a receive and onMessage share most of the semantic meaning, there are some differences. A receive can directly create a process instance (with the createInstance attribute) and has the standard attributes and elements of activities. OnMessage events do not have these elements or capabilities, but the pick activity that contains them. OnAlarm events and while activities have the definition of duration or deadline time expressions in common, but the onAlarm event includes an activity to be executed at the time of the alarm, while a wait is just used to wait for the given time. The missing sequence and flow constructs also put some burden on the designer of a BPEL process, as he has to rely on a heuristic approach; it takes away the possibility to model a control flow explicitly as he sees fit. It is also the question how good this heuristic approach would work for complex and large models. The empty activity is also not modelled. The profile makes extensive use of UML 1.4 activity and activity diagrams. These concepts have been changed extensively with UML 2.0. The old activity concepts, while having some benefits of their own (entry actions on activities for instance), have some limitations.

- 46 -

The notation for processes and ports suffers from the lack of a conceptual method to define ports. The adopted notation in the draft profile is quite complex, especially for processes with many ports, and lacks a certain intuitiveness. The modelling of partner link types is another issue. The modelling with packages and enclosed classes and interfaces is not very intuitive and quite complex.

3.4.11. Reusable Profile Concepts

While the profile has issues, it also defines concepts that are still useable in the new profile. • The modelling of namespace hierarchies using packages is still applicable. As is the modelling of messages and data types with classes. The definition of port types using interfaces is another reusable concept. • Properties, property aliases, and correlation sets can also be modelled using the concepts of the draft profile. • The modelling of process logic with activity diagrams is also still useable, though only in name, as the actual changes from UML 1.4 to 2.0 preclude a conceptual re-use.

- 47 -

4. UML 2.0 Profile for BPEL 1.1

This section will define a UML 2.0 profile for BPEL 1.1. Based on the previously discussed UML 1.4 profile, it will expand or modify it where necessary and add new concepts and solutions. The truthful representation of BPEL is the guiding principle. UML models also have an underlying semantic and the correctness of UML is an important factor. There can be cases when a semantically correct UML approach to a BPEL concept would be complex and reduce the clarity of the diagram. In those cases, the BPEL correctness is chosen over UML semantic. The reasoning will be explained where this happens.

This chapter will give a detailed overview of the profile and the reasoning behind it. Section 4.1 will highlight the reused concepts, while Section 4.2 shows the concepts that are new in this profile.

4.1. Concepts adapted from previous Profile

The previous profile has used several ideas and concepts that are still applicable and can be reused for a new profile, with adaptations to UML 2.0 in some cases. The concepts without changes are data types, correlation sets. The concepts with adaptations are namespace hierarchy, , messages, properties and property aliases, port types, and the process and variable definition.

Namespace hierarchy The modelling of a namespace hierarchy with packages is intuitive and can be achieved in UML with packages and imports and thus reused for this profile. An adaptation from the previous profile is that the target namespace for the process is now given through a stereotype attribute of the process class itself, rather than during the mapping as in the previous profile.

Data Types and Messages The modelling of data types and messages as classes is easy and straightforward and is taken over from the previous profile with adapations. Each message class is mapped to one WSDL message in a direct, one-to-one way. Data type classes are mapped one-to-one to XSD complex types and the contained attributes to elements of this complex type.

Figure 26: A class, stereotyped “data”

- 48 -

Figure 27: A class, stereotyped “message”

An adaptation of the concept is the inclusion of another binding style of messages in the profile, the document/literal wrapped style. Using this style, each WSDL message has exactly one part acting as a placeholder, and the type of this part encapsulates the actual parts.

Figure 28: Document/literal wrapped styled message

Figure 28 shows an exemplary message using this style. The presentation is no different from other messages, except that the stereotype is now <>. For each such message, the mapping will create an XSD complex type. The name of hat type follows the following convention: message name + “parameters”. This complex type will then contain all the attributes of the class as elements in a sequence. One WSDL part then references this type, its name is the name of the message as defined in the UML class. This is not quite correct for this binding style. The name of the message should depend on the name of the operation the message is used in. This is not easily doable with the current approach for messages, which are defined independently from the operations they are used in. So this approach is chosen.

The XSD would look like this

while the WSDL message would look like this:

- 49 -

A <> stereotyped class would map to this:

Properties and Property Aliases This concept is taken over from the previous profile, with adaptations in property aliases. The query that holds the statement to extract the property from a message is included in the stereotype. The operations that define the property aliases are stereotyped with a <> stereotype, which has a stereotype attribute “query”. The specification of the query depended on the actual tooling used in the previous profile (it gave tool tips for Rational Rose and Rational XDE). By adding that stereotype attribute, the profile is independent from a given tooling (as long as the tooling supports UML 2.0 profiles, including stereotype attributes) and an integral element of the profile. A properties class must have at least one attribute.

Correlation and Correlation Sets These concepts were taken over from the previous profile. Each correlation set must have at least one attribute and this attribute must refer to a property of the process. To correlate individual invoke, receive, or reply activities, a different approach is taken and will be detailed in the related section about these activities.

Port Types This concept is taken over from the previous profile with a small adaptation. The stereotype is named <> instead of <> to align with the profile for software services [19] and WebSphere Integration Developer. By defining the WSDL operations as UML operations the action that models the invoke activity (a callOperationAction), can directly reference the operation. A constraint is that it must have at least one operation.

Figure 29: An interface, stereotyped “interface”, with operation

- 50 -

Process and Variables These concepts were taken over from the previous profile with adaptations. The class now is a structured classifier and includes partner link definitions. This leverages the possibility of structured classifiers to include structural information and makes the definition of partner links less complex and more intuitive. The attributes of a process can be given in the profile using stereotype attributes. This elements are name, targetNamespace, queryLanguage, expres- sionLanguage, suppressJoinFailure, enableInstanceCompensation, and ab- stractProcess. The previous profile used fixed values for these attributes.

Figure 30: A modelled BPEL process

Figure 30 shows a sample BPEL process as modelled using the profile. In the upper section of the class, the variables are mapped. The lower section shows the partner links of the process inside the structural section of the class.

- 51 -

A constraint is that variables must only be part of a process class.

4.2. New Concepts

This section shows the new concepts of this profile, which draw from the addi- tions and changes of UML 2.0. Most of these changes cover the process logic – the actual BPEL activities. The previous profile used activity diagrams, and so does this version. The changes in activity diagrams from UML 1.4 (1.5) to UML 2.0 are significant and make it necessary to define a completely new approach.

Partner Link Types and Partner Links The modelling of partner link types in the previous profile with packages, classes, and stereotypes was complex and not very intuitive to use or read. With Collabo- rations, UML 2.0 offers an easier and more intuitive approach. A partner link type is represented by one collaboration stereotyped <>. It has exactly two parts, which may be typed with the stereotyped interface for a port type. Each part represents one role of the partner link type. At least one of the two must be typed. A constraint is defined to verify that every <> stereotyped collaboration has exactly two parts. A partner link is represented by a collaborationUse stereotyped <> in the process class (a structured classifier) and typed by a partner link type. For each partner link there exists a port in the process class that has a role binding to the collaborationUse. This port represents the “myRole” role of the partner link. A stereotype attribute “endpointReference” allows to attach an endpoint reference to the partner link. A constraint is defined that <> stereotyped collaborationUses must be part of a <> stereotyped class.

This approach has not only advantages, but also some drawbacks. It violates UML semantics, as a collaborationUse must bind every part of the collaboration it uses. This profile only binds to one part: the “myRole”. Thus, any validation will report this as an error. While the profile should be as semantically correct as possible, it also should be easily understood and used. The modelling of “myRole” directly in the process as port makes sense – it represents the functionality the process itself offers to the world, after all. Adding a second port to represent the “partnerRole” for sake of semantic correctness of UML would not only further clutter the diagram, but also obfuscate the meaning of a “partnerRole”: that it is the role a partner offers. Adding it to the process could be misconstrued as a service the process itself offers.

The reason for this stems from the possibility of degenerate cases of partner link types. In case of normal partner link types with two roles, the above approach is trivial; a role representing myRole is always present.

- 52 -

A degenerate case has one role only. It would have been intuitive to simply model this as a collaboration with just one typed role; but there is a problem with this approach when modelling partner links and ports: when the role is the “part- nerRole”, the port of the process would represent the “partnerRole”, something that is not correct in BPEL meaning (a BPEL process does not offer a partner role). Therefore, the partner link types always have two roles. In normal ones, both are typed, in degenerate ones, only one is actually typed while the other is not – it is all but a purely client role.

Figure 31: A collaboration, stereotyped “partnerLinkType”, degenerate case

The main reason for this approach is that other approaches would have cost readability and consistency. To further increase readability (and to differentiate “empty” “myRoles” from real ones, the real port can be typed with the port type. In UML, this means the port type is the provided interface of this port and shown in the diagram using the “lollipop” notation.

Partner links play an important role in activities and the process logic. The profile uses activity partitions to represent the partner links for invoke, receive, reply etc. The representation is formalised through the “represents” attribute of the activity partition. The name of the partner link is also used as name for the activity partition to make the applied partner link more visible.

The swimlane notation for activity partitions is usable for some scenarios but there are also instances where swimlanes would not be practical, especially when sequences or flows cover several (or all) partner links. That would mean graphically spreading them across all the swimlanes, which would only obfuscate the evident meaning of the diagram. Where appropriate, the swimlane notation can be used. If this is not practicable, the alternate notation for activity partitions should be used.

An important task of any BPEL profile is naturally the modelling of the process logic, how a process performs its operations. First, we detail the modelling of simple BPEL activities, and then the structured activity components and finally scopes and the different handlers.

- 53 -

Activities For the “name” and “suppressJoinFailure” elements of BPEL activities, the profile uses stereotype attributes. “Name” is not used as the name for the UML action as “name” is only optional for the BPEL activities. The application of these stereotype attributes could be realised using the generalisation of a common stereotype for activities, or, as implemented in the profile, as stereotype attributes for each activity. “joinCondition” as the third standard attribute is modelled as a local precondition of the UML action itself; this means – informally – that the join condition has to be true before the action can execute, and has the additional benefit, that this join condition is directly linked to the action. The standard elements of BPEL – target and source tags for links – are modelled by incoming and outgoing control flows of an action. These control flows are stereotyped <>, and may have a guard expression. That guard expression is used to specify the optional transition condition of the link.

The approach for join conditions has a problem. UML 2.0 semantic says, that actions can only execute when all the incoming flows have tokens, meaning that they are “true”. Local preconditions do not change this fact, as they are considered when the action starts executing, not before [2]. The UML 2.0 approach that would actually conform to the joinCondition meaning would be to put a join node before each action, which models the join condition. Understandably, this can lead to some graphical overhead, and so the precondition approach is chosen as the modelling choice, but with the knowledge that it only acts as a simplification of the join node approach. That holds for any modelled BPEL activity mentioned in the sections below.

Now that the standard elements and attributes have been covered, the activities themselves will be detailed.

Simple Activities Simple activities are modelled by stereotyped UML actions. To facilitate the profile, it uses several types of actions. Opaque actions, invocation actions, and actions for signalling.

Receive/Reply Receive/Reply modelling makes use of the signalling concept of UML 2.0. Basi- cally, a receive activity waits until it is called and, in case of synchronous calls, sends back a reply. UML 2.0 offers two actions, acceptEventAction and sendSig- nalAction to facilitate this concept. They are stereotyped <> and <> respectively. Receive and reply actions receive or send a variable trough an operation of a port type. This is modelled as noted above by activity partitions. The acceptEventActions accept special signals. These signals encapsulate the operation, the input, and output and are listed as the triggers of these actions. A reply can only be used when a matching receive is present.

- 54 -

Invoke An invoke calls an operation trough a port type. A callOperationAction can be used for this and so directly reference the operations specified in the <> interface. The input and output variables can enter and leave this action through input and output pins. The variables are identified by the name of the pin. The object flow from or to the actual variables is assumed to be modelled by read/writeVariable actions and data stores, but is left out of the diagram alto- gether to increase readability; having control and object flows in the diagram that have no explicit relevance to the modelling of a BPEL process (and only model an implicit concept of BPEL) should be avoided to keep the diagram clutter-free.

Invoke activities can have inlined fault handlers and compensation handler. This will be handled by an interruptible region, stereotyped <>. Ac- ceptEventActions are used for each catch statement of the inline fault handler, and have outgoing edges to activities outside the region, thus matching the behaviour. An AcceptEventAction that is stereotyped <> does the same for the compensation handler of the invoke activity. Conceptually, this is a reuse of the concept for specifying fault and compensation handlers on the scope-level.

Correlation Sets Invoke, receive, and reply activities and onMessage events all have the option to reference correlation sets. To model this, the profile introduces a <> stereotyped precondition on the UML action. This precondition then defines a correlation set the activity uses. A Boolean stereotype attribute “initiate” will determine whether the value “initiate” is set to yes or no and the attribute “pattern” will determine the pattern used by the invoke correlations element. A constraint is that this stereotyped precondition is only allowed on invoke, receive, reply activities and onMessage events.

Wait The wait activity is modelled as a special AcceptEventAction stereotyped <>. The accepted time event specifies the time expression that the wait should wait for or wait until. A constraint is that the AcceptEventAction only accepts time events.

Assign The assign statement is a special case. It uses an opaqueAction stereotyped <>. An opaqueAction allows to enter specific code in it. The body part of it contains the handwritten copy statement(s) of the assign, and the language specification would be “BPEL”.

- 55 -

Throw The throw activity explicitly throws a named fault. In UML, we use a <> stereotyped SendSignalAction for this, with the signal being the thrown fault (fault message and optional fault variable).

Empty The empty activity is just an action, named “empty”, stereotyped <>, so the standard elements and attributes still can be applied if desired.

Terminate The terminate activity is an ActivityFinalNode, which has the stereotype <>, so the terminate activity can, if necessary, be given the standard elements and attributes.

Structured Activities With structured activity nodes, UML 2.0 offers a concept that support BPEL structured activities.

Sequence BPEL sequences are modelled as UML sequence nodes, which is stereotyped <>. They cover sequence semantic “out of the box” and no further adaptation has to be made. The nodes inside the sequence node are considered in the order they are specified.

Flow BPEL flows are modelled as UML 2.0 structured activity nodes, stereotyped <>. Contained actions and/or structured activity nodes are started concurrently with the <> structured activity node. Links are modelled by control flow between actions stereotyped <>. Transition conditions of links are modelled by UML guards of the control flow, while join conditions are modelled with help of local preconditions on the action itself.

The semantic of initial nodes [2], which are needed for UML semantic correctness, allow for a BPEL-like semantic, as they can be assumed implicitly in case of activities without incoming edges. These activities get started as soon as the enclosing activity starts. In case of a flow, that means as soon as the flow is en- tered.

As has been mentioned in the UML introduction, the UML specification has chosen an open mind regarding flows and structured activity nodes. For BPEL links to work, we must have flows entering and leaving structured activity nodes from outside the node itself. Should future UML versions decide that this is no longer possible, alterations to the link modelling must be made.

- 56 -

Dead Path Elimination (DPE) is difficult to model with the activity diagram of UML 2.0. The problem comes from the conceptual differences between a Petri-net-like semantic and the flow model of BPEL. The implicit join property of the UML actions – that all source actions with outgoing flows to a target action need to offer tokens through flows before execution can begin – means that when the transition condition of an incoming flow (the link) has evaluated to false, no token would be offered. The target action would thus not be executed and not generate an output. No action, which has an incoming link from this action would ever execute. Thus, the given token semantic does not allow for dead-path elimination. However, we can define a special kind of token through an extension: a fault token. When a transition condition evaluates to false, instead of transferring no token at all, the join node modelling the join condition would then send a special fault token. This token would then represent a negative link status when moving along the flow through the model until it reaches a join condition that evaluates to true and the token is destroyed. This covers a dead-path elimination-like semantic [2].

While The while activity can easily be modelled with a <> stereotyped loop node of UML 2.0. A loop node already covers repeating behaviour. To have a while- like semantic instead of a repeat-until semantic, the attribute “isTestedFirst” has to be set to true, which means that the test section of the node is executed before the body part.

Switch The switch activity is modelled by a <> stereotyped conditional node. Each section – the clause – of the conditional node maps to a BPEL case statement. An “Else” clause covers the “otherwise” statement of the switch. A constraint is that the attribute “isDeterminate” must be set to true. This shows that only one section of the conditional node will ever execute (though this attribute cannot be assured by UML itself, it is only asserted by the designer).

Pick A pick activity is mapped as a <> stereotyped interruptible region. The attribute “createInstance” is added as a stereotype attribute. Each action without any incoming edge is mapped to an event. For the onMessage and onAlarm events, consider the following section. Once an action within the region executes, and tokens leave the region by the interrupting edge, all activity within the region is terminated, thus following the pick semantic. It has a constraint that it may only contain (at least one) onMessage or onAlarm events.

Handlers

- 57 -

There are three types of handlers to consider: fault, event, and compensation handlers. They do share a common idea. When we consider the handlers to be actions that react to certain events, faults for the fault handler, onMessage or onAlarm events for the event handler, the acceptEventAction of UML 2.0 is a logical solution for this.

Fault Handler The fault handler is a <> stereotyped AcceptEventAction at the top-level of the related scope it belongs to. This can either be the activity scope itself, or a structured activity node in case of a BPEL scope. Its name is the fault it catches, and accepts signals that are identified as faults. In case of the catchAll part of the fault handlers, the action is simply named “catchAll”. The activity the fault handler calls in case of the fault is specified by an action that is connected through a flow with the <> action. A constraint is that each <> action must have exactly one outgoing flow that links to one action.

All these <> actions are implicitly wrapped around with the fault handlers element by the mapping. This was done for simplicity. Each of the <> actions could have been additionally embedded in a structured activity node that models the encompassing “fault handlers” container. This would not have added information.

Event Handler This construction of fault handlers is also applied to event handlers. Each top- level AcceptEventAction that is stereotyped <> or <> is part of the event handler. OnMessage actions are signal-accepting actions, where the signal is the message it is expected to react to. For the onAlarm event, a time-triggered AcceptEventAction is used. All onMessage and onAlarm events are wrapped around with an event handler element in a transformation. The action linked to by an outgoing flow from either event is the action that should be executed. A constraint is that each <> and <> action must have exactly one outgoing flow that links to one action. It is not quite correct, though. The UML 2.0 specification says, that as soon as the AcceptEventAction gets activated and has no incoming edges, it stays activated. But according to BPEL, an onAlarm that was executed, gets deactivated afterwards.

Compensation Handler A compensation handler is simpler, as it only has one activity inside it. It is mapped by a <> stereotyped AcceptEventAction, and just named “compensation handler”. The action linked to by an outgoing flow is the action that should be executed.

- 58 -

A constraint is that each <> action must have exactly one outgoing flow that links to one action.

Scopes Scopes are modelled with <> stereotyped structured activity nodes. They encapsulate the scope and all within it, and support nesting. Apart from the standard attributes and elements, the stereotype has an additional stereotype attribute for the option “variableAccessSerializable”. The “mustIsolate” attribute of structured activity nodes can be used to map the “variableAccessSerializable” property of scopes. Note the different approach for variables on scopes to variables on the process level. Scope variables are mapped to UML variables on the structured activity node. Unlike a UML class, which is stereotyped for the BPEL process a UML structured activity node does not have attributes.

- 59 -

5. Profile Implementation

The profile specified in above chapter is the desired solution based on full UML 2.0 compliance. The implementation of the profile is limited by the employed software tooling. There are several UML editors available, and the Rational Soft- ware Modeler has been chosen as the implementing tooling environment. The UML 2.0 support of Rational Software Modeler does not cover all aspects of UML 2.0 and the implementation has to use the available concepts and nota- tional support of the tool.

5.1. Rational Software Modeler

The Rational Software Modeler is a UML 2.0 modelling tool by IBM and built on Eclipse 7 technology. It supports all diagram types of UML, as well as profile development. Through Eclipse plug-in technology, it can be enriched by custom- written plug-ins. It is the tooling used for the implementation of this thesis.

5.1.1. Relevant Restrictions in Rational Software Modeler

Before the actual implementation is detailed, the limitations and restrictions of Rational Software Modeler (RSM) with focus on implementation for this profile are mentioned. The most prominent is the incomplete support for UML 2.0 activity diagrams.

• Activity Partitions It disallows structured activity nodes (or any node) to be part of more than one partition. A sequence can have elements that are not in the same partner link, thus the sequence node (or rather structured activity node) would have to be in all these partner links. This is not possible with Rational Software Modeler. To circumvent this, a different approach has to be taken. RSM support for activity partitions is very limited. It also supports only the swimlane notation for partitions, which might have been useable, albeit at cost of readability, if not for the above. • Actions RSM only supports a very limited amount of actions: action, callBehaviorAc- tion, and callOperationAction. All other actions are not implemented. RSM allows to specify signals, but not actions that could react to these signals. All elements that build on that have to be modelled differently. • Structured Activity Nodes Rational Software Modeler only has a structured activity node, but none of its specialisations (sequence, loop, conditional nodes). However, the absence of a representational notation guideline in the UML 2.0 specification might also

7 http://www.eclipse.org/

- 60 -

be a reason for their absence. All activities that use these nodes have to use simple structured activity nodes or be restructured. Structured activity nodes also cannot have UML 2.0 variables in Rational Software Modeler. This means that variables for scopes have to be modelled differently. • Miscellaneous A slight nuisance, especially for the designer, is that RSM occasionally does not draw flows between elements even though they are there. Designers would have to make certain that there really is no link before they draw one anew.

5.2. Implementation Details

Due to above limitations, the actually implemented profile is diverging from the proposed one in the chapter above. In the following, the workarounds RSM made necessary are specified and how the profile is implemented.

Profiles are created in profile projects. Here, the stereotypes can be defined. Adding a stereotype is very simple and the extended UML elements can be specified in the “extension” tab. Stereotype attributes can be added in the “attributes” tab. Icons can be set for each stereotype to separate stereotypes from their base UML elements. This profile used BPEL icons of WebSphere Integration Devel- oper. Constraints are also defined here and can be specified in OCL or Java. When a stereotype is applied, the constraints can be validated trough RSM.

All parts that deal with classes, interfaces, or composite structure diagram do not need adaptations to be used with RSM. These concepts can be used as specified above. For details, refer to the previous sections. However, the concepts that model BPEL activities mostly cannot be used as is and have to undergo some severe changes so they can be implemented and used in RSM.

Partner Link/Port Type Representation in Partner Activities For each activity that can have partner link and port type given as elements (invoke, receive, reply, onMessage), the corresponding UML 2.0 stereotype has the stereotype attributes “partnerLink” and “portType”. This is a direct result of the absence of useful activity partitions. In earlier versions, this information was given via comments of the action, but not only did it clutter the diagram, it also was problematic to work with string comments in the transformation, so the much easier concept of stereotype attributes was chosen. If direct representation of the port type and partner link information is desired, the use of comments to denote this is nevertheless an option.

- 61 -

Receive/Reply Receive and Reply are mapped as acceptEvent and sendSignalAction. These are not present in RSM. Out of the three available actions RSM supports, the callBehaviorAction is chosen and stereotyped accordingly, because it can be appended with pins. The name of the action – the operation to be received from and replied to, is still the name of the operation. Due to the nature of callBehaviorAction, a corresponding behaviour must be there to be called, so a sub-activity is created. This activity is of no further use, and will be ignored by the mapping. To decrease the number of these elements, receive and reply pairs can share the same activity element. Instead of accepting and sending signals with the operation and variables, the callBehaviorAction gets input or output pins. A receive activity will have an input pin, which name is the input variable of the activity. A reply activity will have an output pin, which name is the output variable of the activity, accordingly. A special <> stereotyped output pin is created to facilitate the sending of faults through a reply activity. The fault pin has a stereotype attribute with the fault variable name. Like with invokes in the ideal profile, the pins would be modelled with data stores, but these are left out for reasons mentioned in the last section.

Figure 32: callBehaviorAction, stereotyped “receive”, with input variable

Figure 33: callBehaviorAction, stereotyped “reply”, with output variable

Invoke The invoke activity can retain its base UML 2.0 action, the callOperationAction. Unfortunately, the absence of interruptible region in RSM makes it impossible to use this concept for the inlined fault handler and accompanying compensation handlers. To circumvent this, two “invoke” stereotypes are introduced: <> that is based on the action itself, with all the input and output variables, and <>, which is a structured activity node. This node will then contain a “normal” invoke action, but also the fault and compensation handler as specified in the profile. The <> stereotype needs the naming differ- ence because of RSM. Stereotypes with different metaclasses can have the

- 62 -

same name, but when trying to apply one of these stereotypes in RSM, they will not be applied. A constraint is that the <> may only have invokes, fault, or compensation handler elements inside it.

Figure 34: callOperationAction, stereotyped “invoke”, with input and output variables

Wait The problem of the wait activity mapping is the absence of other action types apart from the ones present and the lack of signalling support. The implemented profile introduces two stereotypes for wait: <> and <>. These are based on the simple action. The name of the action is the time expression. A duration expression for <>, a deadline expression for <>.

Assign The problem of the assign activity mapping is the lack of opaque actions in RSM. The workaround is built on a stereotyped callBehaviorAction, just like receive or reply, and named “assign”. This will create an empty “assign” UML activity in the model, but like for receive and reply, this is ignored. The modelling of the copyTo and copyFrom is relying on pins; input pins for from-specs, output pins for to-specs. Several stereotyped pins are introduced to facilitate this: an expression pin to map expressions, a literal pin to map literal values, a variable pin to map variables (which has stereotype attributes to map both variables with parts or property elements), and a partner link pin to map partner link copy specifications (with a stereotype attribute endpointReference). One copy element of an assign activity is mapped as a pair of input and output pin. Should the assign have more than one copy elements, several pins have to be used. To correlate the input pin with its corresponding output pin, the pins have the stereotype attribute “ID”, which is a simple integer number; each pair of pins has the same ID. A constraint is that these special pins may only be used on an <> stereotyped callBehaviorAction. Another constraint is that only even numbers of pins are allowed on the assign. Each pair of pins must have an ID and the IDs must match. If there is only one pair, the ID is superfluous for the mapping but should be defined for consistency.

- 63 -

Figure 35: callBehaviorAction, stereotyped “assign”, with from- and to-spec variables

Throw Throw activity is mapped by the simple stereotyped action RSM offers. The name of the action is the fault to be thrown, and a stereotype attribute “faultVariable” can hold the optional faultVariable.

Compensate Like the throw activity, the compensate activity uses the simple action of RSM, with an applied stereotype. The name of the action is the scope to be compen- sated.

Terminate The terminate activity mapping does not require change, as RSM supports activity final nodes.

Empty The empty activity can use the simple action. Stereotyped <> and named “empty”, it is of no further complexity.

Sequence Sequence activities would have made use of the UML 2.0 sequence node. Since this is not available, a normal structured activity node will have to be used. The node does not offer the convenient semantic of order as the sequence node; this has to be done manually with control links. The first action in the node is the one without incoming control flow, and connects to the next element, until an element does not have any further outgoing control flow.

Flow Flows can me modelled as defined in the profile, because the structured activity node they use is supported by RSM.

- 64 -

Figure 36: A SAN, stereotyped <>, with two invoke activities

The mapping of links is a bit more complicated. Problems arise when the links are between activities encapsulated by other structured activities inside a flow. Consider the following example:

Figure 37: Sample showing problem with links in RSM

We have two sequences with activities that are enclosed within a flow. Between the activities, a link exists. In BPEL the link would be owned by the flow and appear there. In Rational Software Modeler, the link is a control flow that is owned by the <> stereotyped structured activity node. The <> does not know it has a flow. One option would be to move the ownership of the link through the model explorer of Rational Software Modeler, but this is far from op- timal. The chosen solution is to recursively go over all enclosed nodes, and look for links within. The result of this approach is, that the first flow gets to own all links enclosed within it.

Switch The conditional node that the switch activity would be modelled with is not present in RSM. The implemented profile uses the concept introduced in the previous profile: a decision node, with guards. A <> stereotyped structured

- 65 -

activity node holds exactly one decision node with outgoing flows. Each guard of the control flows specifies a case statement for the switch, and exactly one (optional) control flow without guard, named “otherwise”, specifies the otherwise case of the switch.

While While activities cannot be modelled as the profile intends to for lack of loop node support in RSM. For this concept, the idea of the previous profile is reused: one decision node, with one outgoing control flow. A <> stereotyped structured activity node holds exactly one decision node with exactly one outgoing flow. The guard of that flow holds the looping condition, the activity the flow points to the activity to be looped.

Pick The pick activity is mapped by a structured activity node, stereotyped <>. Within it, the “onMessage” and “onAlarm” elements are mapped as specified below. The edge going out of such an element leaves the structured activity node and points to the action that is to be executed. Semantically, this is not quite correct, since theoretically all actions would start as soon as the node does. The profile deviates from UML semantics as follows: it is assumed that the edges leaving the structured activity node are interrupting edges, which terminate the node itself. A constraint is that it may only have onMessage and onAlarm elements.

Handler The problem of modelling handlers is the absence of signalling actions, like the other concepts used herein. The handlers are mapped as specified below. Fault handlers are modelled by a <> stereotyped callBehaviorAc- tion. The name of the action is the caught fault. It can have an input pin to specify the optional fault variable. OnAlarm events are split into two stereotypes: <> and <>. The extended UML element is the simple action. The names of the action specify a duration expression (onAlarmFor) and deadline expression (onAlarmUntil). OnMessage events are mapped as <> stereotyped callBehav- iorActions. The name of the action specifies the operation to be called. Optional input and output pins specify the input and output variables of the handler. Compensation handlers are mapped by simple actions stereotyped <>. The UML action the outgoing flow points to specifies the activity to be executed when then the handler is called.

- 66 -

Figure 38: A fault handler, with activity

Scope The profile uses structured activity nodes for scopes, and as such can be modelled in RSM. The handlers are modelled as defined above. The problem arises with variables. RSM does not support UML 2.0 variables, as has been pointed out above. The suggestion to alleviate this is the use of <> stereotyped data store nodes, which are typed. Another possible idea would have been the use of special pins on the structured activity node, but the encapsulated data stores would at least model the nature of BPEL variables in scopes better than pins, so the data store approach is used.

5.3. Considerations for BPEL 2.0

The updated version of BPEL 2.0 brings some changes to the syntax and structure of BPEL. Some of these changes, mostly name changes, are quite simple to adapt to this profile. Some changes require new and/or restructured constructs to work. As BPEL 2.0 is not yet officially released [15], there will be further changes, but this section shall give a quick outlook of the current changes and how they can be implemented in a profile. They are listed by their BPEL issue list number [18].

• BPEL Issue 1: Permeability of scopes The Boolean element “isolated” replaces previous element accessVariableSe- riazable. This can be done by simple renaming. • BPEL Issue 7: Import An import mechanism is added for XSD and WSDL definitions. This could be modelled as an additional wrapper class for imports, or attributes of the process class. The use of package import is also an idea to consider. • BPEL Issue 11.1: Making truly extensible Another change is the extensibleAssign element, which allows other data manipulation operations from other namespaces to be included in the assign. This could be solved by introducing a new stereotype mapping extensi- bleAssign as a new element. • BPEL Issue 13: Future Usage of XPATH 2.0 and XQuery 1.0 Where expressions are used (e.g. duration expressions, conditions), BPEL 2.0 allows to directly specify the expression language in the tag itself as an attribute.

- 67 -

This could be solved by an additional stereotype property for expression language definition. • BPEL Issue 34: Dependency on Proprietary Specifications BPEL introduces a “service-ref” concept to keep BPEL open for future endpoint referencing and addressing schemes. This “service-ref” is used in the from-specification for assigns. For the ideal profile, this is quite simple, as it already is an opaque action. For the implemented profile, an additional input pin type would have to be introduced. • BPEL Issue 36: Multiple instances of event handler The onMessage element of eventHandlers has been renamed to onEvent. It gets messageType as new attribute and the variable attribute is no longer optional. This is simply done by introducing a stereotype for this new element and base it on onMessage. MessageType can be covered by an additional stereotype attribute. • BPEL Issue 37: Initiating Correlation Set More Than Once The initiate attribute of the correlation element of receive, reply, invoke, on- Event and onMessage elements is enriched by an additional option “join” be- sides “yes” and “no”. This could be solved by an additional stereotype attribute of the stereotyped precondition. Optionally, a special enumeration could be defined con- sisting of the three values. • BPEL Issue 43: Setting up Periodic Alarms OnAlarm gets an additional element “repeatEvery”, which allows to specify a repeating interval. For the ideal profile, this can be as solved by defining a new time event, for the implemented profile a <> stereotype might be introduced to cover this change. • BPEL Issue 44: portType is duplicated on Invoke activity and partner- LinkType The portType element of partner activities is now optional. This is already reflected in the profile, as the port type is derived through the partner link the activity partition represent. In the implemented profile, it is just a stereotype attribute. Simply not specifying a value for it will solve the issue. • BPEL Issue 74: Ambiguity in join condition definition The join condition previously has been a part of the standard attributes. It is now defined in the targets element, right along with the links the activity is target of. Target and source elements now can be grouped in “sources” and target containers. The change requires no adjustment in the profile, but in the transformation implementation. • BPEL Issue 75: Locally Scoped partnerLink declarations Scopes now have the option to define partner links inside them. The mapping for partner links in scopes is not trivial. In the profile, they are defined as composite structure diagrams on the process class. Scopes are

- 68 -

elements of an activity diagram. These two cannot be mixed, so a completely new way would have to be taken to allow the modelling of partner links in scopes in a meaningful way. • BPEL Issue 95: Rethrow a Fault An additional activity “rethrow” is introduced. It is used in fault handlers to rethrow a caught fault. It is an activity without attributes. A new <> stereotyped action could be introduced. To attach the rethrow to a fault handler, it will be connected by a control flow to the handler. • BPEL Issue 112: Input/Output Elements on Messaging Activities? Invoke, receive, reply and pick activities now have fromPart/toPart and from- Variable/toVariable elements, which can handle assignment-like actions inside the activity. One approach to solve this might be again using pins on the UML actions. Also possible it the use of the concept of an enclosing structured activity node and use stereotyped data store nodes or an explicit <> stereotyped action. • BPEL Issue 123: Matching with The new element messageExchange is used to associate receive with reply messages. This could be modelled with an additional stereotype attribute. • BPEL Issue 135: Clarifying forcedTermination Handler BPEL 2.0 introduces a new handler type, the termination handler. Termination handlers are a new type of handler that are used when a forced termination of a scope takes place and can use the same range of activities as a fault handler. It should be possible to model this new type of handler like current handlers, a fault handler for instance. • BPEL Issue 136: If-Then-Else Activity The switch activity gets replaced by the If activity. This can be modelled by a simple renaming of the switch stereotype, and replacing “case” statements with the syntax of “if”, “elseif”, and “else”. • BPEL Issue 140: Until Activity RepeatUntil is a new activity that realises a looping behaviour with a repeat- until-like semantic: the test is executed after the body part of it is executed. The concepts used for while activities can be reused for this, but need a change of execution order of the test and body part. In case of the UML while loop, this is simply done with the attribute “isTestedFirst” set to false, in the implemented profile the decision node must come after the activity in the “while” structured activity node. • BPEL Issue 147: Serial and Parallel For-Each An additional activity “forEach” is introduced that executes an activity for each element in an iterator variable. The expansion region of UML does cover for-each semantic, and might be the concept to model this activity. • BPEL Issue 160: facilities to define XML schema validation boundary

- 69 -

A new activity is introduced that is used for validation of variables. Assign activity gets a new element “validate”. The activity could be mapped as an opaque action, with the variables list as the body part of the action, or a structured activity node with UML 2.0 variables. For the currently implemented profile, an approach with callBehavio- rActions and input pins could be considered. The additional element can be mapped as a stereotype attribute. • BPEL Issue 206: Exit Activity (Immediately Terminating a Service In- stance) The terminate activity has been replaced by exit. This can be solved by simple renaming.

- 70 -

6. Mapping between Profile and BPEL

This section will detail the mapping and transformation of the UML model to corresponding BPEL and WSDL models. Firstly, the rules are given without focussing on the employed tooling, so the rules can be more easily applied to different technologies. Secondly, the tooling used to implement these rules is outlined, as well as possible other tooling. And thirdly, the experience with the transformation implementation is given.

Figure 39 gives a high-level overview of the mapping. On the one side is the UML model that has been employing the BPEL profile, the source model. On the other side, the models that should be mapped to are listed: BPEL, WSDL, and XSD models. These constitute the target models. Between these, the mapping takes place (which is left out in this overview, cf. section 6.1 for more details on the mapping rules). After the actual transformation, the models can be serialised out and generate the corresponding BPEL, WSDL, and XSD files. Output here depends on the models employed. They may vary and not always work as imagined (in the WSDL model used for the implementation, there was a problem serialising namespaces).

BPEL Model

Transformation UML Model WSDL Model Output Rules files

XSD Model

Mapping & transformation Serialisation Figure 39: mapping overview

6.1. Relation and Transformation Rules

This section will give the mapping rules in an abstract way and is not based specifically on one mapping language or tooling to make it easier to apply them to different tooling. For each concept, a mapping is given in a tabular form where the left-hand side gives the UML view and the right-hand side the BPEL view of the mapping. Each mapping is ordered, so that the top-most entry in the list gives the most general mapping, i.e. from a callBehaviorAction with stereotype <> to a BPEL reply activity, the rows below this then go into further details of this construct. They could be read in natural language in an “X relates to Y” way.

- 71 -

For instance the following row

Class & stereotype=”process” & name = Process >> name=” ” could be read as: “A class with the stereotype <> and name relates to a BPEL process with name . The identity, the join condition that determines that element X relates to element Y, is bold-faced in the rule files.

In case of stereotype properties, the following approach is used to represent them:

Class.stereotypeProperties Name = queryLanguage , Process >> queryLanguage =” ” Name = expressionLanguage , Process >> expressionLanguage =” ”

Class.stereotypeProperties refers to all applied stereotype attributes of a UML element. The rows below this then list these stereotype attributes. The identity here is given by the name of the stereotype attribute and the BPEL attribute.

Where appropriate or necessary, additional explanations will be given after the tabular rule description.

6.1.1. BPEL Process

This mapping rules cover the non-activity concepts of the process. The classes that make up these concepts should be placed into a package, so that processes and WSDL and XSD elements can be easily separated.

Process

UML BPEL Class & stereotype=”process” & name = Process >> name=” ” Class.ownedAttribute & stereo- Process >> Variable name=” ” type=”variable” & name = Class.ownedAttribute Process >> Variable type=” ” Class.stereotypeProperties Name = queryLanguage , Process >> queryLanguage =” ” Name = expressionLanguage , Process >> expressionLanguage =” ”

- 72 -

Name = suppressJoinFailure , Process >> suppressJoinFailure =” ” Name = enableInstanceCompen- Process >> enableInstanceCom- sation , pensation =” ” Name = abstractProcess , Process >> abstractProcess =” ” Name = targetNamespace , Process >> targetNamespace =” ” Each process class is mapped into one BPEL process, and the output will be one file for this process.

Properties

UML WSDL Class & stereotype=”properties” Class.ownedAttribute name = Property >> name=” ” Class.ownedAttribute Property >> type=” ” Class.ownedOperation & stereo- PropertyAlias >> property- type=”propertyAlias” & name = Name=” ” Class.ownedOperation input PropertyAlias >> part=” ” Class.ownedOperation input PropertyAlias >> mes- sageType=” ” Class.ownedOperation stereotypeProper- ties Name=” query ”, PropertyAlias >> query =” ”

Correlation Sets

UML BPEL Class & stereotype=”correlation” & CorrelationSet >> name=” ” name = Class.ownedAttribute CorrelationSet >> element in properties=”properties-list” The class contains a number of attributes that define the properties list. Each attribute matches to an element of the properties list.

Partner Link Types

UML BPEL Collaboration & stereotype=”partnerLinkType” PartnerLinkType >> & name = name=” > role name = name=” ” Collaboration.property PartnerLinkType >> role >> por- type name=” ”

- 73 -

PartnerLinks

UML BPEL CollaborationUse & stereotype=”partnerLink” PartnerLink >> name=” ” & name = CollaborationUse PartnerLink >> partnerLink- Type =” ” CollaborationUse.roleBinding.target & target PartnerLink >> myRole=” ” type !empty & name The mapping of the partnerRole is more complex, as the partnerRole is not defined within the confines of the CollaborationUse, but implicitly by the second part (the part not bound by the CollaborationUse) of the Collaboration used. Thus, the mapping needs access to Collaboration (the partner link type) and CollaborationUse (the partner link) at the same time to be able to do the mapping. “MyRole” and the PartnerLink as a whole are mapped as above. To complete the PartnerLink, the mapping rule has to access the Collaboration, then select the part not bound by the CollaborationUse, check if that part is typed, and if so, map it to the partnerRole of the PartnerLink. The port is not needed for the mapping, as the role binding has the relevant information.

Namespaces

A BPEL process results in one file (.bpel) and the WSDL and XSD elements for it result also in separate files (.wsdl and .xsd) and are placed in folders. They are mapped independently, but build on each other in regards to namespaces. The target namespace is given by the “targetNamespace” attribute of the process stereotype. The name of the model then makes up the next part of the namespace. The name of packages are further added to the namespace. Given a target namespace “http://www.test.com” and a model “purchaseOrder” with packages “purchaseDataTypes”, “purchaseMessages”, and “purchaseProcess the resulting namespaces would look like: “http://www.test.com/purchaseOrder/ purchaseProcess”. Namespace prefixes have to be defined, and the mapping uses the name of the model or package as prefix, for ease of use. The package dependencies are mapped as namespace imports. For each package import (A package with modelled WSDL message could import a data type package, for instance), a corresponding import statement is created in the respective WSDL/BPEL model and/or file.

6.1.2. Standard Activities and Elements for BPEL activities

Standard attributes and elements are (possible) additional elements for BPEL activities, both simple and complex. Thus, they will be described here once for all the activities to avoid needless repetition of these mapping rules.

- 74 -

Standard Attributes

Following mapping covers the standard attributes of BPEL activities, where “Ac- tion” stands for any UML action (callOperationAction, callBehaviorAction) and structured activity nodes. “Activity” stands for any of the BPEL activities the standard attributes can apply to.

UML BPEL Action Activity Action .stereotypeProperties Name = name , Activity >> name =” ” Name = suppressJoinFailure , Activity >> suppressJoinFail- ure =” ” Action localPrecondition & Activity >> joinCondi- name=” joinCondition ” & body = ” sion>

Standard Elements This mapping covers the standard elements part of a BPEL activity, where “Ac- tion” and “Activity” are defined as in standard attributes. Flows are owned by the enclosing UML activity.

UML BPEL Action outgoing & stereotype=”link” & Activity >> link source Outgoing linkName=” ” Action .outgoing.guard.body = > transitionCondi- sion> tion=” ” Action incoming & stereotype=”link” & Activity >> link target name = linkName=” ”

6.1.3. BPEL basic activities

This section gives mappings for the basic activities of BPEL. Each activity has the standard elements and attributes, as mentioned above.

Correlations

This is a mapping for the correlations part of receive, reply, invoke activities, and onMessage events and has been extracted from these rules.

UML BPEL Action local precondition & stereo- Activity >> correlation >> set=”< name> ” type=”correlations” & name = localPrecondition.stereotypeProperties Name = initiate , Activity >> correlation >> initi-

- 75 -

ate =” ” Name = pattern , Activity >> correlation >> pattern =” ”

Receive

UML BPEL callBehaviorAction & stereotype=”receive” Receive >> operation=” ” & name = callBehaviorAction.input Receive >> variable=” ” callBehaviorAction.stereotypeProperties Name = createInstance , Receive >> createIn- stance =” ” Name = partnerLink , Receive >> partnerLink =” ” Name = portType , Receive >> portType =” ” Port type is mandatory in BPEL 1.1, but optional in BPEL 2.0.

UML BPEL callBehaviorAction & stereotype=”reply” & Reply >> operation=” ” name = callBehaviorAction.output Reply >> variable=” ” callBehaviorAction.output & stereo- Reply >> faultName=” ” type=”faultPin” callBehaviorAction.stereotypeProperties Name = partnerLink , Reply >> partnerLink =” ” Name = portType , Relpy >> portType =” ” Port type is mandatory in BPEL 1.1, but optional in BPEL 2.0.

Invoke

UML BPEL callOperationAction & stereotype=”invoke” Invoke>> operation=” ” & name = callOperationAction.input Invoke >> inputVariable=” ” callOperationAction.output Invoke >> outputVariable=” ” callOperationAction.stereotypeProperties Name = partnerLink , Invoke >> partnerLink =” ” Name = portType , Invoke >> portType =” ” Port type is mandatory in BPEL 1.1, but optional in BPEL 2.0.

- 76 -

Invoke (complex)

UML BPEL SAN & stereotype=”invokeSAN” Invoke SAN.containedNode callOperationAction & stereotype=”invoke” SAN.containedNode Action & stereo- CompensationHandler type=”compensation” SAN.containedNode callBehaviorAction & Fault Handler stereotype=”fault handler” This rule defines the invoke activity with fault and compensation handler.

Assign

UML BPEL callBehaviorAction & stereotype=”assign” Assign callBehaviorAction.input & stereo- Assign >> Variable from-spec, vari- type=”variablePin” & name = able=” ” Input.stereotypeProperties Name= part , Assign >> part =” ” Name= property , Assign >> property =” ” callBehaviorAction input & stereo- Assign >> Expression from-spec, ex- type=”expressionPin” & name = pression=” ” callBehaviorAction input & stereo- Assign >> PartnerLink from-spec, type=”partnerLinkPin” & name = partnerLink=” ” Input. stereotypeProperties Name= endpointReference , Assign >> endpointRefer- ence =” ” callBehaviorAction input & stereo- Assign >> Literal from-spec, value = type=”LiteralPin” & name = callBehaviorAction output & stereo- Assign >> PartnerLink to-spec, part- type=”partnerLinkPin” & name = nerLink=” ” callBehaviorAction output & stereo- Assign >> Variable to-spec, vari- type=”variablePin” & name = able=” ” Output stereotypeProperties Name= part , Assign >> part =” ” Name= property , Assign >> property =” ”

Wait

UML BPEL Action & stereotype=”waitFor” & name = Wait >> for=” ” Action & stereotype=“waitUntil” & name = Wait >> until=” ”

- 77 -

Empty

UML BPEL Action & stereotype=”empty” Empty

Throw

UML BPEL Action & stereotype=”throw” & name = Throw >> faultName=” ” Action.stereotypeProperties Name = faultVariable , Throw >> faultVariable =” ”

Compensate

UML BPEL Action & stereotype=”compensate” & Compensate >> scope=” ” name =

6.1.4. BPEL Structured Activities

This section defines mappings for the structured activities of BPEL. It only shows the elements and properties of the structured activity itself. Enclosed activities – simple or complex – are mapped as they are listed here. They will not be listed in the mapping of each construct itself. Thus, consider that each construct has an “activity” part, which can be either a simple or complex activity. Thus, it is obvious that a complete mapping has to be done recursively, especially if the enclosed activities are complex themselves and contain even more activities; section 6.1.6 details a more holistic view of the complete mappings.

Sequence

UML BPEL SAN & stereotype=”sequence” Sequence Elements of a sequence need to be mapped in specific order. When using RSM, the elements of a structured activity node can be ordered arbitrarily in the properties of the SAN. The resulting model will use this order, thus the mapping makes the assumption that elements can be mapped in the order they appear in the file. If this assumption cannot be made, the ordering has to be done manually (as mentioned in the profile implementation), starting at the node without any incoming edges – the first activity in the sequence – and then go edge by edge over the nodes in the sequence until a node with no outgoing edge is reached.

- 78 -

Flow

UML BPEL SAN & stereotype=”flow” Flow SAN containedEdge & stereotype=”link” & Link >> name=” ” name = Maps structured activity nodes with the stereotype <> to BPEL flows. As all activities in flows are running concurrently, no special care has to be taken for ordering activities. The mapping of links is complicated by RSM. RSM initially places the control flows representing the links in the structured activity they are immediately enclosed. Thus, a link that should appear in the enclosing flow is located in an enclosed SAN, a sequence for instance. To catch these flows, each enclosing structured activity node has to be stepped into and checked for links. When found, they are mapped to links. This is done recursively for every enclosed structured activity node.

Switch

UML BPEL SAN & stereotype=”switch” Switch SAN.ownedElement DecisionNode & Switch >> case condi- DecisionNode.outgoing.guard.body tion=” ” Decision.outgoing name=” otherwise ” Switch >> otherwise Outgoing target Switch >> case/otherwise activity

While

UML BPEL SAN & stereotype=”while” While SAN.ownedElement DecisionNode & De- While >> condition=” ” cisionNode.outgoing.guard.body DecisionNode.outgoing target While >> Activity to be looped

Pick

UML BPEL SAN & stereotype=”pick” Pick SAN.ownedElement CallBehaviorAction Pick >> onMessage & stereotype=”onMessage SAN.ownedElement CallBehaviorAction Pick >> onAlarm & stereotype=”onAlarmFor”

- 79 -

SAN.ownedElement CallBehaviorAction Pick >> onAlarm & stereotype=”onAlarmUntil” The onMessage, onAlarmUntil, and onAlarmFor elements are mapped as specified below.

Scope

UML BPEL SAN & stereotype=”scope” Scope SAN.ownedElement dataStore & stereo- Scope >> variable name=” ” type=”scopeVariable” & name = dataStore type = Scope >> variable type =” ” SAN. mustIsolate = Scope >> variableAccessSeriali- azable =” ” The other concepts of the Scope - fault, compensation, and event handlers - are mapped as specified in the mapping rules below.

Fault Handler

UML BPEL callBehaviorAction & stereotype=”fault Fault Handlers >> catch >> fault- handler” & name = Name=” ” callBehaviorAction name=” catchAll ” FaultHandlers >> CatchAll callBehaviorAction input FaultHandlers >> Catch >> faultVari- able=” ” callBehaviorAction outgoing target Activity Fault handler appears only in the top-level activity in the UML model, or in scopes. Thus, the mapping is only executed at the top-level or when entering a scope.

Compensation Handler

UML BPEL Action & stereotype=”compensation” CompensationHandler When a UML action or structured activity node with stereotype “compensation“ appears at top level of the process behaviour (or inside a scope), the activities are assumed to be the compensationHandler.

Event Handler

UML BPEL CallBehaviorAction & stereo- EventHandlers >> onMessage type=” onMessage ” CallBehaviorAction & stereo- EventHandlers >> onAlarm type=” onAlarmFor ”

- 80 -

CallBehaviorAction & stereo- EventHandlers >> onAlarm type=” onAlarmUntil ” When a callBehaviorAction with stereotype ”onMessage”, ”onAlarmUntil”, or ”onAlarmFor” are at the top-most level of the process behaviour, they are taken as onMessage or onAlarm elements of eventHandlers, which is implicitly assumed, that is wrapped around these actions in the mapping. The mapping for the events is given below.

OnMessage

UML BPEL callBehaviorAction & stereo- onMessage >> operation=” ” type=”onMessage” & name = callBehaviorAction input onMessage >> variable=” ” callBehaviorAction.stereotypeProperties Name = partnerLink , onMessage >> partner- Link =” ” Name = portType , onMessage >> portType =” ”

OnAlarm

UML BPEL Action & stereotype=”onAlarmFor & name onAlarm >> for=” ” = ” Action & stereotype=“onAlarmUntil” & onAlarm >> until=” ” name =

6.1.5. WSDL/XSD elements

This section finally covers the WSDL and XSD concepts: message, port types, partner link types, and data types.

Messages

UML WSDL Class & stereotype=”message” & Message >> part >> name=” ” name = Class.Attribute Message >> part >> type=” ”

UML WSDL Class & stereotype=”docLitMessage” Message >> part >> name=” ” & name = Message >> part >> element=”” + Parameters” Message >> part >> name=””

- 81 -

XSD >> complex type name=” ” + “Parameters” Class.ownedAttribute XSD >> part name=” ” Class.ownedAttribute ; type XSD >> simple type >> type=” ” primitiveType Class.ownedAttribute ; type XSD >> complex type >> type=” non-primitiveType

Port Types

UML WSDL Interface & stereotype=”interface” & PortType >> name=” ” name = Interface.operation PortType >> operation=” ” Operation. returnResult Operation >> output message=” ” Operation. inputVariable Operation >> input message=” ” Operation. outputVariable Operation >> fault name=” ” Operation.outputVariable Operation >> fault message =” ”

Data Types

UML XSD Class & stereotype=”data” & name = XSD complex type name=” ” Class.ownedAttribute XSD element name=” ” Class.ownedAttribute ; type XSD simple type, type=” ” primitiveType Class.ownedAttribute ; type XSD complex type, type=” non-primitiveType

6.1.6. Approach to Overall Mapping

The mapping of a complete process is more complex than these listed mapping rules make it appear. The rules are not used in a standalone fashion, but in an integrated mapping of the whole UML model. The mappings of processes, properties, basically those constructs that build on classes or interfaces, are simple and straightforward. The mapping of the BPEL process logic and its nested structure requires recursion.

- 82 -

sequence

receive flow flow flow assign flow

Figure 40: Sample recursion over activities

Figure 40 shows a sample recursion of this approach. The mapping enters the sequence, and maps the receive element. Then it encounters a flow element, and it steps into it, mapping it. The assign is mapped, and then it encounters another flow, and steps into this flow maps it, and then the enclosed reply.

A package may contain BPEL, WSDL, or XSD elements. For each of these, mappings are defined, which are applied to the package. The mapping is threefold. • If a package contains a process class and process logic the BPEL mapping rules are applied. • If a package contains message, interface, partnerLinkType or portType classes the WSDL mapping rules are applied. • If a package contains dataTypes classes, the XSD mapping rules are applied.

For each package, the mapping engine steps into it, assess what classes (and stereotypes) are inside it, and map the package contents according to this to BPEL, WSDL, or XSD.

This approach is just one possible way to do it. Its reason is to allow the separa- tion of BPEL, WSDL, and XSD elements in a meaningful way. Defining a package for each of these in UML is a way to make the structure clear but the mapping does not demand this. It would also be possible to model a process in just one package with WSDL and XSD mapping in this package, as well, or have only two packages: one for BPEL and the other one for WSDL and XSD.

XSD and WSDL packages The mapping for these elements is comparatively easy. Due to their structure, most elements can be mapped one-to-one, without much recursive overhead. In cases of XSD, the profile provides only limited support and so the mapping is very simple. WSDL messages and port types do not require any recursive action and can be mapped directly one-to-one. Mapping of partner link is more complex, due to reasons explained in the partner link section of the BPEL process. When the partner link types have been

- 83 -

mapped, the partner link mapping then uses a reference relationship to get the correct partner link types for its elements.

BPEL packages BPEL package mapping is twofold. The first part, mapping the variables, properties, property aliases, and correlation sets, can be done very easily, as they, too, can be mapped without recursive action on a one-to-one basis (Though they can be in different packages). The complexity comes into play in the mapping of the process logic of the BPEL process. The mapping engine must go into the owned behaviour of the UML process class and then start mapping. First come the top-level elements of the process itself, fault, compensation, and event handlers – including their activities – then the activity of the process itself. This is simple, if the activity is but a simple BPEL activity. In case of a complex activity (sequence, flow…) the mapping has to step into that activity, and then check again for activities, and step into complex activities (if present) yet again. Depending on the transformation tooling employed, this could be encapsulated into a transformation rule, e.g. “activity2BPEL”, in which all the possible activity mapping rules (according to the BPEL specification’s listing of possible activities) are put. It also has to ensure the correct succession of activities, and avoid mixing it up. In a sequence, for instance, the order in which the activities are defined in BPEL is important. In case the UML model is in a correctly ordered .emx file of RSM, this is alleviated as one can simply match over the elements. If it is not ordered, the mapping itself has to make sure that the activities appear in the correct order.

- 84 -

UML Model

BPEL package BPEL Package

WSDL Package BPEL process

XSD package (data types) Variables

Message CorrelationSets

portType Properties/Aliases

PartnerLinkType partnerLinks

Behaviour

Fault/Event/Comp.Handler

Structured activity node

Action

Figure 41: simplified UML model structure

Figure 40 shows a very simplified sample structure. At the top is the UML model itself, below it are two BPEL packages. One package is expanded, and shows a WSDL package with its elements, as well as an XSD package for data types. The BPEL package contains the process itself, and its sub-elements, which can be expressed in the class diagram directly. The behaviour finally goes into the process logic itself (and shows a structured activity node and an action nested inside another structured activity node). The dashed lines show the reference between elements. Partner links reference partner link types. These reference port types, which reference messages. Messages reference XSD data types, and are referenced by variables. Correlation sets reference properties.

6.2. Transformation Technologies

Now that we have defined the profile and the transformation rules, a transformation tooling or framework is needed that facilitates mapping between Eclipse Modeling Framework (EMF) [30] models. The Eclipse Modeling Framework is a framework for Eclipse that gives designers the ability to design an implement models. It keeps the implementation details away from the designer and provides a code generation capability, which enables models implemented in EMF to be easily used in any Java application.

There have been two frameworks taken into closer consideration:

- 85 -

• Rational Transformation Framework • Model Transformation Framework (MTF)

The Rational Transformation Framework is a part of the Rational Software prod- ucts (Modeler, Architect). The transformation is written in Java. The framework realises one-way transformations. It has a front-end, which is the source model. The back-end is the output of the transformation. Best practise is to have an intermediate model. Elements from the front-end are placed in this intermediate model, and then a transformation goes over it to produce the desired output. The transformation in the framework consists of three elements: transforms, extractors, and rules. Transforms is the basic container element for transformation and contains extractors and rules. Extractors are iterators that traverse over elements that are passed to a given transform. Rules are the main operator of the transformation and are prescriptive. They take elements and perform actions on them to affect it [29].

The Model Transformation Framework [25] is a framework developed by IBM and available through alphaWorks 8. It uses a different approach. It is not a prescriptive framework: it does not define rules in the way “create object X, set property Y”, but defines how models relate to each other. A rule tells the system what it takes for a model A to be consistent with model B. If the models are not consistent, it can reconcile them – in the worst case (no target model is present) it will create the model. MTF has two phases of transformation: a mapping phase and a reconciliation phase. A mapping takes a set of rules and applies it to models. When all the elements comply with the rules, nothing happens. When the elements do not comply, a mapping will report violations. The reconciliation phase tries to fix these violations. MTF supports an automatic reconciliation, where MTF will try to change the model elements so they comply with the rules.

The mapping is built around so-called relations.

For the mapping, MTF was chosen. The reasons are

• Ease of programming: Once the language has been understood, the rules can be written quite easily and the programmer does not have to concern himself with low-level issues like parsing, file creation et al. • Transformation debugging: It is also possible to run MTF from within a Java program and solve the conflicts through custom-written Java code. • Two-Way Mapping: As rules written in MTF do not define prescriptive mappings but only consistency conditions, it has a built-in two-way mapping capa-

8 http://www.alphaworks.ibm.com/tech/mtf

- 86 -

bility. For the framework, it theoretically does not matter, whether the source or target model is to be created. If either one is not present, it will create it upon reconciliation of the models. In practise, though, this is not as easy. The problems regarding this two-way mapping and the profile are discussed in section 6.3. • Usability: It enables easy interaction with different EMF models, including content-assist in an Eclipse-environment for these models.

Below is a sample relation in the MTF relations language (Mapping Rules Defini- tion Language). relate class2porttype(uml:Interface int, wsdl:PortType pt) when equals (int.name, pt.qName) { op2op(over int.ownedOperation, over pt.eOperations) }

The mapping is defined by a set of such relations, together forming the rules definition (.rdl file). The relation above shows the basic syntax of a rule. The relation is named class2porttype and maps a UML interface to a WSDL portType. This is specified by the comma-separated statements between the brackets. The abbreviations before the semicolon (uml, wsdl) are so-called namespaces, which represent EMF models. To further define this relation, an identity (join) condition is introduced, saying that interfaces and port types are identical based on their name. Without this condition, MTF tries to map every possible combination of interfaces and port types, and subsequently throws an error because it tries to match every element on the one side to every element of the other side. In the body of the relation, so-called correspondences can be given to further define the mapping. In this case, a second relation op2op is used, that maps the UML operations of the interface to WSDL operations of the port type. The EMF model defines the operations as a set of operations, thus the keyword “over”, which tells MTF that it should go over every element in this set, the same holds for the operations of the port types.

6.3. Realisation of Prototype

In this chapter, I will give a short overview of the experience gathered while implementing the mapping with Rational Software Modeler and the Modeling Trans- formation Framework.

For the mapping a rule file, uml2bpel, has been developed. It includes mapping rules for BPEL concepts and the relevant WSDL concepts. For the UML to XSD mapping, the prototype uses a simplified version of a rule file that is included as sample relation with MTF.

- 87 -

One of the reasons MTF was chosen over the Rational Transformation Frame- work was the possibility of an integrated two-way mapping. While MTF gives this two-way mapping ability basically for free if the rules support it, this is not without a degree of complexity. One big problem of the implementation of two-way mapping has been the file format itself. Rational Software Modeler does not write out the applied profiles when saving to .uml2 file format; any profile information applied to a model is lost. Thankfully, MTF supports reading from .emx-files, the format the model is stored within Rational Software Modeler. The writing to .emx-files is not yet supported, so the approach would have to be to transform the WSDL/BPEL/XSD files to uml2. Unfortunately, this also means that the profile information would have to be re-applied to the model. Another problem is the use of the “match” statement of MTF. When having a rule like somerule(match over left.collection, over right.collection) it means that for every element in the right collection, there should be a matching element in the left collection. When reconciling right to left, MTF will create elements in the left collection to match elements in the right collection. Elements that are already in the left collection will be ignored. The other way round, left to right, means that the rule will be applied to right and left elements when they match, but it will not create elements for the right collection. Checking for applied stereotypes by their name is also problematic for a two- way mapping. When going over the set of applied profiles for an element and check whether a stereotype is applied by its name, this works in the UML to BPEL direction (and has been used successfully). The mapping engine would not be able to create UML elements and apply stereotypes to them with this rule in a reverse mapping, though, because it is not enough information for the engine. In the backward direction, the engine does not know about a profile. To be able to match stereotypes backward, the profile itself must be used. For this, the profile file (.epx) must be read into MTF. Then the stereotypes can be referenced as stereotypes with a special set of rules, and not just by their names. For this to work, though, the profile must be accessible as a file in the current MTF version, as the loading of a profile through an URL (import statement) is not supported yet in the employed MTF version. To achieve a two-way mapping requires some experimentation with the rules. One approach is to develop two sets of rules starting from one set of rules, and work out a common subset of rules that work for both directions and two smaller sets of rules that handle the UML to BPEL direction and the BPEL to UML direction.

The rule implementation heavily depends on the employed EMF models. One has to know how the models are implemented to properly work with them. This can lead to some problems, when a model does not behave the way one ex-

- 88 -

pects. While implementing the mapping, a problem with namespace mapping ap- peared. The WSDL EMF model had a problem serialising namespaces. That is, the namespaces had been created in the ecore model file, but when serialising it out to a WSDL file, this information was lost. Another issue with EMF models is the BPEL EMF model. The employed EMF model for BPEL is based on a WS-BPEL 2.0 draft and tolerates BPEL 1.1 dese- rialisation. In the specific case of defining link sources and targets the BPEL specification has changed; the model generates “sources” and “targets” containers around the individual “source” and “target” tags of BPEL 1.1. As the underlying BPEL-engine would also be built around this model, there are no problems to be expected in processing this generated BPEL.

An observed problem of MTF in conjunction with Rational Software Modeler is the memory consumption. MTF is only a prototypical mapping implementation, so memory leaks and performance issues might still be present. Several consecu- tive mapping sessions have repeatedly bloated the memory consumption of Ra- tional Software Modeler to 1.2 GB RAM and more. Even though it traverses several times over the model, MTF does so quickly and without observable delay, but no experience has been gathered regarding performance of bigger models and scalability.

While the learning curve is pretty steep for beginners, MTF rules can represent the mapping rules very well. Thus, MTF allows for an efficient validation of the relations, even though MTF rules will most likely not be used in a productive environment. Through the concept of extensions, MTF allows adding convenience methods for EMF models and can enhance them. They can also define how MTF should handle non-EMF objects.

- 89 -

7. Conclusion

The first objective was to define a UML profile with an outlined mapping for the profile to BPEL. The second objective was to provide an implementation of the profile and the third objective to provide an implementation of the mapping for the implemented profile and evaluate a bi-directional approach.

The realisation of the profile significantly diverts from the specified profile. A theoretical profile defines a profile with a complete UML 2.0 support, and a real-world profile, that shows how the theoretical profile can be implemented using actual tooling (Rational Software Modeler) in the real world due to limitations of the implementation platform, especially regarding activity diagrams. The differences, as well as similarities have been discussed in detail.

The transformation and rules are based on the profile as implemented in Rational Software Modeler and specified herein. The rules cover the whole range of BPEL processes and WSDL. The prototype implementation using MTF shows that the rules can be successfully used to achieve a mapping from UML to BPEL. It also shows that these rules could be applied for a bi-directional approach; the implementation thereof depends on the tooling used and its limitations.

7.1. Future Work

The profile is designed for BPEL 1.1. While BPEL 2.0 is not yet released in a final version, the thesis gives a quick overview of the changes from the current version, and how the profile might be adapted to match these changes. Some changes are simple, merely cosmetic (e.g. required vs. optional mentioning of port types in invocation activities), while the partner link specification in scopes requires bigger adaptations to the profile. The limitations Rational Software Modeler imposed on the design and implementation of a working profile have been severe in some respects. Future versions of Rational Software Modeler may bring more UML 2.0 conformity, so a profile could be implemented that is closer to the intended profile. Another interesting starting point for future work is the implementation of the profile in other UML 2.0 editors (such as Poseidon for UML 9, for instance). The mapping tool is only prototypically implemented, intent to show the principle behind the mapping and rule files and the practicability of the mapping. A future project a production-strength implementation of the transformation (e.g. as a plug-in in WebSphere Integration Developer or Rational Software Modeler), is of interest. Regarding the UML specification, a clarification of the flow semantic in conjunction with structured activity nodes in future versions of UML is highly desirable, as well as a defined notation for the specialisations of structured activity nodes.

9 http://www.gentleware.com/index.php

- 90 -

List of Literature

UML [1] Amsden, J., Gardner, T., Griffin, C., Iyengar, S.: Draft UML 1.4 Profile for Automated Business Processes with a mapping to BPEL 1.0. Version 1.1. Online, accessed 09/06/2003. http://www-128.ibm.com/developerworks /rational/library/content/04April/3103/3103_UMLProfileForBusinessProces ses1.1.pdf

[2] Object Management Group: UML 2.0 Superstructure Specification. Online, accessed 14/07/05. http://www.omg.org/cgi-bin/doc?ptc/2004-10-02.

[3] Bell, D.: UML basics: The component diagram . Online, accessed 21/07/05 http://www-128.ibm.com/developerworks/rational/library/dec04/bell/.

[4] Ambler, S. W.: The Object Primer : Agile Model-Driven Development with UML 2.0. Cambridge University Press, 2004. 0-521-54018-6

[5] Bock, C.: UML 2 Activity and Action Models . In: Journal of Object Tech- nology , vol. 2, no. 4, July-August 2003, pp. 43-53. http://www.jot.fm/ issues/issue_2003_07/column3

[6] Bock, C.: UML 2 Activity and Action Models Part 2: Actions . In: Journal of Object Technology , vol. 2, no. 5, pp. 41-56. http://www.jot.fm/issues/ issue_2003_09/column4

[7] Bock, C.: UML 2 Activity and Action Models Part 3: Control Nodes . In: Journal of Object Technology , vol. 2, no. 6, pp. 7-23. http://www.jot.fm/ issues/issue_2003_11/column1

[8] Bock, C.: UML 2 Activity and Action Models Part 4: Object Nodes . In: Journal of Object Technology , vol. 3, no. 1, pp. 27-41. http://www.jot.fm/ issues/issue_2004_01/column3

[9] Bock, C.: UML 2 Activity and Action Models Part 5: Partitions. In: Journal of Object Technology , vol. 3, no. 7, pp. 37-56. http://www.jot.fm/ issues/issue_2004_07/column4

[10] Bock, C.: UML 2 Activity and Action Models, Part 6: Structured Activities . In Journal of Object Technology , vol. 4, no. 4, May-June 2005, pp 43-66 http://www.jot.fm/issues/issue_2005_05/column4

[11] Schardt, J.: What’s New for UML Version 2 . Online, accessed 22/07/05. http://12.164.75.2/productionACC/technologyCorner/accTechnologyArti- cles/NewForUML2WhitePaper/New-For-UML2-White-Paper.pdf.

- 91 -

[12] Kennesaw State University, CSIS 4650. Unified Modeling Language (UML) Tutorial . Online, accessed 09/10/05. http://pigseye.kennesaw.edu/ ~dbraun/csis4650/A&D/UML_tutorial/history_of_uml.htm.

[13] Pender, T.: UML Bible . Wiley Publishers, 2005. 0-764-52604-9.

[14] Object Management Group: UML 2.0 OCL Specification. Online, accessed 10/08/05. http://www.omg.org/cgi-bin/doc?ptc/2003-10-14. 10/05.

BPEL [15] Curbera, F., Goland, Y., Klein, J., Leymann, F., Roller, D., Thatte, S., Weerawarana, S.: Business Process Execution Language for Web Ser- vices, Version 1.0. Online, accessed 10/09/05. ftp://www6.software.ibm .com/software/developer/library/ws-bpel1.pdf.

[16] Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I., Weerawarana, S.: Business Process Execution Language for Web Services. Version 1.1. Online, accessed 01/05/05. http://www.oasis-open.org/committees/ download.php/2046/BPEL%20V1-1%20May%205%202003%20Final.pdf.

[17] Arkin, A., Askary, S., Bloch, B., Curbera, F., Goland, Y., Kartha, N., Liu, K., Thatte, S., Yendluri, P., Yiu, A.: OASIS Web Services Business Proc- ess Execution Language (BPEL) Version 2.0. Online, accessed 24/10/05. http://www.oasis-open.org/committees/download.php/14616/wsbpel- specification-draft.htm.

[18] BPEL issues list. Online, accessed 20/10/05. http://www.oasis-open.org/ committees/download.php/14974/wsbpel_issues_list.html.

SOA and Web Services [19] Johnston, S.: UML 2.0 Profile for Software Services . Online, accessed 14/07/05. http://www-128.ibm.com/developerworks/rational/library/05/419_ soa/.

[20] He, H.: What is Service-Oriented Architecture? Online, accessed 19/10/05. http://webservices.xml.com/lpt/a/ws/2003/09/30/soa.html.

[21] Graham, S., Davis, D., Simeonov, S., Daniels, G., Brittenham, P., Naka- mura, Y., Freemantle, P., König, D., Zentner, C.: Building Web Services with Java . Second Edition. Sams Publishing, 2005. 0-672-32641-8.

[22] Wikipedia: Service-oriented architecture. Online, accessed 30/06/05. http://en.wikipedia.org/wiki/Service_Oriented_Architecture.

- 92 -

[23] W3C: Web Services Architecture Working Group. Web Services Architec- ture. Online, accessed 06/07/05. http://www.w3.org/TR/ws-arch/ [24] Christensen, E.; Curbera, F., Meredith, G., Weerawarana, S.: Web Ser- vices Description Language (WSDL) 1.1. Online, accessed 06/07/05. http://www.w3.org/TR/wsdl.html.

Miscellaneous [25] Griffin, C.: IBM Model Transformation Framework 1.0.0. Programmer’s Guide. 2004. Online, accessed 01/08/05. http://www.alphaworks.ibm.com/ tech/mtf.

[26] Thatte, S.: XLANG. Web Services for Business Process Design. Online, accessed 23/10/05. http://www.gotdotnet.com/team/xml_wsspecs/xlang- c/default.htm

[27] Leymann, F.: Web Services Flow Language. (WSFL 1.0). Online, accessed 23/10/05. http://www-3.ibm.com/software/solutions/webservices/ pdf/WSFL.pdf.

[28] Clark, J., DeRose, S.: XML Path Language (XPath). Version 1.0. (W3C). Online, accessed 21/09/05. http://www.w3.org/TR/xpath.

[29] IBM RSx development team: Create a RSA Transformation . Tutorial for Transformation with RSx . Online, accessed 10/09/05 through Rational Software Architect Reusable Asset at http://www-128.ibm.com/ developerworks/product/rational/rsa/ras.

[30] Moore, B., Dean, D., Gerber, A., Wagenknecht, G., Vanderheyden, P.: Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework . Online , accessed 25/10/05. http://publib- b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246302.html?Open

[31] Wikipedia: ACID. Online, accessed 25/10/05. http://en.wikipedia.org/ wiki/ACID

- 93 -

Appendix A - UML 2.0 profile for BPEL

Dependency Management

To model the XML namespace hierarchy of a BPEL the profile uses UML package hierarchy. The target namespace is given through the “targetNamespace” stereotype attribute of the process stereotype. The name of the model then makes up the next part in the namespace, then appended by the name of the individual packages in the model.

Data Types, Messages and Interfaces

XSD Data type Extends: Class Stereotype: data Used for: This stereotyped is used to notate a BPEL data type. The class can have attributes, representing the subtypes for a complex data type.

WSDL Message Extends: Class Stereotype: message Used for: This stereotype is used to notate a BPEL message type. It may hold attributes of XSD simple types and associations to data types (see above).

WSDL Message (Document/literal wrapped-style) Extends: Class Stereotype: docLitMessage Used for: This stereotype is used to notate a BPEL message type using the document/literal wrapped binding style.

Port Type Extends: Interface Stereotype: interface Contraints: Must hold at least one operation. Used for: This stereotype is used to notate a BPEL port type. Each operation specifies an operation this port type offers.

Properties and Correlation

Property Extends: Class Stereotype: properties Constraints: At least one attribute.

A - 1

Used for: This stereotype is used to represent BPEL properties. It is important to note that the class is only a container for the actual properties. The attributes of the class are mapped to BPEL properties.

Property Alias Extends : Operation Stereotype : propertyAlias Attributes : Query: String. Specifies the query string to extract property from message. Constraints : Only allowed in properties stereotyped class. The property the alias refers to must be defined as properties attribute. Used for : It is used to model property aliases. It is named as the property it is an alias of. The in parameter specifies the message type to extract the property from.

Correlation Set Extends : Class Stereotype : correlation Constraints : At least one attribute. Attribute must refer to a defined property. Used for : This stereotype is used to notate BPEL correlation sets. The attributes the class holds define the correlation set.

Partner Link Types

Partner Link Type Extends : Collaboration Stereotype : partnerLinkType Constraints : Must have exactly two roles. Used for : This stereotype notates a BPEL partner link type. If both roles are typed in UML by a port type, both are mapped to BPEL. If only one of the two roles is typed and stereotyped, only the typed role is mapped to BPEL.

Process and Partner Links

Process Extends : Class Stereotype : process Attributes : targetNamespace: String. The target namespace of the process. enableInstanceCompensation: Boolean. Sets the instance compensation flag. suppressJoinFailure: Boolean. Sets the join failure flag. variableAccessSerializeable: Boolean. Sets the serializeable flag. abstractPocess: Boolean. Sets the flag for abstract processes. expressionLanguage: String. Specifies an expression language for the process.

A - 2

queryLanguage: String. Specifies the query language the process uses. Used for : This stereotype notates a BPEL process.

Variables Extends : Attribute Stereotype : variable Constraints : Must be attributes of a process. Used for : The attributes represent the BPEL variables.

Partner Links Extends : CollaborationUse Stereotype : partnerLink Attributes : endpointReference: String. Specifies the associated endpoint reference of the partner link. Constraints : Must be used in a process. Used for : This feature defines the partner links. The CollaborationUse specifies the name and type of the partner link. A port on the <> always specifies the BPEL myRole the partnerLink plays. PartnerRole is implicitly given by the second part of the Collaboration. It may be noted that this is not UML 2.0 compliant, as the Collabora- tionUse only binds one of the two roles of the Partner link type where it would normally be required to bind all parts of it.

Data Handling

For data handling purposes, XPath expressions are used to express handling of data.

Basic Activities

Standard Attributes The standard attributes for activities, “name” and “suppressJoinFailure” are mapped as stereotype attributes on the activities of type string. They can be defined either in each stereotype, or by defining a common stereotype that is a generalisation for the other stereotypes. The “joinCondition” is mapped as a local precondition on the activity.

Standard Elements The standard elements, target and source, are mapped implicitly by the incoming and outgoing <> stereotyped flows. An action with an outgoing <> has that link as its source, the action the flow points to has that link as its target. A transition condition is defined as guard of the link.

Correlations Extends : Constraint

A - 3

Stereotype : correlations Attributes : Initiate: Boolean. Specifies the value of the “initate” attribute of the correlations element. Pattern: String. Specifies the attribute “pattern” of the correlations element of invoke activities. Constraints : Only allowed on invoke, reply, receive, onMessage stereotyped actions. Used for : This stereotyped precondition allows to specify the correlations element of invoke, reply, receive, and onMessage.

Invoke Extends : callOperationAction Stereotype : invoke Constraints : May only refer to operation defined in port type. Used for : This action is used to notate the BPEL invoke. BPEL input and output variables are given as Input and Output pins on the action.

Invoke (complex) Extends : Interruptible region Stereotype : invokeComplex Constraints : May only contain invoke activities, fault and compensation handlers. Used for : This concept is used to notate the BPEL invoke with inlined fault and compensation handlers. The interruptible region around the “pro- tected” invoke will contain the fault and compensation handler elements for the invoke.

Receive Extends : AcceptEventAction Stereotype : receive Used for : This stereotype notates a BPEL receive.

Reply Extends : SendSignalAction Stereotype : reply Constraints : May not be used without a matching receive. Used for : This stereotype notates a BPEL reply.

Wait Extends : AcceptEventAction Stereotype : wait Constraints : May only be used with and accept TimeEvents. Used for : This stereotype notates a BPEL wait.

Assign Extends : OpaqueAction

A - 4

Stereotype : assign Constraints : - Used for : This stereotype models the BPEL assign. The body of the opaque action contains the actual assign operation.

Control Flow

Sequence Extends : SequenceNode Stereotype : sequence Used for : This stereotype notates a BPEL sequence. Elements in it are processed sequentially.

Flow Extends : StructuredActivityNode Stereotype : flow Used for : This stereotype notates a BPEL flow. Each UML action/activity without incoming control and object flow in the flow activity gets started as soon as the flow is and they are processed concurrently.

Link Extends : Control flow Stereotype : link Used for : This stereotype notates a BPEL link. Guard on link specify transition conditions of link.

Dead Path Elimination A fault token is introduced conceptually, which results from a negative join condition and then travels along flows to model negative link status until a join condition evaluates to true.

Switch Extends : ConditionalNode Stereotype : switch Properties : isDeterminate = true. Used for : This stereotype notates a BPEL switch statement. For each case statement, a UML clause with test section and body section is present. The “otherwise” semantic is handled by an “else”-clause.

Pick Extends : Interruptible region Stereotype : pick Attributes : createInstance: Boolean. Specifies if the pick can create an instance. Properties : isDeterminate = true. Constraints : May only hold onMessage and onAlarm elements.

A - 5

Used for : This stereotype notates a BPEL pick. The elements in the interruptible region (onMessage and onAlarm events) wait for the occurrence of an event. When such an event happens, the corresponding onMessage or onAlarm is executed. When this happens, and a token leaves the interruptible region, the region is terminated, thus the pick cannot accept any events afterwards.

While Extends : LoopNode Stereotype : while Properties : isDeterminate = true. isTestedFirst = true. Used for : This stereotype notates a BPEL while.

Scopes

Scope Extends : StructuredActivityNode Stereotype : scope Properties : mustIsolate = true, if scope attribute variableAccessSerializable = true. Used for : This stereotype notates a scope. They can be nested, and all handlers (see below) belonging to that scope along with it.

Fault Handling

Fault Handler Extends : AcceptEventAction Stereotype : fault handler Constraints : Used for : This stereotype notates a fault handler. It catches events, faults, and acts accordingly.

Throw Extends : SendSignalAction Stereotype : throw Used for : This notates the throw in BPEL. When activated, throws a fault, which will be caught by the handler.

Event Handling onMessage Extends : AcceptSignalAction Stereotype : onMessage Constraints : Used for : This stereotype notates the onMessage in BPEL.

A - 6

onAlarm Extends : AcceptSignalAction Stereotype : onAlarm Constraints : Must have a TimeEvent associated to it Used for : This stereotype notates the onAlarm of BPEL.

Compensation handling

Compensation Handler Extends : AcceptSignalAction Stereotype : compensation Used for : This stereotype notates a compensation handler in BPEL.

Compensate Extends : sendSignalAction Stereotype : compensate Used for : This stereotype notates the compensate activity in BPEL. When called, it sends a signal to the compensation handler to begin compensation for the scope.

A - 7

Erklärung

Hiermit versichere ich, diese Arbeit selbständig verfasst und nur die angegebenen Quellen benutzt zu haben.

Unterschrift

Stuttgart, 27.10.2005