Model-Driven Development Methodology for B2B Collaborations

Ivanna M. Lazarte∗, Edgar Tello-Leal∗†, Jorge Roa∗, Omar Chiotti∗‡ and Pablo D. Villarreal∗‡∗CIDISI, Universidad Tecnologica Nacional-FRSF

Lavaise 610, S3004EWB, Santa Fe, Argentina{ilazarte, jroa, pvillarr}@frsf.utn.edu.ar

†Universidad Autonoma de Tamaulipas, Cd. Victoria, Tamaulipas, Mexicoetello@uat.edu.mx

‡INGAR-CONICET, Avellaneda 3657, S3002GJC, Santa Fe, Argentinachiotti@santafe-conicet.gov.ar

Abstract—The design and implementation of collaborativebusiness processes and the Business-to-Business (B2B) systemsthat support them is an important issue in order to enable en-terprises to set up B2B collaborations. This involves new chal-lenges, mainly regarding the ability to cope with change, decen-tralized management, peer-to-peer interactions, preservationof enterprise autonomy, and the support for interoperability.The design and implementation of B2B collaborations requirethe use of conceptual models that differ in viewpoint, targetpeople, abstraction level and granularity. This makes the use oftraditional software development methodologies inappropriate.In this paper, we propose a methodology for the design andimplementation of B2B collaborations that support the aboveissues. The methodology supports a development frameworkand is based on the Model-Driven Development (MDD). Themethodology provides guidelines, languages, methods, modeltransformations and tools to support the representation ofbusiness requirements, the definition of technology-independentcollaborative process models, the derivation of technology-independent processes and IT architectures that enterprisesrequire to support collaborative processes as well as thegeneration of a technology-specific solution for each enterprise.This methodology guarantees the alignment and consistencybetween the business and technological solutions for B2Bcollaborations.

Keywords-Collaborative Business Process; Business-to-Business; Model-Driven Development

I. INTRODUCTION

In the current global markets, enterprises are applyingcollaborative business models to manage collaboration withtheir business partners with the aim of improving their per-formance and competitiveness. Collaborative models can berealized by implementing Business-to-Business (B2B) col-laborations. This implementation entails a process-orientedintegration among heterogeneous and autonomous enter-prises which must be achieved at a business level and ata technological level [1].

At the business level, enterprises focus on the design ofcollaborative business processes to agree on the behavior ofthe collaboration. A collaborative business process (CBP)defines the global view of the interactions among enterprisesto achieve common business goals [1], [2], [3]. Also, enter-

prises have to design the integration of the CBPs with theirprivate processes that support them.

At the technological level, enterprises focus on the func-tionality and interoperability of their B2B information sys-tems to execute CBPs. This implies the generation of B2Bspecifications (i.e. specifications of system interfaces andbusiness processes based on a B2B standard) required byeach enterprise to execute the role performed in CBPs andimplement them in a business process management system(BPMS) [1].

The design and implementation of B2B collaborations in-volves the fulfillment of particular [1], [2], [3]: the ability tocope with change, decentralized management of CBPs, peer-to-peer interactions, preservation of enterprises’ autonomy,representation of complex negotiations, the required supportfor interoperability, and the alignment between the solutionsat the business and technological levels to guarantee thatthe technological solution provides a full support to CBPs.Furthermore, the design of business processes and systemsinvolved in a B2B collaboration requires models which differin the viewpoint they are described, the phase of modelingin which they are used, the target people dealing with themodel, or merely the level of abstraction and the granularityof the models. Although some methodologies for B2B whereproposed [2], [4], [5], [6], [7], they do not fulfill all theaforementioned requirements.

In this work we propose a methodology for the designand implementation of B2B collaborations that supportsthe above issues. The proposed methodology provides tech-niques, languages and methods that exploit the benefits ofthe Model-Driven Development (MDD) [8]. MDD is basedon the use of models in the software construction to simulate,estimate, understand, communicate, and produce code [9].An MDD approach allows a better way of addressingand solving the problems of interoperability, heterogeneity,enterprises autonomy and alignment between the businessand technological solutions involved in a B2B collaboration.By applying guidelines based on the MDD, it is also possibleto separate concerns through different abstraction levels ofthe development of B2B collaborations.

2010 14th IEEE International Enterprise Distributed Object Computing Conference Workshops

978-0-7695-4164-8/10 $26.00 © 2010 IEEE

DOI 10.1109/EDOCW.2010.21

69

2010 14th IEEE International Enterprise Distributed Object Computing Conference Workshops

978-0-7695-4164-8/10 $26.00 © 2010 IEEE

DOI 10.1109/EDOCW.2010.21

69

This paper is organized as follows: section II presentsa conceptual framework for the development of B2B col-laborations. Section III presents the proposed model-drivendevelopment methodology for B2B collaborations. SectionIV presents the model transformations required to developa B2B collaboration. Section V presents an Eclipse-basedIDE for supporting the proposed methodology. Section VIshows the application of the methodology in a case study.Section VII includes related work and, finally, section VIIIpresents conclusions and future work.

