HAL Id: inria-00597070https://hal.inria.fr/inria-00597070

Submitted on 15 Jun 2011

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

From Business Process to Component Architecture:Engineering Business to IT Alignment

Karim Dahman, François Charoy, Claude Godart

To cite this version:Karim Dahman, François Charoy, Claude Godart. From Business Process to Component Architec-ture: Engineering Business to IT Alignment. The Scientific Workshop on Service-oriented EnterpriseArchitecture for Enterprise Engineering, Aug 2011, Helsinki, Finland. 2011. <inria-00597070>

From Business Process to Component Architecture:Engineering Business to IT Alignment

Karim Dahman, Francois Charoy, Claude GodartUniversite de Lorraine, UHP - LORIA

BP 239 54506 Vandoeuvre-les-Nancy Cedex, France{karim.dahman, francois.charoy, claude.godart}@loria.fr

Abstract—Maintaining the alignment between the Business andIT is of high strategic relevance in today’s enterprise roadmap. Inthis paper, we follow our previous assumption that this alignmentwill be better maintained if we are able to ensure a clearconceptual alignment between the Business Processes and theSoftware Architectures. As our aim is to provide an environmentthat would flawlessly support evolutions of the processes or of thearchitecture while maintaining this alignment, we build on theformal foundation that we have developed to ensure it and showshow it can be actually developed with current Model DrivenEngineering technologies.

Index Terms—Unidirectional Model Transformation, Business-IT Alignment, BPMN, SCA, Conceptual Mapping, ATL

I. INTRODUCTION

For any enterprise that aims to conduct a successful Busi-ness, being able to model its architecture is now an impor-tant asset. Furthermore, being able to relate this businessarchitecture to its supporting Information Technology (IT)is recognized as a driver for the efficiency of enterprisecomputing resource management. One of the claimed goal forthe integration between the business dimension and the IT di-mension is to allow the agility in conducting the business, andadapting it to evolving business demands. The challenges toenforce this alignment from the business strategic perspectiveto the IT still need to be addressed. New approaches promotedthrough Service Oriented Computing (SOC), Business ProcessManagement (BPM) and Enterprise Architecture are meant tobe efficient enablers of this alignment and of its maintenance.Among these three disciplines, the BPM along with the SOCparadigm have an interesting quality. The BPM provides adirect bridge with almost no transformation between analysis,design, implementation and execution. Moreover, the SOC issupported by the Service Oriented Architecture (SOA [1])architectural foundation, and has emerged as a new computingparadigm for designing, building and using software appli-cations to support business processes. The Business ProcessModeling Notation (BPMN 2.0 [2]) standard-related practicestry to sustain this bridge by letting business analysts andapplication architects work on the same readily understandablemodel to obtain a (business process driven) software system.

We are still far from the streamlined experience wherewe could derive deployable software artifacts with soundarchitectural foundation from a BPMN collaboration diagram.This is even more true when we need to take into accountthe deployment topology of heterogeneous, distributed and

continuously changing IT environments to support the processexecutions. Our goal, however, is to show that it would bepossible to automate that business production line from theservice-enabled process dependencies into the architecturalsoftware settings and its maintenance, while using the industryrecognized standards like the BPMN and the Service Compo-nent Architecture (SCA 1.1 [3]). In a previous work [4], wehave shown that its was possible to leverage the Model DrivenEngineering (MDE) to generate SCA models from a subset ofthe BPMN models. The contribution of this paper is to demon-strate how these theoretical results can be implemented usingcurrent model transformation technologies. For this purpose,we have developed an ATLAS Transformation Language (ATL[5]) transformation chain that is able to generate canonicalSCA artifacts from a BPMN collaboration model. We havealso identified how this technology will be an issue for ourfuture development to maintain the Business Processes/SOAAssets alignment as it does not support incremental transfor-mations. This is an important problem regarding the goal thatwe are pursuing: being able to keep the consistency and tomaintain the alignment of the processes with the softwarearchitectures in every directions (i.e., round tripping), thussupporting agility from the realistic business settings withcomplex IT environments.

The next section of this paper is a short reminder of ourprevious work. Section III describes the theoretical resultfor the implementation of our ATL transformation chain inthe Eclipse development environment [6]. In Section IV, wesituate our work through the related research and discuss thelimit that we have encountered during this work. The last partconclude that work with a brief evaluation of other alternatives.

