Service Choreographies througha Graphical Notation based on

Abstraction Layers and Viewpoints(Doctoral Paper)

Mario Cortes CornaxUniversity of Grenoble, CNRS, LIG

Grenoble, FranceEmail: Mario.Cortes-Cornax@imag.fr

Abstract—Organizations’ business processes become more andmore complex and depend on services provided by externalorganizations. The global viewpoint given by choreographyapproach is required to better understand, build, survey andoptimize complex processes. While existing proposals were madefor defining choreographies, it is still difficult to bridge thegap between business process design and implementations. Wepresent choreography with a graphical notation based on meta-modeling techniques as abstraction levels and multiple views.This will help us to fully exploit this currently underusedconcept. In order to address identified notation issues, severalrecommendations are put forward. An empirical experimentationof our work is finally presented bringing about several updatesin our proposal.

I. INTRODUCTION

Today, organizations are moving towards inter-organizational business processes. Their business processesdepend on services provided by external organizations.

Modular solutions relying on Service Oriented Architectures(SOA) are increasingly found to implement these businessprocesses where business activities are conceived as services.SOA is an architectural approach that advocates buildingsystems based on loosely coupled services with well definedinterfaces [1].

In this context, we are interested in the web service chore-ography, a service composition approach focused on messageexchanges between different services from a global viewpoint.This composition approach provides a mechanism to buildand better understand a business process implementation con-cerning several participants. We will therefore seek to betterunderstand service choreographies and propose an approachfor defining this concept so it can be exploited for bothbusiness actors and technical actors.

There is no current consensus when defining choreography[2], [3]. This concept has not yet been standardized despiteW3C’s efforts [4] with the Web Service Choreography De-scription Language (WS-CDL [5]) proposal. Choreography asyet has no industry support and mostly relies on researchprojects like [6], [7], [8], [9]. It seems that all proposalsare converging to the new choreography representation putforward by the OMG [10] in the latest version of the BusinessProcess Modeling Notation (BPMN 2.0)[11].

We find different gaps within choreography proposals wherethe bridge between global business design and executable pro-cesses remains difficult. The principal problems encounteredare 1) Excessive meta-modeling complexity like in BPMN 2.0standard where it is unclear whether or not cognitive principlesare taken into account in managing meta-model’s diagramcomplexity [12], 2) complex executable process alignmentwhere choreography is presented from a global view [5],[8]. As a result, mapping to executable processes becomesa difficult task as different construction blocks are applied[13] and 3) complex business alignment in cases like [14],[9] where no graphical notation is proposed so analysts andbusiness actors, especially novices will have more difficulty inunderstanding and analyzing choreography models.

Our proposal to build the bridge between both worldsrelies on meta-modeling techniques based on abstraction levelsand multiple views as well as graphical representations. Weemphasize the importance of graphical notation to managethe complexity and provide an easier and understandable wayto represent choreographies. Leveled models are presented byMoody in [12] where he empirically prove that reducing a datamodel to chunks of manageable size, complexity is reduced andunderstanding is improved. Multiple views’ separation studiedin [15] are considered to break down a service design intosmaller more manageable parts which are handled by differentstakeholders. We describe the use of these two importantmodeling techniques in Section IV. We show, in a simplifiedway, how both abstract layers and viewpoints should be takeninto account when defining semantics (the meta-model) andin combination with an appropriate graphical notation, aneffective choreography language could be reached.

The rest of the paper is organized as follows. The necessityof choreography in addition to orchestration is argued inSection II. Problems with prior research are presented inSection III. Section IV describes our choreography approach.Paper contributions are resumed in Section V. The graphicalnotation and the meta-model are presented in Section VIthrough a lengthy example that showcases the current results.Section VII define the evaluation protocol used to improve ourproposal. Section VIII concludes the paper and presents thefuture works.

II. CHOREOGRAPHY IN ADDITION TO ORCHESTRATION

As organizations need to manage several service config-urations, composition approaches [16] appear to describe thesequencing and coordination of service invocations. Orchestra-tion and Choreography are two different service compositionapproaches in which we will focus our attention [17]. There isstill a “terminology mess” exposed in [2] when defining thesetwo approaches.

A. Orchestration

Orchestration generally refers to automated execution of adefined process using an execution language such as the WebServices Business Process Execution Language (WS-BPELcommonly known as BPEL) [18]. WS-BPEL is the de-factostandard language for implementing processes based on webservices (orchestrations). An orchestrated process might alsobe exposed as a service that can be invoked. Orchestration iscentered in the execution of one participant’s process. Thereis a central coordinator (the process orchestrator) that invokesexternal services. The external entities ignore that they are partof a bigger process.

As business process complexity increases and depends onother organizations, one-to-one relationships described in or-chestrations remains insufficient to manage complexity whenseveral organizations share common goals. This constraintcan have a negative influence in a global understanding ofthe process limiting its potential capacity of optimization. Aglobal (and preferably graphical) viewpoint in addition to aset of individual viewpoints is required to better understand,build, survey and optimize the global process. Our approachsearches an understanding of choreographies in a gradualand visual way. Our approach will also help to understandthe interests and necessity of this concept when multi-partybusiness processes are designed and analyzed.

B. Choreography