II. FRAMEWORK FOR THE DEVELOPMENT OF B2BCOLLABORATIONS

In order to support the development of a B2B collabo-ration and provide a clearer representation of developmentartifacts, the separation of concerns and the different ab-straction levels, we apply a conceptual framework (see Fig.1) based on the separation of domains in the model-drivendevelopment proposed in [10]. The framework consists inthe definition of: business requirements, a business solution,an IT architecture solution, and a technological solution.These definitions are identified into one of the three domainsrequired for the development of a B2B collaboration.

The problem domain refers to the identification of thebusiness requirements of a B2B collaboration, which derivefrom the collaborative business model that partners agreeto carry out. Such requirements refer to the common goalsto be achieved, the partners involved in the collaborationand the roles partners fulfill, as well as the identification ofthe collaborative business processes to be carried out. Thisdomain does not include details of the design of any solution.

The solution domain refers to how to meet the businessrequirements identified in the problem domain. The solutionsof this domain have to be platform-independent by usingrepresentations of high-level abstraction to capture the do-main’s key concepts. In this way, the generated solution canbe reused to implement it with different technologies. Thesolution domain implies the definition of a business solutionand an IT architecture solution to separate the concernsrelated to the business logic of CBPs from those relatedto the design of the information systems involved in thetechnological solution.

• The business solution consists in defining how partnerswill manage the B2B collaboration. This implies thedefinition of the explicit behavior of CBPs from abusiness viewpoint, which describes the global view ofthe interactions between partners. The business solutionalso implies the definition of the business processes thateach partner has to make in order to support CBPs. Thissolution is defined by business analysts using conceptscloser to the problem domain.

• The IT architecture solution consists in defining thesystems’ architecture that each partner has to im-plement in order to support the business processes

Figure 1. Framework for the development of B2B collaborations

defined in the business solution. This is achieved byapplying a system architecture paradigm to define thesoftware architecture of the systems that each partnerhas to implement. The design of the IT architectureis accomplished at a platform-independent abstractionlevel. IT designers define the IT architecture solutionby using concepts closer to the implementation domain,abstracting technical details. This solution is suitablefor facilitating the transition from the business solutionto the technological solution.

The implementation domain refers to the implementationof the technological solution, which consists of the spec-ifications of business processes and system interfaces byusing B2B standards or technologies, in such a way that thepartners’ systems can interoperate and support the executionof CBPs. The technological solution is implemented byIT developers using platform-specific concepts to generateexecutable code of the B2B specifications.

By applying this framework, business analysts, IT de-signers and IT developers can identify the relevant artifactsrequired in the development of a B2B collaboration, andfocus on the concerns in which they are experts.

III. MODEL-DRIVEN DEVELOPMENT METHODOLOGYFOR B2B COLLABORATIONS

In this section we propose a methodology for the de-sign and implementation of B2B collaborations, which isbased on the framework mentioned above. This methodologyprovides an architecture and a process based on the MDDin order to address the problems of interoperability, het-erogeneity, enterprise autonomy, and business-technologicalalignment of B2B collaborations; and to support the sepa-ration of concerns between the domains of the conceptualframework. The development artifacts of this methodologyare represented by means of models and generated byapplying the principles of the MDD. The focus of effort is onthe models at higher levels of abstraction, which define thebusiness and the system solution, to those at lower levels[11], which define the technological solution. Thus, themethodology uses models of business processes and systemsto construct software artifacts of the technological solutionof a B2B collaboration. The generated software artifactsare the B2B specifications corresponding to the businessprocesses and the B2B system’s interfaces of the partners.

The proposed methodology applies a top-down approachand consists of four phases (see Fig. 2): Business Analysis,Design of the Business Solution, Design of the IT Architec-ture Solution, and Design of the Technological Solution. In

7070

Figure 2. Phases of the proposed model-driven development methodology

the next subsections, we describe the phases, models andlanguages involved in the methodology.

An important issue to consider in a methodology forB2B collaborations is the design of collaborative businessprocesses. This requires a suitable modeling language thatmeets the features of the B2B collaboration domain and theglobal view of the interaction between partners. Currently,there is a lack of standardized modeling languages andmethods for CBPs supporting these features. A modelinglanguage that was proposed to fulfill these features is theUML Profile for Collaborative Business Processes based onInteraction Protocols (UPColBPIP) [1], [12]. In this work,we propose the use of this language to define the businessrequirements as well as the CBPs.

A. Business Analysis

This phase consists in analyzing the problem domainand identifying the business requirements. This is jointlycarried out by the enterprises. To define the business require-ment model, the UPColBPIP language can be used sinceit supports the modeling of the business context of CBPs.UPColBPIP enables the definition of the B2B Collabora-tion View and the Collaborative Process View of a B2Bcollaboration model. The former captures the participants(partners and the roles they fulfill) and their communica-tion relationships. This view also defines the collaborativeagreement parameters and the hierarchy of common businessgoals to be fulfilled by partners. The latter identifies theCBPs required to achieve common business goals. Thus, theoutput of this phase is the business requirement model whichis represented by both views. This model helps businessanalysts to understand the problem and to identify the CBPsto be designed in the next phase.