II. BACKGROUND AND FORMAL FOUNDATIONS

Typically, the Business Process Modeling combines graph-ical and textual annotations to specify the business processmodels that are decoupled from their supporting technicaland software architectures. Several languages can be used tospecify the business service interactions at different levels ofabstraction [7]. Specially, the BPMN collaboration modelsexpress and put in logical relation the exchanges betweenthe internal processes of service-enabled business networks.They aim at coordinating an explicit exchange of informationthrough automated service interactions under the control ofa single endpoint, called orchestration process [1]. In the

SOC those processes are mapped into models that describeservices in a uniform and technology-independent way. At thislower abstraction level, i.e., the IT level, they describe theconfiguration of the so-called SCA assembly models whichare organized in a SOA. The SCA assemblies modularizeand compose service-enabled business functions in a mannerthat is decoupled from their application code. The SCAprovides an Architecture Description Language (ADL) thatoffers means to define platform independent component kitarchitectures and a path from the business goals to the programcode (e.g., executable process languages). With a graphicalnotation support, it describes composites of components, theirconnections and other related artifacts which specify how thecomponent functions are externally consumed and/or offered.

The SOC extends the Component Based Developmentparadigm which states that applications expose their func-tionality as services in a uniform and technology-independentway such that they can be provided and invoked over loosely-coupled architectures. Consequently, the service-enabled busi-ness functions can be implemented as components with re-motely published interfaces in a network. Our previous workhas introduced a MDE approach for the automated generationof (target) canonical SCA assembly models from (source)core BPMN collaboration models, and specified relationsamong their metamodels as conceptual mappings [4]. In oursemantics, models are conform to a metamodel. As a partof this view, the models are viewed as assorted collectionsof typed objects with attributes, and typed links among theobjects. The mapping between the heterogeneous BPMN andSCA models are viewed as rules that establish relations be-tween the model types. We refer to the program executions thatimplement conceptual mappings as transformations. Figure1 depicts an example of a model transformation which willbe used through the reminder of this paper. It illustrates fewsituations that occur when the “task-driven process logic” hasto be transformed into the “component composition logic”. Inthe next section, we present the syntax of those models.

A. The BPMN and SCA Model Syntaxes

At the BPMN level, the processes are focused on thecomposition of services in a business driven-fashion, i.e., theorchestration process, and in that sense the business servicesbecome process activities. Moreover, the processes becomecomposite business services that orchestrates other servicesand the business service networks are modeled as BPMNcollaborations. A collaboration refers to the interactions be-tween a collection of participants which represent the businessentities or roles. They form a business service network anddefine the business process logic of each partner pertaining to adomain being modeled. The BPMN refers to a service orches-tration as a participant’s private process. Consider, the well-known BPMN dealing network example [2] depicted in Figure1. In this business service network, a retailer provides anordering service to a customer partner. In order to provide thisservice, the retailer establishes business links with other part-ners (e.g., scheduler, invoicer, and a shipper), and orchestrates

Dealing Network

Ord

erS

hipm

ent

Invo

ice

Sch

edul

e

Receive Order

InitiatePrice

Calculations

CompletePrice

Calculations

RequestShippingSchedule

ReceiveShippingSchedule

SendShippingSchedule

Ret

aile

r

StartEvent

SequenceFlowConversation

BPMN Collaboration Graphical Constructs

ConversationLink

ServiceReference

Service or Reference Callback Wire

ImplementationComposite ComponentEndEventSendTask ReceiveTask

Poo

l

Process

SCA Assembly Graphical Constructs

ParticipantFork/Join Parallel

Gateway

Request Product

Scheduling

Shipping

InvoicerCustomer

ShipperScheduler

Retailer InvoicerCustomer

Target Canonical SCA Assembly Model

Source Core BPMN Collaboration Model

Dealing Network

ReceiveProduct

Scheduling

Scheduling

ProcessInvoice

Invoicing

Send Invoice

Ordering

Receive Order

Send Invoice

ShippingStart

InitiatePrice

Calculations

CompletePrice

Calculations

ProcessInvoice

RequestShippingSchedule

ReceiveShippingSchedule

SendShippingSchedule

Ord

erS