Choreography generally refers to a description of coordi-nated interactions between two or more parties. A choreogra-phy is focused on the interactions between the different partic-ipants from a global viewpoint. Messages exchanged betweenthe different services are tracked. There is no central coordi-nator so all parties know that they belong to a bigger process.It can be understood as a communication protocol betweenparticipants where the messages and the order of invocationsare determined [19]. WS-CDL (Web Services ChoreographyDefinition Language) [5] is the W3C’s recommendation fordescribing choreographies. WS-CDL has been criticized in[20] by Barros et al. as it does not have a clear semanticmodel and it presents a difficult alignment with BPEL. TheWeb Services Choreography Working Group [4] stopped thedevelopment of this language in July 2009 but it remainsa key reference point for choreography languages. Therehave also been other language proposals, mostly developedin research projects. In [21] Decker et al. introduced BPELfor Choreographies (BPEL4Chor) [14] and survey some otherchoreography language proposals such as Let’s Dance [8] or

Fig. 1. A choreography top-down approach

Fig. 2. A choreography bottom-up approach

iBPMN [22] (BPMN’s extension adapted for choreographies).But this concept is still far from being standardized andadopted by the industry.

C. Choreography Complementing Orchestration

In Fig. 1 a choreography top-down approach schema isshown. The choreography acts, in this approach, as the startingpoint (a common understanding) to generate participants’behavioral descriptions or abstract processes. The behavioraldescriptions become a template from which developers definethe executable processes (orchestrations). If each participantrespects the behavioral description generated by a choreogra-phy, interoperability between participants would be reached.In [23] the authors present the advantages of this approachto avoid ambiguities between the global protocol and eachparticipant’s process.

In Fig. 2 a bottom-up approach schema is shown. In thiscase a choreography would be helpful to analyze the overallinteraction behavior. Participants’ behavior could be comparedagainst the choreography. We could then respond to thequestion: are all participants respecting the communicationprotocol? and if not, legal consequences could then result.

We conclude that choreography is necessary to complementorchestration. In this section we have explored some of theinterests of exploiting this concept. We present below theproblems encountered in the different choreography proposals.

III. PROBLEMS WITH PRIOR RESEARCH

We observe the necessity of presenting choreography withdifferent abstraction levels to achieve the propose of fillingthe ’Business-IT Gap’ when dealing with multi-party business

processes. Different choreography proposals such as [11],[14], [9], [24] fail in bringing closer the business and theIT worlds as they do not cover several important issues asabstraction levels, different viewpoints or graphical notationwhen defining choreographies.

A. The Lack of Graphical Notation

On the one hand, service composition languages as BPEL[18] or WS-CDL [5] are mainly based on XML and they do nothave a graphical standard notation. On the other hand, analystsmodel business processes using graphical languages that allowan intuitive and easy reading such as Business Process Man-agement Notation (BPMN). Technical architects search withinBPM graphical solutions to find a way to understand globalprocesses in a more intuitive way. A big effort has been madeto bring closer BPMN and web services. In [25] Wil M.P.van der Aalst et al. survey several important papers regardingthe interests of bridging the gap between business processesand services implementations. The alignment of BPMN andBPEL is officially presented in the standard BPMN. However,we observe that mapping efforts are centered in orchestrationsi.e. in one-to-one relationships between the different externalentities of the process and not in choreographies.

The new choreography representation proposed in BPMN’slatest version seems to tackle this lack of choreography repre-sentation. Choreographies and orchestrations can be illustratedtogether as there is a good alignment between both representa-tions. However, this alignment effort increases complexity andreduces readability of meta-models. A lack of semantic defi-nition for choreographies is detected because no independentimplementation meta-model is presented. Graphical choreog-raphy representation is not fully exploited since not all of thechoreography meta-model concepts are explicitly represented(e.g., the correlation keys or participants’ multiplicity). Thepurpose of this paper is not to criticize BPMN’s choreographyrepresentation, but could contribute to its amelioration. BPMNpresented a totally new representation, along as improvementsand extensions will be introduced.

B. The Lack of Alignment

Two different modeling approaches are found when definingchoreographies. In [19] Decker et al. referred to them as inter-action models and interconnected interface behavior models.In the interaction models, elementary interactions are definedand they became the basic building blocks. Dependenciesbetween interactions are described and simple interactionsare grouped into complex interactions. In the interconnectedinterface behavior models, the control flow is defined perparticipant and then message links join the individual interfacebehavior models. So a choreography is defined as a set ofbehavioral models. The extension of BPEL for choreographiesproposed by Deker et al. in [14] follows the interconnectedinterface behavioral models paradigm.

In [24] the authors make a similar distinction betweena global view and a role-based view or local view. They“choose” the local view to implement choreography as they

Fig. 3. Choreography modeling approaches supported by different proposals

consider that an implementation based on the global view istoo vague.

Both proposals follow the paradigm which is better alignedwith executable process (e.g. BPEL processes). The problemis that they remain far from the business world as they donot represent a real global view but a set of linked parts. Inaddition, no graphical notation is proposed. Other proposalsas Lets’s Dance [8] or BPMN’s extensions like iBPMN [22]choose an interaction model approach where alignment toexecutable processes is more difficult as they give a moreabstract vision. In contrast, we consider interaction modelsnear business processes.

Figure 3 represents both modeling approaches within someimportant proposals. We place interaction model’s approaches(e.g., WS-CDL and Let’s Dance) closer to business pro-cesses as they propose a global and more abstract view.Interconnected interface behavior model’s approaches (e.g.,BPEL4Chor, Multiagent Protocols (MAP) [9]) and collab-oration diagrams in BPMN) are placed nearer executableprocesses because they are more addressed to participants’executable process definition. Both views are useful andnecessary, depending on the context (business or technical)to reach both the business and the IT worlds. Choreogra-phy concept has been adopted as a first-class citizen in thelatest version of the Business Process Modeling Notation(BPMN 2.0). Collaboration diagrams can be combined withchoreography diagrams (between pools). That permits havingboth choreography approaches at the same time. This is animportant step as both approaches are essential to bridge theBusiness-IT gap. We expect that implementations will supportthis possible combination described in the OMG standard.