B. Design of the Business Solution

This phase focuses on the design of the business processesrequired to carry out a B2B collaboration. People involvedin this phase are business analysts and system designerswho are responsible for defining the business aspects ofthe B2B collaboration. The main focus is on the definitionof the CBPs, which describe the common behavior of theinteractions between partners from a global viewpoint [1],[2], [13]. However, the development of a B2B collaborationrequires not only the definition of the common public be-havior between the partners, but also the business processesthat each partner has to implement in order to fulfill therole it performs in CBPs. Thus, it is necessary to define theinterface and integration business processes of each partner,which describe the behavior of the role the partner performsin CBPs. An interface process, also called abstract process[14], [15] or behavioral interface [13], defines the publicand externally visible behavior of a partner in terms of theactivities that support the receiving and sending of messageswith each other. The public behavior can be derived fromthe CBPs. Finally, from the interface processes, partnersdefine their integration processes, also called private [14],executable [2], [15] or orchestration processes [13]. Anintegration process adds the internal business logic requiredto support the role a partner performs in a CBP. Theinternal business logic includes the activities for producingand processing the exchanged information as well as datatransformations and invocations to internal systems. Allthese business processes should be defined in a platform-independent way, and they differ in their viewpoint and thedetail level in which they are expressed. They all composethe integral business solution of a B2B collaboration.

In this way, the design of the business solution phaseis realized in three tasks: Design of the CBPs, Generationof the Interface Processes, and Design of the IntegrationProcesses (see Fig. 2). The second and third tasks are carriedout separately for each enterprise. They are described below.

1) Design of the CBPs: at this task, the business analystsand system designers of the enterprises work jointly inorder to model the CBPs from a business perspectiveby using the UPColBPIP language [1], [12]. Oneof the main contributions of this language is theuse of interaction protocols to model the behaviorof CBPs. An interaction protocol describes a high-level communication pattern through a choreographyof business messages between partners [12]. Thus,the language supports the definition of the Interac-tion Protocol View of a B2B collaboration model,which contains an interaction protocol for each CBP.The UPColBPIP language extends the semantics ofthe UML2 interactions to model interaction protocolsthrough sequence diagrams, which provides a moreexpressive concrete syntaxis to visualize protocols.

7171

In addition, as a complement to the definition of thebehavior of CBPs, the language supports the definitionof other two views. The Business Document View de-scribes business documents to be exchanged in CBPs.Business documents and their types are representedin class diagrams, and they are referenced in interac-tion protocols. To define the syntactic and semanticsstructure of business documents and guarantee thedata interoperability, other suitable languages can beused, such as the approach proposed in [16]. TheBusiness Interface View describes the interfaces ofeach role performed by partners, which are representedin UML2 composite structure diagrams. A businessinterface (service) contains business operations thatsupport the asynchronous message exchange by inter-action protocols.Since CBP models describe inter-enterprise collabora-tion, it is essential to enable partners to make sure thebehavior of CBPs is well-defined. This requires theuse of verification and validation (V&V) techniques.Hence, we propose that V&V of CBP models shouldbe carried out at an early stage in the development,when most of the fundamental decisions of a B2B col-laboration are realized, i.e. previous to the generationof the IT architecture solution. To support this, formaltechniques have to be applied, such as the methodproposed in [17], which uses Petri Nets to carry outthe V&V of interaction protocols.The output of this task are the verified and validatedCBP models.

2) Generation of the Interface Processes: at this task,business analysts and system designers of each en-terprise separately generate the enterprise’s interfaceprocesses, which describes the public and externallyvisible behavior of the role the enterprise performsin the defined CBPs. This public behavior can bederived from the CBPs. To support this, we proposethe use of a method [18], which is based on theMDA (Model-Driven Architecture) [19] and supportsthe automatic generation of the enterprise’s interfaceprocess model from a CBP model defined with theUPColBPIP language. Interface Process Models arerepresented by the BPMN [14] language. This methodenables enterprises to generate interoperable interfaceprocesses in compliance with the global logic of B2Binteractions agreed on CBPs. The output of this taskare the interface process models of each enterprise.

3) Design of the Integration Processes: this task consists,for each partner, in defining the private view of therole the partner performs in the CBP. To do that,the interface process model of an enterprise servesas a skeleton to design its corresponding integrationprocess. Internal activities, which are required forgenerating the information to be sent and processing

the information to be received from partners, haveto be added to the interface process model to definethe corresponding integration process. To support thisdesign, we propose the use of new predefined activitypatterns [20], which capture recurrent business func-tions to process or generate the information exchangedbetween partners.A verification approach for businessprocesses/workflows should be applied to detecterrors in the integration process models, such asdeadlocks, livelocks, etc. However, the addition ofinternal activities in these process models may alsointroduce errors leading to inconsistencies amongthe interface process models of the partners, i.e.interface process models that are not in accordancewith the common and public logic agreed among thepartners. Hence, other type of verification approachis necessary to detect these inconsistences andguarantees that integration processes satisfy thebehavior of the global view of interactions betweenparticipants. The output of the V&V task are theverified and validated integration process models,which are defined by using the BPMN language.