hipm

ent

Invo

ice

Sch

edul

e

Partitioned Core BPMN Collaboration Model

Dealing Network

SchedulingEnd

SchedulingEnd

ShippingIntermediate

ShippingEnd

Request Product

Scheduling

ReceiveProduct

Scheduling

SchedulingStart

InvoiceStart

InvoiceStart

InvoicingEnd

ShippingStart

ShippingEnd

ShippingIntermediate

InvoicingEnd

SchedulingStart

Promotion

Retailer

Invoice

Order

Schedule

Shipment

ShipperScheduler

Fig. 1. BPMN-to-SCA transformation example and languages constructs.

their exposed services: scheduling, invoicing, and shipping. Tosustain the separation of concerns in the service “orchestrationlogic” [8], the retailer participant’s private process is modeledwith different sub-roles (e.g., order, schedule, invoice andshipment). Those roles contain tasks which invoke or provideoperations for a single external service provider (i.e., relative

to the retailer). The collaboration specifies the behavioraland architectural views of the business structures and theirparticipant roles. The business links between participants aremodeled as conversations that capture the service contracts.Formally, we define those models as below.

Definition 1 (Source Core BPMN Collaboration Model):A source core BPMN collaboration model is a tuples = (P ,R,A,A�,A�, E ,F , conv,H,L) where P is a setof participants which can be partitioned to disjoint setsof sub-roles R and interaction tasks A which can bepartitioned into disjoint sets of send tasks A�, receivetasks A�, E ⊆ P × P is a participant association relation,F ⊆ A×A is the sequence flow relation between the tasks,conv : ∪p∈PAp → ∪p∈PAp is an injective function whichmaps interaction tasks, H = {(a, a′) ∈ Ap × Ap′ | ∃p,p′∈Pconv(a) = a′} is the conversation relation, and L ⊆ R ×Ais a process relation.

Likewise, when mapped to the SCA space, the servicesbecome components. The processes are executed by service-components that contain the effective implementation artifacts.The inter-component interactions are conceptually similar tothe inter-process invocations. Consequently, the conversationsbetween processes can map to the connectors between com-ponents. It must to be noticed, that we intentionally hidedefinition of the rest of BPMN constructs shown in Figure1 (e.g., events, sequence flows and gateways), since thosetypes have not conceptually equivalent counterpart types inSCA as explained in Section II-B. In order to generatesound component compositions we have introduced in [ 4] atechnique that emphasizes the separation of service modelingconcerns between the BPMN design space and the SCAlevel. This technique, which we called orchestration processpartitioning, is intended for avoiding the straight mapping ofthe inter-task dependencies to the component connectors. Asshown in Figure 1, it transforms the inter-task control flowof a single orchestration process with different roles, e.g.,retailer, into a new collaboration between separated processes,with singular roles. Also, it decomposes monolithic “task-driven logic” into functionally equivalent decoupled logics.Each resulting participant, e.g., order, schedule, invoice andshipment, contains its own private process with additionalsynchronization tasks.

Due to the lack of space, we do not give details of the parti-tioning algorithm. Those processes directly interact with eachother with additional conversation. Formally, for any p ∈ P ,the subset of interaction tasks Ap that have conversations withthe same external participant (i.e., service denoted p ′′ ∈ P)is denoted Ap��p′′ = {a ∈ A�

p ∪ A�p | ∃a′′ ∈ Ap′′aHa′′}.

By applying the orchestration partitioning algorithm to itsprocess, i.e., denoted Lp ⊆ Rp × Ap, we obtain a set ofparticipants P ′ where P ′ = Rp and ∀p′∈P′ | ∃p′′∈PAp′ =Ap��p′′ ∧Rp′ = {p′}. Each obtained participant, i.e., “processpartition” denoted p′, includes only a subset of the tasks thatinvoke (resp., provide) operations on a same service provider,i.e. denoted p′′ (resp., consumer). Those partitions represent

“proxy” orchestrations that are related to each external service.They are fine-grained internal services composing the initialservice (i.e., relative to the initial participant p) and they arematched up with p through participant associations, i.e., E ⊆∪p∈P ×∪p′∈P′ . In this case, we refer to the initial participantas an associated participant. The orchestration partitioningensures a more manageable component architecture and addsa clear architectural view about how fine-grained services arecomposed, that the BPMN per se fails to capture.