IV. THE RESEARCH OVERVIEW

Figure 4 depicts an overview of our approach. The threelayered choreography meta-model approach is presented. Thedesign meta-model is based on the one presented by Barroset al. in [20] but enriched with package notation and moredetailed definitions. The analysis meta-model is an abstractionof the design meta-model where the syntax dependencieson WS-CDL were removed. The domain meta-model is anabstraction of the latter where the basic and fundamentalchoreography concepts are represented. Referring to the def-inition of implementation-independent level taken from [19]

Fig. 4. An overview of the research approach

in an implementation-independent level “fundamental deci-sions about interactions are made”, avoiding concrete messageformats or security issues. Notice that our design abstractionlayer for instance is a WS-CDL meta-model (interaction modelapproach). One of our first objectives is to place in thedesign layer a language meta-model that is closer to executableprocess like BPEL4Chor or MAP.

We place the domain and analysis layers near businessprocesses and the design layer near the implementation level.We represent the separation as a wavy area as the separationis fuzzy. By transformation rules, we could move from onelayer to another. Therefore, transitions between the abstractionlayers gradually manage to close the gap between businessprocesses and process implementations. A bottom-up approachwill help to understand and validate executable processesagainst choreography definition. A top-down approach helpsto implement the final executable processes for each partyavoiding ambiguities.

Figure 4 also shows a division in two different views ofeach layer: the structural view and the behavioral view. Thisseparation makes the models easier to read and more under-standable for both designers and developers. The structuralview connects all fundamental components displaying them ina static way. The behavioral view defines the reactions of thedifferent elements to the actions of the others. When analyzingWS-CDL, we identified the elements corresponding either toone view or the other. This separation is represented fromthe first layer (the design meta-model) and maintained in theconsecutive abstractions.

We present a graphical notation corresponding to our do-main and the analysis meta-model. We base our graphicalnotation on the Moody’s Principles of Notations presentedin [26]. The paper defines a set of principles for design-ing cognitively effective visual notations. Below, the nineprinciples are resumed. We detail them when presenting ourgraphical notation explaining how we have taken into accounteach principle. We remark that in some cases, contradictory

situations could arrive when applying them. They are empiricalbest practices rather than exact rules that can always beapplied. The nine principles are presented below:

• Principle of Semiotic Clarity: there should be a one-to-one correspondence between symbols.

• Principle of Perceptual Discriminability: different sym-bols should be clearly distinguishable from each other.

• Principle of Semantic Transparency: visual representationappearance might suggest their meaning.

• Principle of Complexity Management: explicit mecha-nisms for dealing with complexity might be included (e.g.modularization and levels of abstraction).

• Principle of Cognitive Integration: explicit mechanismsto support integration of information from different dia-grams might be included.

• Principle of Visual Expressiveness: the full range andcapacities of visual variables (shape, texture, brightness,size, color and orientation) might be used.

• Principle of Dual Coding: text to complement graphicsmight be used.

• Principle of Graphical Economy: the number of differentgraphical symbols should be cognitively manageable.

• Principle of Cognitive Fit: different visual dialects fordifferent tasks and audiences might be used.

As described before, this paper focuses on presenting thesemantics of the choreography through a layered meta-modeland several modeling techniques to fully exploit this concept.A graphical notation is proposed for the domain and the anal-ysis meta-model that follows the nine principles. Below, thedifferent layers of our choreography meta-model are presentedin parallel with the graphical notation through a scenario.Before this, however we summarize our contributions.

V. CONTRIBUTIONS

In our approach, a graphical notation adapted to our layeredmeta-model is proposed. Our graphical notation takes intoaccount the principles of graphical notation explained byMoody in [26]. These principles settle a scientific base forgraphical notation and critique some current popular notationsas BPMN or UML from different points of view. Althoughnot all of the principles are applicable simultaneously it isimportant to give great value to a graphical notation as it isthe better communication medium through which, to interactwith users. A first graphical proposal was presented in theevaluations detailed in Section VII. After this, a re-evaluationwas done and a newer proposal is presented in this paper inparallel with the meta-model layers.

Our proposal describes choreography as a conjunction ofthree abstraction layers (three meta-models). Within this,both modeling approaches could be represented in the samechoreography concept (interaction models in the analysis leveland interconnected interface behavior model in the designlevel). The domain abstraction level stays above presentingthe fundamental elements of choreography. When meta-modelcorrespondences between layers are formalized, model trans-formations could be defined. As a result, we obtain a funda-