C. Design of the IT Architecture Solution

This phase is also separately realized by each enterprisein order to define an IT architecture model (see Fig. 2)at a platform-independent level to decouple the IT logicalsolution from its technical implementation, enabling such animplementation to be produced on different platforms. TheIT architecture model is derived from the integration processmodels defined in the previous phase, and it is designedby IT designers for representing the part of the solutionthat will remain unchanged on any platform, considering thesoftware architecture paradigm that the enterprises agree touse for defining their IT architecture model. A Service Ori-ented Architecture (SOA) or a Multi-Agent System (MAS)architecture are good candidates to be used for definingan IT architecture model within a conceptual viewpoint.There are several UML profiles for SOA that can be usedfor modeling the SOA-based IT architecture solution, suchas the UML4SOA proposed in [21]. The IT architecturemodel of an enterprise mainly defines the system interfacesfrom the enterprise’s viewpoint. This model is useful tofacilitate the communication between business analysts andIT designers, and allows a more simple transition from abusiness solution into a technological solution.

D. Design of the Technological Solution

In this phase each enterprise defines the technologicalsolution to support the decentralized execution of CBPsby enacting the B2B specifications through the enterprise’sBPMS. This solution is defined by IT developers usingplatform-specific concepts in order to convert such solution

7272

into a particular executable code. Although this phase iscarried out in parallel for enterprises, they have to agreeon the B2B standards and technologies to be used forimplementing the B2B specifications.

This phase is carried out in two tasks: Design of theplatform-specific IT Solution and Generation of B2B speci-fications (see Fig. 2). These tasks are described below.

1) Design of the platform-specific IT Solution: it consistsin the definition of the models of B2B specificationsbased on a B2B standard or technology. To do that,metamodels of the selected B2B standard or tech-nology should be provided. The platform-specific ITmodel must contain the necessary platform-specificinformation (e.g. concrete message formats sent orreceived by partners, the transport protocols used, etc.)in order to put the IT architecture model in operation.The platform-specific IT model generated in this taskis dependent on the software architecture used fordefining the IT architecture model. For example, ifit is based on SOA, then BPEL and WSDL can beused for defining the platform-specific IT solution.

2) Generation of B2B specifications: it consists in thegeneration of the XML-based specifications of busi-ness processes and the B2B systems’ interfaces ofan enterprise from its platform-specific IT model,which contains the necessary information for the codegeneration. The code of the software artifacts corre-sponding to the applications that implement the B2Bsystems’ interfaces is not generated in the proposedmethodology.

IV. MODEL TRANSFORMATIONS

As we have described in the previous section, the modelsof the development domains of a B2B collaboration evolvethrough the phases and define the collaboration from differ-ent viewpoints, abstraction levels, etc. To allow models toevolve in a consistent way while maintaining the alignmentamong them, and to reduce the development costs and time,the methodology provides automatic and semi-automaticmodel transformations to generate the output models of eachphase.

Defining and applying model transformations are criticaltechniques within any model-driven style of development[11]. A model transformation consists of a set of transfor-mation rules that defines how an input model is mapped intoone or more models or into an executable code. To supportthe required model transformations for the methodology,we propose the application of different methods of modeltransformations. The models are classified according tothe MDA, which proposes model transformations at differ-ent abstraction levels: defining platform-independent mod-els (PIMs) from a computation-independent model (CIM),selecting platform-specific models (PSMs) and executingtransformations that generate PSMs from PIMs, and finally

Figure 3. Model Transformations required for the methodology

generating codes by executing transformations of PSMsinto Code. The proposed model transformation methods tobe applied in the development of a B2B collaboration areexplained below (see Fig. 3).

A. From a Business Requirement Model to CBP Models

To obtain CBP models, two model transformation methodsare applied. The first one takes as input the business require-ment model, which is at the CIM level and is obtained in thebusiness analysis phase by using the UPColBPIP language.From this model, an automatic model transformation isapplied, which generates as output the skeletons of theUPColBPIP CBP models to be defined in the design ofCBPs task from the design of the business solution phase(see T1 in Fig. 3). Then, these models are completed bymodeling the interaction protocols that describe the CBPs.After this, to obtain the verified and validated CBP models,the MDA-based approach for generating Petri Net specifica-tions from CBP models is applied [17]. Interaction protocolsare formalized, transformed, and mapped into Colored PetriNet (CPN) specifications, which can then be verified andvalidated with CPN tools whose results are used to correctthe process models (see T2 in Fig. 3). This way, the resultingverified and validated CBP models, which are then redefinedwith the UPColBPIP language, are at the PIM level.

B. From a CBP Model to an Interface Process Model

To enable each enterprise to generate its interface processmodels from the CBP models agreed between the partners,we propose the application of the MDA-based methoddescribed in [18] (see T3 in Fig. 3). This method takes asinput CBP models defined with the UPColBPIP language,which are represented as interaction protocols. For a selectedinteraction protocol, the method applies an automatic modeltransformation that generates as output BPMN Business