In the SCA, the assembly models logically modularize andcompose components in a manner that is decoupled fromtheir code. A component can be a composite (i.e., an assem-bly of components glued together using some “compositionlogic”) or atomic when it is considered without its insidestructure. The components expose their provided ports, i.e.,called services, and require (i.e., or discover) other servicesby means of references. They are configured to interact withthe other components through the connectors, i.e., called wires.Also, the callbacks can be defined for services and referenceswhen the components play per se both the service consumerand provider roles. Finally, each component contains theimplementation with an appropriate technology of the processspecified by the mapped participant’s orchestration. We definethose models to be used for the further formal foundations ofthe model transformation which are given in the next section.

Definition 2 (Target Canonical SCA Assembly Model):A target canonical SCA assembly model, i.e.,assimilated to a composite, is a tuple t =(B,M,N , C,O,Q,K,G,J , I,R,V ,W) where B is aset of sub-composites which can be partitioned to disjointsets of composite services M and composite referencesN , C is a set of components which can be partitioned intodisjoint sets of component services O and componentreferences Q, K is a set of callbacks, G ⊆ (M∪N ) ×K isthe composite callback relation, J ⊆ (O ∪ Q) × K is thecomponent callback relation, I is the of implementations,R ⊆ (M × O) ∪ (N × Q) is the promotion relation,V ⊆ C ×B is the implementation as composite relation, andW ⊆ (M∪Q) × (N ∪O) is the wire relation.

B. The BPMN to SCA Conceptual Mapping

Before we delve into the formal details, a look at thegeneral model transformation problem is needed. Given twometamodels S and T , the model-to-model transformation,denoted transmap : S → T , is a partial function that takesa source model s in S and produces a target model t inT . The source-to-target types correspondences are definedby a partial function, denoted map, which is based on thesemantics of the source core BPMN collaboration and thetarget SCA assembly types. This means that only the sourcemodel objects with types that has proper conceptual mappinginto target types are transformed. For example, only the tasksthat specify service interactions (i.e., send or receive) aretransformed. The other constructs such as gateways and eventsare not relevant for sketching the component assembly, but,

define functional aspects of the component implementation.Moreover, we define an index function as follows: ∀p,p′∈P |∃a∈Ap,a′∈Ap′ , aHa′, index(a) = initialp

′if �a′′∈Ap | a′′ ∈

prev∗(a) and index(a) = finalp′if �a′′∈Ap | a′′ ∈ next∗(a).

This function is used to differentiate the tasks in the ser-vice interaction patterns [9] in the following definition. Thefunctions denoted prev∗(a) = {a′ ∈ Ap | a′F∗

p a} andnext∗(a) = {a′ ∈ Ap | aF∗

p a′} give the set of all directand transitive predecessors and successors of a task a, whereF∗

p is the reflexive transitive closure of Fp. A static analysisof the process flow is considered to distinguish tasks inconversations. We formally define the mapping below.

Definition 3 (Collaboration to Composite Mapping):Let s = (A,R,P ,A�,A�, E ,F , conv,H,L) be awell-formed and well-behaved source core BPMNcollaboration model (i.e., given in Definition 1). s canbe conceptually mapped to onto a target canonicalSCA assembly model, i.e., assimilated to a compositemap(s) = (B,M,N , C,O,Q,K,G,J , I,U ,V ,W) where

• B =⋃

p∈P{p | ∃p′∈P pEp′}, i.e., associated participantto composite,

• M =⋃

p∈P{a ∈ A�p | ∃p′,p′′∈P pEp′ ∧ index(a) =

initialp′′}, i.e., initial receive task to composite service,

• N =⋃

p∈P{a ∈ A�p | ∃p′,p′′∈P pEp′ ∧ index(a) =

initialp′′}, i.e., initial send task to composite reference,

• C = P \⋃

p∈P{p | ∃p′∈P pEp′}, i.e., participant tocomponent,

• O =⋃

p∈P{a ∈ A�p | �p′∈P pEp′ ∧ ∃p′′∈P index(a) =

initialp′′}, i.e., initial receive task to component ser-

vice,• Q =

⋃p∈P{a ∈ A�

p | �p′∈P pEp′ ∧ ∃p′′∈P index(a) =initialp

′′}, i.e., initial send task to component refer-ence,