mental view (domain), an abstract viewpoint as an interactionmodel(analysis) and a more specific and technical viewpointof choreography as (interconnected interface behavior mod-els(design) coming under the same choreography definition.For instance, we maintain WS-CDL (interaction model) as ourdesign model as it is our reference language but we consideredworking with a language that is better aligned to executableprocesses like BPEL4Chor or MAP so both approaches wouldbe part of the same choreography definition.

VI. THE CHOREOGRAPHY META-MODEL

This section presents the choreography meta-model througha wedding planner scenario. The scenario depicts the com-munication protocol of a virtual organization that consistsof several businesses that share a common goal. The threeabstraction layers are shown and explained. Alongside thedomain meta-model and the analysis meta-model the graph-ical notation is presented. More detailed explanations of ourgraphical proposition is developed latter in Sections VI-C andVI-E.

A. The Wedding Planner Scenario

An interesting application of choreographies is found whenmodeling virtual organizations’ business processes. A virtualorganization could be considered as ”an alliance for integratingcompetences and resources from several independent realcompanies, that are geographically dispersed” [27]. We presentour approach following a scenario that illustrates a virtualorganization.

4urWed (For Your Wedding) is a Wedding Planner (WP)which assists with planning and organization of weddings.4urWed wants to deliver the bride and groom their dreamwedding for a tempting price. It implements a method toprovide a good and cheap weeding plan to their clients. Fourfirms, have agreed to create a virtual organization with 4ur-Wed by giving special offers. A decentralized communicationprotocol has been established between the firms. There isno central coordinator so communication between them andwithin external suppliers has been optimized.

With this service a couple do not expend to much timein organizing a wedding and dealing with many suppliers.Among the services included by the WP there is websiteavailable with private access to: a detailed order notificationfor tracking all the wedding activities, an automatic check listreminder for scheduling appointments such us visiting venues,choosing decorations, trying on the dress and tasting food.The following are specialized businesses offering differenttypes of services involved in a wedding product or activityspecification.

• Chantal’s Bridal is a seasoned bride and groom wardroberetailer that offers a wide variety of wedding clothing andaccessories from Italian, French, Spanish and Americandesigners. They also offer a qualified seamstress servicefor sizing, tries and alterations if necessary.

• Spark Castle offers halls and ceremony sites (chapel,mosque, synagogue) with an officiator. Spark Castle also

provides tables, chairs, linen, chair covers, crockery andcutlery from an extensive catalogue. They offer profes-sional entertainers to get the party started, offering musicfor all tastes (discos, DJ’s, bands, jazz, chamber music).

• Cater company provides catering for events from smalland intimate dinners to large parties for over 500 guests.It has a talented team of chefs cooking a customizedmenu with locally sourced products and a trained and wellpresented staff to serve dinner and special drinks. Cateralso proposes several cake confectioners specializing inwedding cakes.

• Wedding Studio comprises of highly talented photogra-phers offering up to five hours of their service for thetaking of the wedding photos.

The previous businesses constitute the virtual organizationwith 4urWed. Other extra services are offered by externalcompanies. The virtual organization will choose dependingon the clients requirements. Wedding requirements have beensimplified to present our meta-model and graphical notationin a more understandable way.

• A team of floral designers might be needed to provideceremony decorations, centerpieces and bouquets.

• The transportation service might offer vehicles for thebride and groom such as a limousine or carriage as well ascoaches and buses to transport guests from the ceremonyto the reception and back to the city center.

Scenario:Consider that Joe and Maria are planning to get married.

They decide to accept wedding planner services for organizingtheir wedding. Corresponding to 4urWed proposals, Joe andMaria choose the ceremony site, the catering including themusic, and the extra transportation service. They also opt forthe retailer service to make it perfect on such a special day.They do not contract a photographer as Maria’s uncle is incharge of the wedding photos.

This scenario is used to present the different layers of themeta-model and the corresponding graphical notation.

B. The Domain Meta-Model

Figure 5 and Fig. 6 show the domain meta-model where thefundamental elements of a choreography are presented.

From a structural viewpoint, let us consider the com-munication protocol (Choreography) that has a set of roles(Role) linked in relationships (Relationship). A relationshiprepresents the existence of knowledge between both roles. Arole is an abstract entity (e.g. Wedding Planner and CateringProvider and Transporter) played by a participant (Partici-pant) that is the concrete entity (e.g. 4urWed or Cater). Aparticipant may play multiple roles in a choreography (e.g.Spark Castle playing site provider role and music provider).Several participants could be defined (in design time) to playthe same role. However, when executing the global process,an unique participant will play a role in the choreography.This approach respects the flexibility of web services, whereend-points can be defined at run time.

Fig. 5. The domain meta-model - Structural view

Fig. 6. The domain meta-model - Behavioral view

From a behavioral viewpoint, a choreography is definedas a set of interactions (Interaction) between two roles (e.gan interaction can be the provision of the wedding cakebetween the catering provider and the cake confectioner). In aninteraction Wedding Cake Provision there is a role transmitter(sourceRole), which is the one who starts the interaction (e.gthe Catering Provider), and a role receiver (targetRole)(e.g.the Cake Confectioner). An interaction is a logical name fora communication between two roles.

We retain from this layer that the first elements to beidentified in a choreography are the roles and optionally theparticipants playing that roles. Then, a set the interactionsbetween roles (behavioral) that implies defining their relation-ships in a static way.

C. The Domain Graphical Notation

The wedding scenario is illustrated in Fig. 7. Domain meta-model terms are graphically modeled. This structural viewshows the roles, the participants playing those roles and therelationships between them. We add behavioral interactions asthe low number of concepts in both views permit us to clearlyexpress them in an unique representation.

The explanation of this graphical notation is illustrated inFig. 8. We represent the roles (e.g. Client or Transporter)appearing in the wedding scenario with a gray rectangle.The participants playing the roles are defined by a whiteoval (e.g 4urWed or Cater) and they are linked to theircorresponding role by a thin line. Relationships between rolesare represented by a thick line. Arrows indicate the “direction”

Fig. 7. Domain model of the wedding planner choreography - Structuralview plus interactions

Fig. 8. Explanation of the the domain graphical notation

of the interactions i.e the source role and the target role withinthe corresponding interaction.

In Table I we survey the graphical notation principles whichare taken into account when representing a choreography in thedomain layer. We present each principle and the correspondingapplication.

We observe that most of the graphical notation principlesare considered. However, there are some of them as theprinciples of Complexity Management, Cognitive Integrationor Cognitive Fit that are not yet applicable in this layer.Therefore they are analyzed in Section VI-E where analysisnotation is surveyed.

D. The Analysis Meta-Model

The analysis meta-model presented in Fig. 9 and 10 is thelayer in which are represented the elements that must appear inevery choreography definition independently of the syntax. Weintroduce in this layer the control flow mechanisms and themessages exchanged between the choreography participantsvia the service operations. This layer has its origin in WS-

Principle ApplicationSemioticClarity

We observe one-to-one correspondence betweenthe meta-model concepts and their graphicalnotation. Interactions are the exception case aswe link the concepts of fromRole and toRole tothe black arrow’s direction and not to the rolerepresentation.

SemanticTransparency

This point is difficult to set up in a chore-ography representation but it could be an im-provable issue. When defining roles, partici-pants and interactions, we do not use visualrepresentation whose appearance suggests theirmeaning. Relationships and the interactions aremore suggestive.

PerceptualDiscrim-inability

Visual distance between elements, and visualvariables are taken into account. Each graphicalsymbol has an unique value on at least onevisual variable. Different shape (e.g. role vsparticipant), color (e.g interaction vs participant)or texture (e.g. role’s relationship vs participantplays role) are applied.

Visual Ex-pressiveness

We use the shape as primary visual variable fordistinguishing between the graphical elements.Color, size, texture and position variables arealso used to discriminate graphical elements.

Dual Coding In general, we have not used text to complementgraphic elements. We think that notation is easyenough to avoid text aid.

GraphicalEconomy

The number of graphical symbols is seven.We find role, participant, relationship, interac-tion, link between participant and role, blackarrow defining interaction’s direction and thelink between an interaction and a relation-ship. This number is cognitively manageable forstakeholders.

TABLE ISURVEY OF GRAPHICAL NOTATION PRINCIPLES - DOMAIN

CDL meta-model so it can be seen as an interaction modelapproach (meta-model in our case), where the main elementis the interaction.

We explain the analysis meta-model through the sameexample but extended. A participant that plays a role mustprovide the services (Service) defined for that role to respectthe choreography. Note that we consider a service as a logicalentity i.e the way to access the set of defined operations (Oper-ation). Each operation defines a request message (request) andoptionally, a response message (response) and error messages(errorMessages). We present messages as statical elementscorresponding to an operation. When an operation is defined,we would also have to define its corresponding messages.

In the behavioral view, we introduce some new elements.As a choreography is a set of ordered interactions betweenroles, we need mechanisms to compose and order them. Weintroduce the behavioral step class (BehavioralStep) as a gen-eralization of control flow (ControlFlowStep) and interactions(Interaction). A ControlFlowStep can be choice (Choice),parallel (Parallel) and sequence (Sequence) activities. When anoperation is invoked in an interaction, it has to be an operationdefined within the targetRole’s services. For example, in theinteraction Menu Provision the Wedding Planner could invoke

Fig. 9. The analysis meta-model - Structural view

Fig. 10. The analysis meta-model - Behavioral view

an operation provideCatering implemented by the CateringProvider in the service PlannerToCateringService. A requestmessage requestCateringMsg and a response message cater-ingResponseMsg might be defined in this operation.

The domain meta-model and the analysis meta-model re-spectively are close. The domain meta-model is included inthe analysis meta-model (classes in white) where some domainclasses are refined to go into details such as Interaction andRole.

E. The Analysis Graphical Notation

Figure 11 and Fig 11 represent the Wedding Planner’schoreography model (corresponding to the analysis meta-model). Figure 13 and Fig. 14 explain all the elementsused in the graphical notation. Figure 13 is focused on theelements that have been added from the domain’s structuralrepresentation. A service (ClientToPlannerService) attached

Fig. 11. Analysis model of the wedding planner choreography - Structural view

Fig. 12. Analysis model of the wedding planner choreography - Behavioral view

Principle ApplicationSemanticTransparency

From a global viewpoint, representation ap-pearance of choreography suggests the meaningof the concept. Structural diagram suggest astatic way of choreography representation whilea behavioral representation based on sequencediagrams, suggest dynamic interactions.

ComplexityManagement

We introduce explicit mechanisms for dealingwith complexity. Different notations are pre-sented for the domain and the analysis represen-tation (abstractions levels). Different viewpoints(structural and behavioral) are also representedwith different graphical notations in the analysismodel (modularization).

Cognitive In-tegration

Explicit mechanisms to support integration of in-formation from different diagrams are included.We maintain a similar representation in domainand analysis models. We also observe an inte-gration mechanism as roles are represented inan equivalent way from the structural to thebehavioral view in the analysis model. Thisequivalence permits an easy transition to oneviewpoint to another.

Cognitive Fit We use different visual dialects for differenttasks when representing in a totally differentway the structural and the behavioral viewsof choreography. However we not provide adifferentiation according to the possible differentaudience.

TABLE IISURVEY OF GRAPHICAL NOTATION PRINCIPLES - ANALYSIS

to a role (Wedding Planner) is described. We illustrate anexpanded service where operations (e.g. requestPlan) aredefined. The three types of messages found are: an inputmessage (e.g. requestPlanMsg), a response message (e.g.AcknowledgmentMsg) and an error message (e.g. ErrorMsg).We observe that both services and operations can be expanded(–) or collapsed (+). The possibility to expand or collapsemake the models more readable.

Figure 14 explain the behavioral view which is basedon sequence diagrams. In this case, a role (Client) inter-acts with another role (WeddingPlanner) calling an operation(requestPlan) that is provided in the role receiver’s servicedefined in the structural view (ClientToPlannerService). Theinteraction is represented by the arrow and the operation aboveit represents the operation called in that interaction.

We survey in Table II several graphical principles taken intoaccount to define the analysis graphical notation. We do notanalyze all of them since they have already been analyzedin Section VI-C and they are equivalently applied for thisnotation.

F. The Design Meta-Model

Our design meta-model is a WS-CDL’s meta-model basedon the one presented by Barros et al. in [20] but enrichedby dividing it in different packages. The packages that areconsidered following the WS-CDL’s syntax are: Informa-tionType, Choreography (Structural), RoleType, Interaction,Activity and Choreography (Behavioral). These packages are

Fig. 13. Explanation the analysis graphical notation - Structural view

Fig. 14. Explanation the analysis graphical notation - Behavioral View

the starting point of our bottom-up approach. The viewpointseparation can be extracted from WS-CDL’s choreographydefinition where roles, participants, relationships and messagetypes are defined separately from the interactions sequencing.In [5] more detailed examples can be found. In general, themain package’s classes have a corresponding meta-class in thehigher abstraction levels as for example Interaction, Role orChoreography. Showing this meta-model is not dicussed bythis paper which is more centered on the graphical notationcorresponding to both domain and analysis meta-model.

VII. EVALUATIONS

To evaluate the meta-model and the graphical notation thatwe propose, we performed an experiment within service and/orbusiness process specialists. This evaluation was designed andanimated with the assistance of Nadine Mandran from theMarvelig platform [28]. The methods that are used are inspiredin [29], [30], [31]. The results of this evaluation helped to im-

Hypothesis 1Our meta-model represents well the semantics forchoreographies

Evaluation methodThe subjects understand and evaluate our meta-model

Protocol

• To classify the subjects, we first ask them to fill out aquestionnaire about their work habits.

• We explain the concept of choreography presentingrapidly the meta-model.

• We propose a choreography scenario described in nat-ural language.

• The subjects identify concepts within meta-model inthe proposed scenario. Are all concepts in the scenariocorresponding to a term in the meta-model? Are theremissing concepts?

• The subjects comment the meta-model by completinga table where they are asked to identify the missingconcepts of the meta-model and those that seem super-fluous.

Material

• Presentation of the choreography and the meta-model.• Sheet with the three layered meta-model.• Sheet with the scenario• Questionnaire habits: choreography, business process,

and virtual organization definitions, familiarity with thelanguages (web service, BPMN, etc.).

• Final Questionnaire: missing or unnecessary concepts.

TABLE IIIEVALUATION - HYPOTHESIS 1

prove both choreography meta-model and graphical notation.This empirical experimentation results in a re-evaluation ofour proposal, where several updates were done a posteriori.In this paper, the updates and ameliorations proposed havealready being taken into account. We explain some of the mostimportant modifications issue of this evaluation.

The experimentation is based on two hypotheses. Firstly,ourmeta-model represents well the semantics for choreographies.Secondly, our graphical notation is appropriate for describingchoreographies. The first hypothesis is based on the identifi-cation of the meta-model concepts within a textual scenario(where a choreography could be applied). The validation of thesecond hypothesis relies on the identification of the notationprinciples and the comparison against the new choreographyrepresentation presented in the latest version of BPMN.

The evaluation protocol of each hypotheses are detailed inTables III and IV. The participants were 8 services and/orbusiness processes specialists. The experiment took place in ameeting room and lasted three hours.

The first questionnaire helps to recognize the differentsubjects’ profile when analyzing their work during the ex-perimentation. We categorize their responses in: Very Often(VO), Often (O), Sometimes (S), Never (N) or if they donot know that concept (DK). With this questionnaire weremark that the majority of the subjects used to use conception

Hypothesis 2Our notation is appropriate for representing choreographies

Evaluation methodIdentification of notation principles and comparison againstBPMN 2.0’s choreography notation.

Protocol

• We present our graphical notation and BPMN’s graph-ical notation illustrating the scenario.

• We provide the graphical models based on the first partscenario so the example is already known.

• Next, we divide the subjects into two focus groups:one group defends our graphical notation and the otherBPMN’s notation. We identify the positive and the neg-ative points for each representation by the confrontationof ideas of both homogeneous groups.

• Finally, each subject individually critic the graphicalnotation indicating the strengths and weaknesses foreach notation by completing a final questionnaire.

Material

• Presentation of BMPN 2.0 for our graphical notationand choreography.

• Two sheets illustrating the scenario with both notations.• Final questionnaire: weaknesses and strengths for the

both notations.

TABLE IVEVALUATION - HYPOTHESIS 2

techniques when developing their technical works (VO=4;O=2; S=2; N=0). They are generally comfortable with servicetechnology (VO=1; O=4; S=1; N=2). Disperse knowledge inbusiness process domain is observed (VO=3; O=1; S=0; N=2;DK=1). They identified some important technologies relatedwith web services (e.g., BPEL, WS-CDL, Web Service De-scription Language (WSDL), Universal Description Discoveryand Integration (UDDI), Service Oriented Architecture (SOA),...) as well as modeling standards for representing businessprocess (e.g., BPMN or UML).

We will not analyze in detail the results of the evaluationas we evaluated a previous version of our meta-model andgraphical notation not presented in this article. What we wantto highlight in this section is that empirical experimentationsis a useful manner to evaluate and improve these type ofproposals. However it remains not evident how to validate andmeasure results when working with such an abstract concepts.We considered performing new evaluations following a similarprotocol so we could obtain direct feedback from potentialusers.

We resume some important conclusions obtained from thisevaluation below:

• The analysis layer terms were too syntactically closeto WS-CDL. We were not presenting terms in animplementation-independent way as we currently do forthe analysis level. That was the major problem thatspecialists where facing. WS-CDL syntax terms wherenot intuitive for them. The difference between the term

“exchange” and “interaction” was confusing. WS-CDLconsiders that several exchanges belong to an interaction.This consideration created confusion. We update thisnotion of “exchange” introducing the term Message, sothe concept Interaction is simplified and becomes a setof messages (implicitly, message exchange).

• Another important comprehensibility problem, was thefact of maintaining the analysis classes with the typesuffix as WS-CDL does (e.g., ParticipantType, RoleType,RelationshipType. We thought it better to avoid this suffixso as to not generate confusion. Analysis and domain’smeta-model are now semantically clearer than before. Inthe analysis meta-model we just want to illustrate forexample that a Participant plays a Role and between tworoles a Relationship is defined . No type suffix is neces-sary to express these relationships between concepts.

• An unclear separation between structural and behavioralviews was also criticized. For example, we used the termBehavior as WS-CDL does. In WS-CDL, a Role Typeenumerates the observable Behavior a party exhibits inorder to collaborate with other parties. We consideredthis concept as a structural (static) property, but theterm “behavior” is confusing. It was replaced by Servicewhich represents in this case the same concept (what arole can offer to other parties) but it is more explicitand stays coherent with the structural-behavioral division.Specialists, however, found however an important anduseful point to make this separation. Representing themin different graphical ways also helped to underline thedifference between both viewpoints.

• In the structural view, we represented only participants,roles and relationships between roles. It was proposed inorder to enlarge this representation making it more useful.We therefore enriched the analysis’ structural meta-modelso that more necessary concepts could be represented inthe structural view. That implied enriching its correspond-ing graphical notation respecting the principle of SemioticClarity[26] that advocates a one-to-one correspondencebetween semantic and syntactic concepts. The result wasa richer and more representative static view which ispresented in Section VI-E.

• The majority of the specialists found the use of a be-havioral representation inspired by sequence diagramsintuitive and easy to apply. However, they remark thedifficulty in managing complexity when representingcomplex processes. UML’s sequence diagrams providea reference mechanism to manage complexity so thisproblem could be resolved in future extensions. Thepopularity of UML diagrams make the appropriatenessof this notation easier than new notations.

• The use of integration mechanisms between representa-tions was appreciated. Developing the coherence betweendiagrams has been one of our prior points.

VIII. CONCLUSION AND FUTURE WORKS

In this paper we have presented the choreography con-cept with three complementary abstraction layers. We mainlypresent the semantics of choreographies (the domain and theanalysis meta-model). We have also presented the Moody’sgraphical notation principles and we used them to evaluateour domain and analysis graphical notation. We note that thesegraphical notation principles are more easily supported thanksto the modeling techniques applied which are the leveledmeta-models (domain, analysis and design) and the views’separation (structural and behavioral).

A design meta-model that has good alignment to executableprocess is considered to reduce the “Business-IT Gap”. Formalcorrespondence between meta-model levels might be defined toautomate as much as possible the gradually transitions betweenthe layered meta-models. We highlight the lack of verticalalignment of current proposals to business or technical worldsand the fact that usually, graphical notations rely on commonsense, intuition and emulation of common practice, ratherthan adopting a rigorous scientific approach [32]. The pointsthrough which we base this paper, (meta-modeling techniquesand graphical notation) must be prior researches to bridge thegap between business and technical worlds. Finally, to betterformalize our graphical notation, we should also work on thegraphical notation meta-model describing it separately fromthe semantics.

Existing evaluations of choreography definition languagesare based on Service Interaction Patterns [33], but thesepatterns only cover one perspective into the requirementsfor choreography definition languages. In future works, weconsider to identify and categorize choreography requirementsregarding the most important research axes for choreographiesas meta-modeling techniques, monitoring benefits [34], tech-nical needs such as the ones identified in [21] or graphicalnotation’s scientific background [26] in addition to interactionpatterns. A meta-model extension is considered to supportthese patterns, as well as identified requirements. At thepresent, this was not our top priority.

Given the effort that this would require, we did not go as faras defining a new choreography language nor a new graphicalnotation. Our various suggestions are thus not meant to be aBPMN’s 2.0 substitute for choreographies. However, we deemthat they have a value in illustrating useful techniques andnew perspectives to cross. We hope they will be considered assources of inspiration and debate by the BPM(N) communityand other choreography proposals.

ACKNOWLEDGMENTS

I would like to specially thank Dominique Rieu and SophieDupuy-Chessa for their feedback. I would also like to thankGabriel Pedraza, German Vega, Emma Rosser and AurelienFaravelon for their helpful comments. This work was sup-ported by the ANR MOANO project.

REFERENCES

[1] M. Papazoglou and W. Heuvel, “Service oriented architectures: ap-proaches, technologies and research issues,” The VLDB JournalTheInternational Journal on Very Large Data Bases, vol. 16, no. 3, pp.389–415, 2007.

[2] F. Daniel and B. Pernici, “Insights into web service orchestration andchoreography,” International Journal of E-Business Research, vol. 2,no. 1, pp. 58–77, 2006.

[3] S. Vinoski, “WS-nonexistent standards,” Internet Computing, IEEE,vol. 8, no. 6, pp. 94–96, 2004.

[4] WSC, “Web services choreography working group,” ”http://www.w3.org/2002/ws/chor/”, 2002.

[5] W3C, “Web services choreography description language version 1.0 -w3c candidate recommendation,” ”http://www.w3.org/TR/ws-cdl-10/”,2005.

[6] S. Ross-Talbot, G. Brown, K. Honda, N. Yoshida, and M. Car-bone, “Pi4soa technologies fundation,” ”http://sourceforge.net/apps/trac/pi4soa/wiki”.

[7] L. Fredlund, “Implementing ws-cdl,” in Proceedings of the secondSpanish workshop on Web Technologies (JSWEB 2006), 2006.

[8] J. Zaha, A. Barros, M. Dumas, and A. ter Hofstede, “Lets dance: Alanguage for service behavior modeling,” On the Move to MeaningfulInternet Systems 2006: CoopIS, DOA, GADA, and ODBASE, pp. 145–162, 2006.

[9] A. Barker, C. Walton, and D. Robertson, “Choreographing Web Ser-vices,” IEEE Transactions on Services Computing, vol. 2, no. 2, pp.152–166, 2009.

[10] OMG, “Object management group,” ””http://www.omg.org/”, 1989.[11] ——, “Business process management notation (bpmn 2.0),” ”http://

www.omg.org/spec/BPMN/2.0/”, 2010.[12] D. Moody, “Complexity effects on end user understanding of data

models: An experimental comparison of large data model representa-tion methods,” in Proceedings of the Tenth European Conference onInformation Systems (ECIS’2002). Citeseer, 2002, pp. 6–8.

[13] J. Mendling and M. Hafner, “From WS-CDL choreography to BPELprocess orchestration,” Journal of Enterprise Information Management,vol. 21, no. 5, pp. 525–542, 2008.

[14] G. Decker, O. Kopp, F. Leymann, and M. Weske, “BPEL4Chor: Extend-ing BPEL for modeling choreographies,” in Web Services, 2007. ICWS2007. IEEE International Conference on. IEEE, 2007, pp. 296–303.

[15] R. Dijkman and M. Dumas, “Service-oriented design: A multi-viewpointapproach,” International journal of cooperative information systems,vol. 13, no. 4, pp. 337–368, 2004.

[16] N. Milanovic and M. Malek, “Current solutions for web service com-position,” IEEE Internet Computing, vol. 8, no. 6, pp. 51–59, 2004.

[17] C. Peltz, “Web services orchestration and choreography,” Computer, pp.46–52, 2003.

[18] OASIS, “Web services business process execution language v2.0,” ”http://www.oasis-open.org/committees/tc home.php?wg abbrev=wsbpel”,2007.

[19] G. Decker, O. Kopp, and A. Barros, “An introduction to servicechoreographies,” Information Technology, vol. 50, no. 2, pp. 122–127,2008.

[20] A. Barros, M. Dumas, and P. Oaks, “A critical overview of theweb services choreography description language,” BPTrends Newsletter,vol. 3, 2005.

[21] G. Decker, O. Kopp, F. Leymann, and M. Weske, “Interacting services:from specification to execution,” Data & Knowledge Engineering,vol. 68, no. 10, pp. 946–972, 2009.

[22] G. Decker and A. Barros, “Interaction modeling using BPMN,” inProceedings of the 2007 international conference on Business processmanagement. Springer-Verlag, 2007, pp. 208–219.

[23] S. Ross-Talbot, G. Brown, K. Honda, N. Yoshida, and M. Carbone, “Soabest practices: Building an soa using process governance,” 2009.

[24] Z. Qiu, X. Zhao, C. Cai, and H. Yang, “Towards the theoreticalfoundation of choreography,” in Proceedings of the 16th internationalconference on World Wide Web. ACM, 2007, pp. 973–982.

[25] W. Van Der Aalst, M. Dumas, A. Ter Hofstede, N. Russell, H. Verbeek,and P. Wohed, “Life after BPEL?” in Formal techniques for computersystems and business processes: European Performance EngineeringWorkshop, EPEW 2005 and International Workshop on Web Servicesand Formal Methods, WS-FM 2005, Versailles, France, September 1-3,2005: proceedings. Springer Verlag, 2005, p. 35.

[26] D. Moody, “The Physics of Notations: Toward a Scientific Basis forConstructing Visual Notations in Software Engineering,” IEEE Trans-actions on Software Engineering, pp. 756–779, 2009.

[27] L. Priego-Roche, D. Rieu, and A. Front, “A 360 Vision for VirtualOrganizations Characterization and Modelling: Two Intentional LevelAspects,” Software Services for e-Business and e-Society, pp. 427–442,2009.

[28] L. d’Informatique de Grenoble (LIG), “Marvelig: Ppinired’exprimentation scientifique,” ”https://marvelig.liglab.fr/doku.php”.

[29] N. Berthier, “Les techniques denquete en sciences sociales,” Methode etexercices corriges. Armand Colin/HER, Paris, France, 2000.

[30] J. Langford and D. McDonagh, Focus groups: supporting effectiveproduct development. CRC, 2003.

[31] P. Runeson and M. H”ost, “Guidelines for conducting and reporting case study research insoftware engineering,” Empirical Software Engineering, vol. 14, no. 2,pp. 131–164, 2009.

[32] N. Genon, P. Heymans, and D. Amyot, “Analysing the CognitiveEffectiveness of the BPMN 2.0 Visual Notation,” Software LanguageEngineering, pp. 377–396, 2011.

[33] A. Barros, M. Dumas, and A. Ter Hofstede, “Service interaction patterns:Towards a reference framework for service-based business processinterconnection,” Faculty of IT, Queensland University of TechnologyFIT-TR-2005-02, 2005.

[34] B. Wetzstein, D. Karastoyanova, O. Kopp, F. Leymann, and D. Zwink,“Cross-organizational process monitoring based on service choreogra-phies,” in Proceedings of the 2010 ACM Symposium on Applied Com-puting. ACM, 2010, pp. 2485–2490.