7373

Process Diagrams (BPD) [14] representing the partners’interface processes, i.e. a BPD for each partner involvedin the protocol. The transformation process is based on theapplication of a set of predefined BPMN patterns for eachconceptual element of an interaction protocol. Thus, thesemantics of each protocol element is represented in terms ofthe elements and semantics provided by the BPMN languagefrom one partner’s viewpoint, which is required to representinterface processes. This MDA-based method supports theexecution of the generation of interface processes task fromthe design of the business solution phase. The obtainedinterface process models based on the BPMN language areat the PIM level.

C. From an Interface Process Model to an IntegrationProcess Model

To obtain the integration process models, each enterprisecan independently apply a model transformation methodto allow a semi-automatic design of these models (seeT4 in Fig. 3). An automatic procedure cannot be appliedbecause the addition of private activities and logic conveysthe application of business analysts’ implicit knowledgeor private enterprise information, which are difficult toincorporate in a model transformation process. However,in order to provide a support to the design of integrationprocesses task, a refactoring transformation method [22]based on predefined activity patterns [20] is applied totransform a BPMN interface process model into a BPMNintegration process model. As defined in [20], an activitypattern captures a recurrent business function. Hence, inorder to design integration processes, we propose the use ofa set of predefined BPMN activity patterns for each event oractivity found in an interface process model to represent theprivate activities required for processing or generating theinformation exchanged between partners. To obtain verifiedand validated integration process models (see T5 in Fig.3), model transformation approaches could be applied tocarry out the V&V of these models in a similar way as it isproposed for CBP models (see Section IV-A). The resultingintegration process models are at the PIM level.

D. From an Integration Process Model to an IT ArchitectureModel

To enable each enterprise to obtain its IT architecturemodel at the PIM level, an automatic model transformationmethod is applied by IT designers, which takes as input theintegration process models (see T6 in Fig. 3). The methodgenerates an IT architecture model, which supports theintegration processes, according to the software architectureparadigm enterprises agreed, so as to provide the necessaryinformation required for transforming such model into thecorrect PSM that represents the technological solution. Twocurrent architecture paradigm can be used for B2B systems:Service Oriented Architecture (SOA) or Multi-Agent System

(MAS). Thus, MDD-based methods for generating SOA [23]or MAS [24] from integration process models have to beapplied to support the design of the IT architecture solutionphase.

E. From an IT Architecture Model to a Platform-specific ITModel

To enable each enterprise to obtain its platform-specific ITmodel at the PSM level, an automatic model transformationmethod is applied by IT developers, which takes as inputthe IT architecture model (see T7 in Fig. 3). The methodis based on the target platform agreed among enterprises.The IT developers choose the platform that enables theimplementation of the B2B collaboration with the selectedarchitectural style. For instance, if the IT architecture isbased on SOA, the target platform can be based on theBPEL [15] and WSDL [25] standards. Instead, if the ITarchitecture is based on MAS, the JADE [26] platformcan be used. Metamodels of the target platforms shouldbe provided to carry out the required model transformationprocess, as proposed in [4].

F. From a Platform-specific IT Models to B2B specifications

To obtain the final software artifacts, i.e. the code of theB2B specifications corresponding to the partners’ integra-tion business processes and system interfaces, a model-to-code transformation process is applied (see T8 in Fig. 3).The code to be generated depends on the target platformpreviously selected. The generation of the XML-based codeis required if the target platform is based on SOA and theBPEL and WSDL standards. In this case, the transformationof PSM, based on BPEL and WSDL, into the correspondingXML-based code is almost direct. This can be supportedby XML production rules that convert a UML class modelinto an XML version, as proposed in [4]. In contrast, thegeneration of Java and XML-based code is required if thetarget platform is a Java platform for MAS such as JADE.

V. ECLIPSE-BASED IDE TO SUPPORT THEDEVELOPMENT OF B2B COLLABORATIONS

In previous work [27], an Integrated Development Envi-ronment (IDE) for the modeling and verification of CBPswas proposed. This IDE is based on the Eclipse opendevelopment platform [28], and supports the UPColBPIPlanguage and the model transformations that are necessaryto carry out the verification of CBPs. The implementationof this IDE is based on the Graphical Modeling Framework(GMF) [28], which provides an infrastructure for developingvisual editors based on the Eclipse Modeling Framework(EMF) [28].

In this work, we make use of the architecture of this IDEas the basis for providing an extended IDE that supports theproposed model-driven development methodology for B2Bcollaborations. By providing an Eclipse-based IDE, we take

7474

Figure 4. Architecture of the Eclipse-based IDE - Part 1

Figure 5. Architecture of the Eclipse-based IDE - Part 2

advantage of a well-known development environment andthe Eclipse platform extension mechanisms that enable thecreation of editors and model transformation machines aswell as the reuse and integration of existing tools.

The extended Eclipse-based IDE we are proposing to sup-port the design and implementation of B2B collaborationsconsists of the following components:

• A set of Eclipse-based plug-ins (see Fig. 4, 5), whichare graphical editors that support the definition of thediagrams of the modeling languages that are used inthe methodology. Some plug-ins support the definitionof UPColBPIP models (one plug-in for each view ofthis language). The Eclipse-based plug-ins for BPMN,BPEL and WSDL, which are provided by the Eclipsecommunity, are added to this IDE. New editors can alsobe added to support the building of SOA models, MASmodels and JADE models.

• A set of Eclipse-based plug-ins which are transfor-mation machines that support the proposed model-to-model and model-to-code transformations (see Fig.6) required in the methodology. They are based ondifferent Eclipse tools [28] that support the buildingof model transformation machines such as ATL, QVT,VIATRA, JET2.

By using the Eclipse platform it is possible to guaran-tee the interoperability of the different plug-ins, tools andtransformation machines, since the metamodels of the usedlanguages are implemented in the same platform as EMFmodels. In addition, the Eclipse platform enables us to pro-vide an integrated tool that supports the entire developmentprocess of the model-driven development methodology forB2B collaborations.

Figure 6. Architecture of the Eclipse-based IDE - Part 3

Figure 7. B2B Collaboration View

VI. CASE STUDY EXAMPLE

In this section we show the application of the method-ology to a case study from the Supply Chain IntegratedManagement domain. The collaboration is based on thescenario D of the CPFR business model [29] by two manu-facturing enterprises of the electronics industry. The purposeof this collaboration is to make manufacturers improve theirbenefits and reduce costs through a better coordination ofthe activities involved in managing the supply chain betweenthem.

Figure 7 and 8 show diagrams of the B2B Collabora-tion View and the Collaborative Process View respectively,which were defined with the UPColBPIP language. Theformer describes the participants, i.e. the manufacturer Awho performs the supplier role and the manufacturer Bwho performs the customer role; both related through aB2B relationship link and the corresponding interfaces. Acommon business goal diagram was also defined, whichdescribes the metrics and targets of the goals, although it isnot shown because of space restrictions. There is a main goaland four subgoals: accurate demand forecasting, reliableorder schedule, reliable deliveries, and order fulfillment. Thelatter diagram defines the five CBPs to be performed in thecollaboration, their relationships, the partners involved, andthe business goals each partner has to achieve.

The behavior of CBPs was defined with the UPColBPIPlanguage. Due to space limitations, we cannot show allthe diagrams with the different views of a UPColBPIPmodel. As an example of an interaction protocol, Figure 9shows the sequence diagram of the protocol that representsthe Collaborative Demand Forecast process. This protocolsupports a negotiation process between a customer anda supplier to agree on a demand forecast. The processbegins with the customer, who requests demand forecast.The request message conveys the data to be considered inthe forecasting (e.g.: products, time-frame). The supplier

7575

Figure 8. Collaborative Process View

Figure 9. Interaction Protocol View

processes the request and may respond by accepting orrejecting it, as it is indicated by the Xor control flowsegment. If it is accepted, the supplier undertakes to realizethe required forecast; otherwise, the process finishes witha business failure. If the supplier accepts the request, thecustomer informs, in parallel, a sales forecast of its points ofsales (POS) and its planned sale policies, as it is indicated bythe And control flow segment. Finally, with this information,the supplier generates a demand forecast and sends it to thecustomer. Then, the process ends.

The interface process models are automatically gener-ated from the defined interaction protocols, by applyingthe MDA-based method described in section IV-B. As anexample, the generated BPMN Business Process Diagramrepresenting the supplier’s interface process model is shownin Figure 10.

The integration process models are generated with theaddition of the required private activities to the interface pro-cess models by applying the activity pattern-based approachaforementioned. As an example, the BPMN Business Pro-cess Diagram representing the supplier’s integration processmodel is shown in Figure 11.

In order to define the IT architecture model of eachenterprise based on SOA, we have applied the UML4SOAprofile [21]. Figure 12 shows the composed Web service

Figure 10. BPMN Business Process Diagram of the Supplier’s interfaceprocess

Figure 11. BPMN Business Process Diagram of the Supplier’s integrationprocess

Figure 12. IT Architecture Model based on SOA for the Supplier

derived from the supplier’ integration process. This describesthe orchestration of the supplier and the customer’s Webservices from the supplier’s viewpoint, as well as the Webservices of the supplier’s internal systems.

The chosen target platforms to implement the collabo-

7676

Figure 13. BPEL code fragment for platform-specific IT solution

ration are the BPEL and WSDL standards. The platform-specific IT models of each enterprise, which are basedon these standards, are generated from the correspondingUML4SOA models. Afterwards, from the PSM, the XMLdocuments containing the BPEL and WSDL code are gen-erated. As an example, Figure 13 shows a fragment ofthe generated BPEL code that is part of the supplier’stechnological solution.

VII. RELATED WORK