• K =⋃

p∈P{a ∈ A�p ∪A�

p | ∃p′∈P,a′∈Ap a ∈ next∗(a′)∧index(a′) = initialp

′ ∧ index(a) = finalp′}, i.e., final

receive task or final send task to callback,• G =

⋃p∈P{(a, a′) ∈ A�

p × A�p | ∃p′,p′′∈P pEp′ ∧

a ∈ prev∗(a′) ∧ index(a) = initialp′′ ∧ index(a′) =

finalp′′}, i.e., associated receive task relation to com-

posite callback relation,• J =

⋃p∈P{(a, a′) ∈ A�

p × A�p | �p′∈P pEp′ ∧ ∃p′′∈P

a ∈ prev∗(a′) ∧ index(a) = initialp′′ ∧ index(a′) =

finalp′′}, i.e., associated send task relation to compo-

nent callback relation,• I =

⋃p∈P{p | �p′∈P pEp′ ∧ ∃a∈Ap,r∈Rp rLa}, i.e.,

process to implementation,• U =

⋃p∈P{(a, a′) ∈ (A�

p×A�p′)∪(A�

p×A�p′) | ∃p′,p′′∈P

pEp′ ∧ index(a) = initialp′′ ∧ index(a′) = initialp

′′},i.e., associated task relation to promotion relation,

• V =⋃

p∈P{(p, p′) ∈ P × P | ∃p′∈P pEp′}, i.e., partici-pant association to implementation as composite,

• W =⋃

p∈P{(a, a′) ∈ A�p × A�

p′ | ∃p′∈P index(a) =initialp

′ ∧ index(a′) = initialp ∧ aHa′}, i.e., conver-sation to wire.

Note that we assume the well-formedness of the sourcemodels and its well behavedeness. It means they are consistentwith the structural and the behavioral requirements of serviceinteraction specification, e.g., defined in [9]. For the minimalcorrectness requirements on the structure of the processes wefollow [10], e.g., there is a single start event, there is one ormore end events, and every process task is on a path fromthe start event to an end event. Due to lack of space, werefer to [11] for detailed structural requirements on the SCAmodels. Since the BPNM participants map into SCA compo-nents, then, after the orchestration partitioning, the obtainedparticipant associations between the new participants map intothe implementations as composites. For example, Figure 1shows the mapping of participants resulting from the retailer’sprocess partitioning. The associated participant is mapped toa component. The collaboration obtained after the partitioningmaps into the retailer composite which is attached to theimplementation of the initial retailer component. Recursively,each obtained sub-participant, e.g., order, schedule, invoiceand shipment, is mapped onto a component, and it is placedwithin the implementing composite. The process of each sub-participant maps to a single component implementation. Thisallows different technologies to be used for each processimplementation. It has to be noticed that we do not makerecommendations on the technology usage.

III. BPMN TO SCA MODEL TRANSFORMATION

In the previous section, we have introduced the conceptualmapping for the transformation of canonical SCA assemblymodels from core BPMN collaboration models. This sectionperforms a more through investigation on the implementationof the transformation code. In order to implement the transfor-mation of the model artifacts, we use the ATL transformationchain which is depicted in Figure 2. The ATL is integrated inthe Eclipse development environment and can handle modelsbased on the core Eclipse Modeling Framework (Ecore [6]).It also provides support for models using EMF-based UMLprofiles. In our proof-of-concept prototype, the BPMN andSCA metamodels are created using the Ecore. The BPMNdiagrams and the SCA definitions metamodels are specifiedin the eXtensible Markup Language Metadata Interchange(XMI).

Simplified BPMN Metamodel Simplified SCA Metamodel

Participant SendTask ReceiveTask

FlowElement

Collaboration

Process ComponentReference

Composite

Component

ComponentService*

* *

Ecore

BPMN Metamodel SCA Metamodel

Source Model

SCA XMI FilesBPMN-To-SCA

Target Model Partitionned Model

Orchestration Partitioning

Legend:Conforms ToTransformed In

*

Transformation Chain

BPMN XMI File

Definition*

0..1 *

*

Fig. 2. BPMN-to-SCA transformation ATL chain overview.

Rather than using intermediate model facilities [12], we