In our previous work, we proposed MDA-based methodsto generate technological solutions based on Web servicecompositions [4] and the ebXML standard [1], which aredirectly derived from CBP models defined with the UP-ColBPIP language. The definition of the required privatelogic of the partners can only be added at a technologicallevel. However, in this work we provide a methodology thatcovers all the development phases for B2B collaborationsand elevates the abstraction level in the definition of theinterface and integration processes as well as in the definitionof the IT architecture of each enterprise.

A method for modeling cross-enterprise (collaborative)business processes based on MDA was proposed in [2],which supports the mapping of ARIS models of cross-enterprise value chains into BPDM models of abstract(interface) processes. The proposed IT architecture uses acentralized broker to implement and govern B2B interac-tions. This is different from our approach that encouragesa decentralized management of CBPs, in which enterprisesimplement B2B specifications of business processes andsystem interfaces, which are executed by their BPMSs basedon Web services or software agent technologies.

There are different MDD-based approaches for the de-sign and implementation of cross-enterprise (collaborative)business processes, in which the technological solution isbased on the SOA paradigm such as those proposed in [5],[6]. In this work, we propose a model-driven developmentmethodology which enables the implementation of CBPswith different system architecture paradigms and platforms.

The UN/CEFACT modeling methodology (UMM) formodeling global choreographies of B2B scenarios is pro-posed in [7]. It is a top-down approach that encourages

the definition of a global choreography of a collaborativeprocess in a hierarchy of views, which makes it difficultunderstand the choreography along with the interactionsbetween partners in a high abstraction level. In addition,it is not based on a model-driven approach.

VIII. CONCLUSIONS AND FUTURE WORK

In this work we have proposed a model-driven devel-opment methodology for the design and implementationof B2B collaborations. The methodology is based on aconceptual development, encourages a top-down approach,and provides a clear separation of the domains and theabstraction levels of the artifacts required in the develop-ment of B2B collaborations. Thus, the methodology enablesenterprises to: (1) identify the business requirements, (2)define the business solution necessary for satisfying these re-quirements, i.e. the CBPs and the private business processesof each enterprise, (3) define the IT architecture of eachenterprise for implementing the business solution, and (4)define the technological solution that implements the B2Bcollaboration.

The proposed model-driven development methodologyincreases the abstraction level in the design of B2B col-laborations since the main development artifacts are thetechnology-independent business processes and IT architec-ture models. Also, it reduces the development time andcosts, because the technological solution required by eachenterprise is automatically generated from the conceptualmodels defined at the solution domain. By applying modeltransformations that generate the models of each phase inan automatic or semi-automatic way, these models evolve ina consistent way up to the generation of the B2B specifi-cations. This guarantees that such a technological solutionis consistent and aligned with the business solution and theIT architecture solution. This also allows enterprises to besure that the generated B2B specifications really supportthe CBPs, and eventually, the business goals agreed amongenterprises at the business level.

Furthermore, the methodology fulfills the requirements ofthe B2B collaboration domain. To support these require-ments from the modeling of CBPs, we propose the use ofthe UPColBPIP language.

The separation of the business solution from the IT ar-chitecture solution enables the reuse of the business processmodels and the possibility to use different IT architectureparadigms. Also, IT architecture models can be reused togenerate technological solution based on different platformsfor the same architecture paradigm.

Finally, the architecture of an Eclipse-based IDE has beenproposed, which contains interoperable and integrated mod-eling tools and model transformation engines that supportthe proposed methodology.

Future work is about the definition of domain-specificlanguages and metamodels for supporting the modeling of

7777

the IT architecture solution and the technological solution,as well as the implementation of the corresponding transfor-mation machines in the Eclipse-based tool. Future work isalso about the integration of bottom-up approaches to allowthe reuse of existing processes or systems of the enterprises,and the evaluation of this methodology through several casestudies.

REFERENCES

[1] P.D. Villarreal, E. Salomone, and O. Chiotti, ”Modeling andSpecifications of Collaborative Business Processes using aMDA Approach and a UML Profile”, in Enterprise Modelingand Computing with UML, P. Rittgen, Ed. USA: Idea GroupInc, 2007, pp. 13–45.

[2] B. Bauer, S. Roser, and J. Muller, ”Adaptive Design of Cross-organizational Business Processes using a Model-driven Ar-chitecture”, in Wirtschaftsinformatik 2005. Physica-Verlag,2005, pp. 103–121.

[3] S. Roser, and B. Bauer, ”A Categorization of CollaborativeBusiness Process Modeling Techniques”, in IEEE Int’l Conf.on E-Commerce Technology Workshops. 2005, pp. 43–54.

[4] P.D. Villarreal, E. Salomone, and O. Chiotti, ”TransformingCollaborative Business Process Models into Web ServicesChoreography Specifications”, in DEECS 2006, LNCS, vol.4055. Springer, 2006, pp. 50–65.

[5] S. Roser, B. Bauer and J. Muller, ”Model and Architecture-Driven Development in the Context of Cross-Enterprise Busi-ness Process Engineering”, in IEEE Int’l Conf. on ServicesComputing (SCC’06). 2006.