advocate a direct transformation chain that starts off froma BPMN XMI file containing the source core BPMN col-laboration model. Then, its orchestrations are partitioned.Subsequently, this model is transformed into a target canonicalSCA assembly model resulting in XML files which contain theService Component Definition Language (SCDL [3]) of themapped composites, i.e., the particular ADL of the SCA. AnATL-code is composed of rules describing how to generate theobjects of the target models. It is compiled into the ATL byte-code and then executed by the ATL virtual machine [ 5]. As asimple running example, consider the following BPMNtoSCAATL program, i.e., the module.

module BPMNtoSCA;create OUT : SCA from IN : BPMN;helper context BPMN!Definitions

def : CollaborationHasParticipants() : Boolean =if (self.getCollaboration().

participants.oclIsUndefined()) then falseelse true endif;

helper context BPMN!Definitionsdef : getDefinitions() : BPMN!Definitions = self;

helper context BPMN!Definitionsdef : getCollaboration() : BPMN!Collaboration =(self.rootElements -> select (e | e.oclIsTypeOf(

BPMN!Collaboration))).asSequence().first();rule CollaborationtoComposite {from d: BPMN!Definitions, s: BPMN!Collaborationto t: SCA!Composite(name <- s.name,

component <- BPMN!Participant.allInstancesFrom(’IN’)-> collect(e | if not e.processRef.oclIsUndefined()

thisModule.ParticipanttoComponent(e,d,e.processRef))}

lazy rule ParticipanttoComponent {from d: BPMN!Definitions, p: BPMN!Participant,

l: BPMN!Processto c: SCA!Component(name <-

if d.CollaborationHasParticipants()=truethen p.name

else d.getCollaboration().name endif,reference <- BPMN!SendTask.allInstancesFrom(’IN’)->select(e | l.flowElements.includes(e))->collect(e | thisModule.SendTaskToReference(e)),service <- BPMN!ReceiveTask.allInstancesFrom(’IN’)-> select(e | l.flowElements.includes(e))->collect(e | thisModule.ReceiveTaskToService(e)))}

lazy rule SendTaskToReference {from sen: BPMN!SendTaskto ref: SCA!ComponentReference(name <- sen.name)}lazy rule ReceiveTaskToService {from rec: BPMN!ReceiveTaskto ser: SCA!ComponentService (name <- rec.name)}

It defines four rules from the conceptual mapping given inDefinition 3. Those rules uses the simplified BPMN and SCAmetamodels shown in Figure 2. The ATL is a hybrid model-to-model transformation language that supports both declar-ative and imperative constructs [13]. The preferred style isdeclarative, which allows simpler implementation for relativelysimple conceptual mappings. However, imperative constructsare provided so that some not trivial mappings to be handleddeclaratively can still be specified. Roughly speaking, theATL program transforms a collaboration to a composite andeach participant of the collaboration to a component of thecorresponding composite. Also, the rules map the send and thereceive task in a straightforward manner to component servicesand references. The order of the rule execution is determinedautomatically, with the exception of lazy rules, which needs tobe called explicitly. The helper functions provide imperativeconstructs.

In order to ensure the consistent BPMN-to-SCA mapping,we partition the service-enabled business process into smallerdecoupled service-components with separate concerns. Theorchestration process partitioning is written with imperativeconstructs (i.e., not presented in the above ATL-code due tolack of space). It provides a better view on the dependenciesbetween the component inside the application being modeled(e.g., order, schedule, invoice and shipment within retailerin Figure 1) and their relationships with the outside of thesystem (e.g., customer, scheduler, invoicer, and a shipper).Also, it makes the overall component architecture more robustand flexible for the later business process or IT evolutions.Eventually, realizing some change in a specific single businessservice contract brings into play only a part of the componentconfiguration architecture. Finally, it becomes possible onlywhen looking at this SCA architecture to localize the con-cerned parts to be changed, without spying on the opaqueapplication code. It is undeniable, however, that the flexibilityto adapt the processes in order to respond to evolving businessneeds is the most relevant trend in the MDE success.

IV. RELATED WORK

In order to align the Business and IT capabilities, various or-ganizational considerations need to be taken into account [ 14],[15]. In this paper, we focus on the Business-IT alignmentthrough the business processes, particularly, on the generationof the software architectures from service-enabled (businessprocess driven) system specifications. Several languages canbe used to specify the service interaction models at differentlevels of abstraction [7]. Using the BPMN 2.0 [2] can pro-vide the sufficient conceptual information needed to specifya complex service-enabled system in a cross-organizationalsetting. Likewise, the SCA [3] provides a framework forcreating software solutions based in a multi-language andmulti-platform environment that are based on complex ITenvironments. As an alternative to the BPMN along with theSCDL, one could use UML Activity Diagrams and SequenceDiagrams, which offer comparable features along with anyother ADL. However, as the UML is neither fully service-centered, nor business process-oriented, it is necessary toprovide alternative methods to design the business processlogic independently of their implementation infrastructure.Thus, the MDE techniques needs to address the gap in existingUML modeling methodologies for the system engineering witha Service Dominant Logic [14], [15].

In [12], the authors present a MDE scenario that uses theEclipse SOA Tools Platform Intermediate Metamodel. Thescenario starts off with a business process specified in theBPMN, leading to an intermediate model and resulting ina SCA model [3]. The approach is promising, however, theabsence of accurate mappings between the two metamodelsmakes the model transformation not viable. First, it requiresfurther manual adaptation to reflect the initial process require-ments because the BPMN per se neither specifies the roles(e.g., consumer or provider) that participants are expectedto play in a business collaboration. Of course, adapting the

generated SCA configurations necessarily leads to their mis-alignment with the business process layer, and implies designdecision losses. Second, the provided automated incrementaltransformation is fictional, since from the initial mapping, thesource constructs are mapped to conceptually different targetelements. Thus, providing consistency management over thisapproach turns out to very challenging endeavor in practice.Furthermore, the change propagation is a major use casefor the MDE. When a source model is changed and that atransformation has previously generated a corresponding targetmodel, it is necessary to keep the models synchronized. Themodel transformation languages [13], specifically the ATL[5], cannot work well here. It supports a mode for in-placetransformation, called the refining mode [5], but it does notsupport incremental model transformations: a complete sourcemodel is read and a complete target model is created. Thus,the manual changes in the target model are not preserved [ 16].Morevover, the Query/View/Transformation (QVT) is a stan-dardized language for model unidirectional transformations.Some of the issues for the QVT usage was raised in [17].The ATL supports only unidirectional transformation code.First, it requires to explicitly write the synchronization codeto deal with each kind of update on each type of assortedmodels. Second, the complexity of each combinatorial changemapping is inherently compounded with decisions regardingthe potential information loss or gain related to different levelsof model’s expressiveness. They make the synchronizationcode much complex, particularly, when not all the sourcemodel elements correspond the to target model elements. Forexample, it is necessary to revise both the SCA definitionsand their implementations, just to make a minor change onthe service interaction patterns [9] at the BPMN level.

V. SUMMARY AND OUTLOOK

In this paper, we have presented a development scenariosfor the SOC, where business process specifications drivecomponent architectures that are organized in a SOA. At thedesign-time, the business analyst focus on the modeling oftask-driven and service-oriented logics without being botheredby any implementation-specific configuration information. Theintroduced conceptual mapping rules enable the transformationof BPMN collaboration models into canonical SCA assemblymodels. The later models describe and guide the final systemdeployment architecture and its implementation. Thus, thereuse of some existing software applications as well as creatingnew ones to be reused in other system parts become moreevident for the architects. At the execution-time, the assemblymodels are instantiated for the SCA runtime environments andbenefit from those frameworks for deployment and monitoring.Since there is no mean of control flows between the SCAcomponents, then, it seems that some BPMN behavioralaspects have no counterparts in the SCA. However, othersemantics can be defined in the SCA components. Therefore,we want to enlarge our approach by transforming other BPMNconstructs to non-standard SCA elements for example for theimplementation of non-functional requirements.

The experimental results for the BPMN-to-SCA transfor-mation with the ATL are encouraging, and the MDE approachseems very promising, however, it still needs to be validatedin a real-scale case studies. The integration of our ATL chainin the Eclipse SOA Tools Platform [18] is in development.Furthermore, the (full) round-tripping between the businessprocesses and the SOA is essential to rapidly realign theIT to accommodate changing business conditions. Conse-quently, striving for further alignment via service pattern-basedtechniques, and making SOA development more tractableto reconfigure architectures without disrupting the functionalcapabilities of the implementations remain as a future work.

REFERENCES

[1] M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann, “Service-oriented computing: State of the art and research challenges,” Computer,vol. 40, no. 11, pp. 38–45, 2007.

[2] Business Process Model and Notation 2.0, Beta 1, OMG, May 2009.[3] SCA Assembly Model Specification 1.1, Open SOA, Mar. 2009.[4] K. Dahman, F. Charoy, and C. Godart, “Generation of Component Based

Architecture from Business Processes: Model Driven Engineering forSOA,” in ECOWS 2010 - The 8th IEEE European Conference on WebServices, Ayia Napa, Greece, 12 2010.

[5] F. Jouault and M. Tisi, “Towards incremental execution of atl trans-formations,” in Proceedings of the Third international conference onTheory and practice of model transformations, ser. ICMT’10. Berlin,Heidelberg: Springer-Verlag, 2010, pp. 123–137.

[6] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks, EMF: EclipseModeling Framework 2.0. Addison-Wesley Professional, 2009.

[7] M. Dumas and T. Kohlborn, “Service-enabled process management,” inHandbook on Business Process Management 1, ser. International Hand-books on Information Systems, P. Bernus, J. Blazewics, G. Schmidt,M. Shaw, J. v. Brocke, and M. Rosemann, Eds. Springer BerlinHeidelberg, 2010, pp. 441–460.

[8] M. Rosen, B. Lublinsky, K. T. Smith, and M. J. Balcer, Applied SOA:Service-Oriented Architecture and Design Strategies. Wiley P., 2008.

[9] W. van der Aalst, A. Mooij, C. Stahl, and K. Wolf, “Service Inter-action: Patterns, Formalization, and Analysis,” in Formal Methods forWeb Services, ser. Lecture Notes in Computer Science, M. Bernardo,L. Padovani, and G. Zavattaro, Eds. Berlin, Heidelberg: Springer Berlin/ Heidelberg, 2009, vol. 5569, ch. 2, pp. 42–88.

[10] R. M. Dijkman, M. Dumas, and C. Ouyang, “Semantics and analysis ofbusiness process models in bpmn,” Information and Software Technol-ogy, vol. 50, no. 12, pp. 1281 – 1294, 2008.

[11] M. Leger, T. Ledoux, and T. Coupaye, “Reliable Dynamic Reconfigura-tions in a Reflective Component Model,” in Component-Based SoftwareEngineering, ser. Lecture Notes in Computer Science, L. Grunske,R. Reussner, and F. Plasil, Eds. Berlin, Heidelberg: Springer Berlin /Heidelberg, 2010, vol. 6092, ch. 5, pp. 74–92.

[12] A. Mos, A. Boulze, S. Quaireau, and C. Meynier, “Multi-layer perspec-tives and spaces in soa,” in SDSOA ’08, New York, USA, 2008, pp.69–74.

[13] M. Biehl, “Literature Study on Model Transformations,” Royal Instituteof Technology, Tech. Rep. ISRN/KTH/MMK/R-10/07-SE, Jul. 2010.

[14] H.-M. Chen, R. Kazman, and O. Perry, “From software architectureanalysis to service engineering: An empirical study of methodologydevelopment for enterprise soa implementation,” IEEE Trans. Serv.Comput., vol. 3, pp. 145–160, April 2010.

[15] K. Levi and A. Arsanjani, “A goal-driven approach to enterprise com-ponent identification and specification,” Commun. ACM, vol. 45, no. 10,pp. 45–52, 2002.

[16] Y. Xiong, D. Liu, Z. Hu, H. Zhao, M. Takeichi, and H. Mei, “Towardsautomatic model synchronization from model transformations,” in Pro-ceedings of the twenty-second IEEE/ACM international conference onAutomated software engineering, ser. ASE ’07. New York, NY, USA:ACM, 2007, pp. 164–173.

[17] P. Stevens, “Bidirectional model transformations in qvt: Semantic issuesand open questions,” in MoDELS, 2007, pp. 1–15.

[18] “Eclipse soa tools platform project,” (accessed 29 March 2011).[Online]. Available: http://www.eclipse.org/stp/