[6] M. Brambilla, S. Ceri, F.M. Facca, I. Celino, D. Cerizza,and E.D. Valle, ”Model-Driven Design and Development ofSemantic Web Service Applications”, ACM Transactions onInternet Technology, vol. 8 (1) Article 3. 2007.

[7] C. Huemer, P. Liegl, T. Motal, R. Schuster, and M. Zaple-tal, ”The development process of the UN/CEFACT model-ing methodology”, in Int’l Conf. on Electronic Commerce(ICEC’08), vol. 342. ACM, New York, 2008, pp. 1–10.

[8] B. Selic, ”The Pragmatics of Model-Driven Development”,IEEE Software, vol. 20 (5), 2003, pp. 19–25.

[9] T. Gherbi, D. Meslati, and I. Borne, ”MDE between Promisesand Challenges”, in Int’l Conf. on Computer Modelling andSimulation. IEEE Computer Society, 2009, pp. 152–155.

[10] O. Nikiforovatitle, ”Two-Hemisphere Model Driven Ap-proach for Generation of UML Class Diagram in the Contextof MDA”, in e-Informatica Software Engineering Journal,Wrocław University of Technology, 2009.

[11] A.W. Brown, S. Iyengar, and S. Johnston, ”A rational ap-proach to model-driven development”, in IBM System Jour-nal, vol. 45 (3). 2006, pp. 463–480.

[12] P.D. Villarreal, I.M. Lazarte, J. Roa, and O. Chiotti, ”AModeling Approach for Collaborative Business Processesbased on the UPColBPIP Language”, in Lecture Notes inBusiness Information Processing, vol. 43. Springer, 2010, pp.318–329.

[13] M. Weske, Business Process Management: Concepts, Lan-guages, Architectures. Springer Heidelberg, 2007.

[14] OMG. BPMN V1.2, 09-01-03.pdf. Available:http://www.omg.org/spec/BPMN/1.2/PDF

[15] OASIS, Web Services Business Process ExecutionLanguage. Available: http://www.oasis-open.org/committees/download.php/23964/wsbpel-v2.0-primer.htm

[16] M.L. Caliusco, M.R. Galli, and O. Chiotti, ”Technologiesfor Data Semantic Modeling”, in Int’l. Journal of MetadataSemantics and Ontology, vol 1(4). 2006, pp. 320–331

[17] P.D. Villarreal, J. Roa, E. Salomone, and O. Chiotti, ”Ver-ification of Models in a MDA Approach for CollaborativeBusiness Processes”, in 10th Ibero-American Workshop ofRequirements Engineering and Software Environments. 2007.

[18] I.M. Lazarte, O. Chiotti, and P.D. Villarreal, ”TransformingCollaborative Process Models into Interface Process Modelsby Applying an MDA Approach”, in IFIP Conf. on Soft-ware Services for e-Business and e-Society (I3E), vol. 305.Springer, 2009, pp. 301-315.

[19] OMG. MDA Guide V1.0.1, 03-06-01.pdf. Available:http://www.omg.org/cgi-bin/doc?omg/03-06-01

[20] L. Thom, M. Reichert, and I. Cirano, ”Activity Patternsin Process-aware Information Systems: Basic Concepts andEmpirical Evidence”, in Int’l Journal of Business ProcessIntegration and Management, 4 (2). 2009, pp. 93–110.

[21] P. Mayer, A. Schroeder, and N. Koch, ”A Model-DrivenApproach to Service Orchestration”, in IEEE Int’l Conf.on Services Computing (SCC’08), vol. 2. IEEE ComputerSociety, 2008, pp. 533–536.

[22] A.W. Brown, J. Conallen, and D. Tropeano, ”Introduction:Models, Modeling, and Model-Driven Architecture (MDA)”,in Model-Driven Software Development. Berlin: SpringerHeidelberg, 2005, pp. 1–16.

[23] P. Mayer, A. Schroeder, and N. Koch, ”MDD4SOA: Model-Driven Service Orchestration”, in 12th Int’l IEEE EnterpriseDistributed Object Computing Conference (EDOC). IEEEComputer Society, 2008, pp. 203–212.

[24] I. Zinnikus, C. Hahn, and K. Fischer, ”A model-driven,agent-based approach for the integration of services into acollaborative business process”, in Proc. of the Int’l Conf.AAMAS 2008, vol. 1. 2008, pp. 241–248.

[25] W3C. Web Services Description Language, Version 1.1.Available: http://www.w3.org/TR/wsdl.

[26] F. Bellifemine, G. Caire, and D. Greenwood, DevelopingMulti-Agent Systems with JADE. England: Wiley, 2007.

[27] J. Roa, V. Castaneda, P.D. Villarreal, and O. Chiotti, ”A Toolfor Model-Driven Development of Collaborative BusinessProcesses”, in XXXIV CLEI 2008, Argentina, 2008.

[28] Eclipse Org. Eclipse Platform. Available: www.eclipse.org

[29] VICS. Collaborative planning, forecasting, andreplenishment - Voluntary guidelines, V 2.0. Available:http://www.vics.org/committees/cpfr/voluntary v2/

7878