FREE ELECTRONIC LIBRARY - Thesis, dissertations, books

Pages:   || 2 | 3 |

«Abstract. Service-Oriented Architecture (SOA) has emerged as an architectural style to foster enterprise interoperability, as it claims to facilitate ...»

-- [ Page 1 ] --

Model-Driven Development of Service

Compositions for Enterprise Interoperability

Ravi Khadka1, Brahmananda Sapkota2, Lu´ Ferreira Pires2,


Marten van Sinderen2, and Slinger Jansen1

Utrecht University, PO Box 80.089, 3508TB Utrecht, The Netherlands,

{ravi, s.jansen}@cs.uu.nl

University of Twente, PO Box 217, 7500AE Enschede, The Netherlands,

{b.sapkota, l.ferreirapires, m.j.vansinderen}@ewi.utwente.nl

Abstract. Service-Oriented Architecture (SOA) has emerged as an architectural style to foster enterprise interoperability, as it claims to facilitate the flexible composition of loosely coupled enterprise applications and thus alleviates the heterogeneity problem among enterprises.

Meanwhile, Model-Driven Architecture (MDA) aims at facilitating the development of distributed application functionality, independent from its implementation using a specific technology platform and thus contributes to deployment in different platforms. In this paper we propose an MDA-based transformation technique for service composition. The contribution of the paper is two-fold. First, our approach shows how enterprise interoperability is supported by service composition at two different technical levels, namely at choreography and orchestration level.

Second, the approach contributes to the management of changes that affect enterprise interoperability, by defining a (semi-)automated transformation from choreography to orchestrations in which the interoperability constraints specified at the choreography level are preserved.

Keywords: SOA, MDA, Metamodel Transformation, Enterprise Interoperability, Choreography, Orchestration, Service Composition, Service Interoperability 1 Introduction Enterprise interoperability denotes the ability of organizations, hereafter called enterprises, to interoperate in order to achieve certain business goals [13]. To a large extent, the competitiveness and success of modern enterprises is determined by their ability to achieve enterprise interoperability. Advances in Internet technologies have contributed substantially to the propagation and efficiency of cross-organizational collaboration. Nonetheless, important obstacles remain due to business-driven proprietary developments. Therefore, enterprise interoperability problems should be addressed coherently at business and technical levels as a whole [22]. Enterprises are especially challenged by the accelerating pace of changes, such as intra-organizational changes, changes in market demands 2 R. Khadka, B. Sapkota, L. Ferreira Pires, M. van Sinderen and S. Jansen and opportunities, and, consequently, changes in partners and ways and intent of collaboration, and the changes in supporting technologies. To manage these changes, automatic support is essential.

Service-Oriented Computing (SOC) is one of the promising technologies to realize the necessary automated support for change management. The underlying concept of SOC is service, which is described in [16] as a self-contained, platform-agonistic computational element that supports rapid, low-cost and easy composition of loosely coupled distributed software applications. A service can be described, published, and discovered by an enterprise with a focus on reusing external behavior and hiding implementation details. However, in an enterprise collaboration, no single service alone may be available that fulfills all collaboration goals. A typical approach to this problem is to identify the basic (noncomposite) services, based on an analysis of the collaboration goals, and then aggregate them into a larger composite service with the appropriate value-added functionality. We call this process of aggregating services “service composition”, which not only realizes a required (composite) service, but also accelerates application development through the application of reuse at service level [11].

Service compositions can be considered at different abstraction levels, notably at choreography and orchestration levels [17, 2]. A service choreography is a decentralized perspective, which describes the public message exchanges, and thus defines how participating services should interact with each other. At a lower level, it is necessary to define how to realize the responsibilities specified at the choreography level in terms of the concrete processes. A service orchestration is a centralized coordination of participating services, which defines the message exchanges along with the necessary internal actions, like data transformations and internal function invocations [17]. In an enterprise collaboration, a service choreography specifies requirements in terms of message exchanges to support the collaboration goals, while a service orchestration realizes the required message exchanges in terms of executable processes.

It has been widely recognized that SOC technology and SOA have emerged as evolutionary steps to achieve enterprise interoperability [13]. Enterprises can publish their services to alleviate the heterogeneity problem. The collaboration among these enterprises is realized by composing their individual services through the service composition process. In this phase, we need service interoperability at the technical level to realize enterprise interoperability. In the service composition process we specify the interoperability constraints at service choreography level, which focuses on the message exchanges between the participating services. At a lower level, such as in the service orchestration level, interoperability constraints as specified at the choreography level are preserved. Therefore, an approach is needed to transform a given choreography to one or more orchestration(s). Currently these transformations are mostly performed manually [12], which is a time consuming and error prone. A (semi-)automated transformation from choreography to orchestrations, such that it preserves the interoperability constraints specified at the choreography level and automates the enterprise collaboration process, would represent an improvement. In this paper, we propose an approach to (semi-)automate the transformation from choreography to MD Development of Service Compositions for Enterprise Interoperability 3 orchestrations using metamodel transformation techniques from MDA [15]. We refer to this process as model-driven service composition. In this approach, we define the metamodels for choreography and orchestration and mappings between model elements of these metamodels. Our proposed approach of (semiautomated transformation of choreography into orchestrations improves the productivity of the composition process and correctness of the resulting compositions.

The rest of the paper proceeds as follows: Section 2 introduces our approach to model-driven service composition for enterprise interoperability. Section 3 describes an example scenario that we used for illustrating the proposed approach.

Section 4 discusses how this approach was implemented and Section 5 discusses the evaluation of our approach. Section 6 presents related work and finally Section 7 concludes the paper and gives an outlook of future research directions.

2 Approach

Our approach is to perform service composition by (semi-)automatically transforming the given choreography into one or more orchestration(s) using modeldriven transformation techniques. In this section, we investigate the relationship between choreography and orchestration, and indicate how model-driven transformation can be useful to relate these concepts.

A choreography describes the public message exchanges, interaction rules and agreements in a service composition at a high level of abstraction [17, 2]. A choreography is defined from a decentralized perspective, and specifies how the individual services interact with each other. A service choreography does not describe any internal actions of the participating services, like internal computations or data transformations. A choreography captures message exchanges from a global perspective where all the participating services are treated equally, and as such it provides a convenient starting point to define how the participating services must interact to realize enterprise collaboration. At the choreography level, the interactions among each service participating in the composition are described as a global


protocol with which all participating services should comply [2].

After the message exchanges between the participating services are defined in a choreography, we need to define how the added-value of the composite service can be achieved in terms of a concrete implementation. We call the process that realizes the business goal of the enterprise collaboration in terms of executable process an orchestration. There may be one orchestration for each service, or a central authority that coordinates the overall composition process, so called decentralized orchestration and centralized orchestration, respectively [5, 4]. In centralized orchestrations, the central authority is called an orchestrator. Orchestrations describe the communication actions and the internal actions, like data transformations or invocations to internal software modules. In an orchestration, execution orders of the interactions and method invocations of the implemenR. Khadka, B. Sapkota, L. Ferreira Pires, M. van Sinderen and S. Jansen tations also need to be defined [17, 2] in terms of an executable process that contains enough information to enable execution by an orchestration engine.

Fig. 1. Transformation from choreography to centralized orchestration A given choreography can be transformed to either a decentralized or a centralized orchestration. In this paper we only consider the transformation from choreography to centralized orchestration because centralized orchestration is widely used in the service composition process. A diagrammatic representation of the transformation from a choreography to a centralized orchestration is presented in Figure 1. In the choreograph level of Figure 1 the message exchanges and interactions rules are represented by the directed arrows among the services.

The overall responsibility of choreography, represented as R, includes message exchange, interactions rules, and the service level constraints. The transformation from choreography to centralized orchestration is achieved by transferring the overall responsibility of choreography R to the orchestrator and establishing the message exchanges, interactions rules, and the interoperability constraints between the orchestrator and the individual services accordingly. The responsibility R is represented as an executable artifact and is depicted as the flow diagram in the orchestration level of Figure 1.

In our approach we specify service choreographies and orchestrations using Web Service Choreography Description Language (WSCDL or CDL in short) [9] MD Development of Service Compositions for Enterprise Interoperability 5

Fig. 2. Model-driven transformation

and Web Service Business Process Execution Language (WSBPEL or BPEL in short) [1], respectively, because of the wide industry acceptance of these languages.

We apply model-driven transformation to (semi-)automate the transformation from a choreography specified in CDL to a centralized orchestration specified in BPEL. The model-driven transformation is diagrammatically presented in Figure 2. In this transformation, we take the CDL metamodel as source metamodel and BPEL metamodel as target metamodel. We used the language syntax of [9] and [1] to develop the metamodels of CDL and BPEL, respectively. We defined the mappings between CDL and BPEL metamodel elements. These mappings are then used to create transformation specifications in Atlas Transformation Language (ATL) [7], and hence executed by ATL transformation engine. The transformation mappings of the metamodel elements of CDL and BPEL are presented in Table 1.

3 Working Example

The Build-To-Order (BTO) application scenario, adopted from [19] is used as an example to illustrate the usability of our approach. We briefly explain this scenario with the sequence diagram shown in Figure 3. The BTO scenario consists of a customer, a manufacturer, and suppliers for CPUs, main boards and hard disks. We consider all the suppliers to be different enterprises. The manufacturer offers assembled IT hardware equipment to its customers. For this purpose, the manufacturer has implemented a BTO business model. It holds a certain part of the individual hardware components in stock and orders missing components if necessary. In the implemented BTO scenario, the customer sends a quote request with details about the required hardware equipment to the manufacturer.

The latter sends a quote response back to the customer. As long as the customer and the manufacturer do not agree on the quote, this process is repeated. If a mutual agreement is reached the customer sends a purchase order to the manR. Khadka, B. Sapkota, L. Ferreira Pires, M. van Sinderen and S. Jansen

–  –  –

ufacturer. Depending on its hardware stock, the manufacturer has to order the required hardware components from its suppliers. If the manufacturer needs to obtain hardware components to fulfill the purchase order it sends an appropriate hardware order to the respective supplier. In turn, the supplier sends a hardware order response to the manufacturer. Finally, the manufacturer sends a purchase order response back to the customer.

4 Implementation Based on the BTO application scenario, we specified the choreography in CDL, and (semi-)automatically generated the BPEL based orchestration specification for the Manufacturer as an orchestrator. The orchestration process is specified in BPEL. To implement our proposed approach, we defined the CDL and BPEL metamodel using Eclipse Modeling Framework (EMF)1. EMF is an Eclipsebased modeling framework and has code generation facilities for building tools http://www.eclipse.org/modeling/emf/ MD Development of Service Compositions for Enterprise Interoperability 7 Fig. 3. BTO example and other applications based on a structured data model. The transformation specification has been written based on the transformation mapping presented in Table 1 using ATL2, which contains the ATL transformation engine that runs ATL transformation specifications as transformation rules.

Pages:   || 2 | 3 |

Similar works:

«Bitcoins: Made in China Tim Swanson Revised: May 11, 2014 Abstract: The discussion over the actual costs of maintaining a decentralized seigniorage network is a new area of research. In practice it appears that the logistical cost of operating the Bitcoin network rises linearly with its total value. More efficient mining gear does not reduce energy use of the Bitcoin network. It only raises the network difficulty. The proof-of-work method used to mitigate rogue attacks, must expend real work,...»

«A Know your Enemy: Compromising Adversaries in Protocol Analysis DAVID BASIN, ETH Zurich CAS CREMERS, University of Oxford We present a symbolic framework, based on a modular operational semantics, for formalizing different notions of compromise relevant for the design and analysis of cryptographic protocols. The framework’s rules can be combined to specify different adversary capabilities, capturing different practically-relevant notions of key and state compromise. The resulting...»

«Ship grave hall passage – the Oseberg monument as compound meaning Frands Herschend Uppsala University The ship in the grave from Oseberg is 23 metres long (Brøgger et al. 1917; Christensen et al. 1992). It stands next to a river on its keel on the rollers that made its journey on land possible. A mound covers the ship. Some time after the construction of the monument, perhaps a hundred years or so, someone made a an impressive straight cut into the mound, broke through the roof of the...»

«ISSN 2305-9001. Вісник НТУУ «КПІ». Серiя машинобудування №3 (69). 2013 УДК 621.9.06.–233.1:621.822.76 Зверев1 И.А., д.т.н., Данильченко2 Ю.М., д.т.н. 1МГТУ «Станкин», г. Москва, Россия; 2НТУУ «Киевский политехнический институт», г. Киев, Украина КИНЕМАТИКА И ЖЕСТКОСТЬ РАДИАЛЬНО-УПОРНЫХ...»

«Louis, Lester and Pierre: Three Protocols for Location Privacy Ge Zhong, Ian Goldberg, and Urs Hengartner David R. Cheriton School of Computer Science University of Waterloo Waterloo, ON, Canada N2L 3G1 {gzhong,iang,uhengart}@cs.uwaterloo.ca Abstract. Location privacy is of utmost concern for location-based services. It is the property that a person’s location is revealed to other entities, such as a service provider or the person’s friends, only if this release is strictly necessary and...»


«eBook summary Government Budget Analyst Interview Questions Answers in our online Library. Free read Government Budget Analyst Interview Questions Answers PDF file GOVERNMENT BUDGET ANALYST INTERVIEW QUESTIONS ANSWERS PDF Download: GOVERNMENT BUDGET ANALYST INTERVIEW QUESTIONS ANSWERS PDF Online digital document GOVERNMENT BUDGET ANALYST INTERVIEW QUESTIONS ANSWERS File update. So you are person who likes to download government budget analyst interview questions answers Pdf to any kind of...»

«Palms of controversies Oil palm and development challenges Alain Rival Patrice Levang Palms of controversies Oil palm and development challenges Alain Rival CIRAD Patrice Levang IRD / CIFOR Center for International Forestry Research © 2014 Center for International Forestry Research Content in this publication is licensed under a Creative Commons Attribution-NonCommercialNoDerivs 3.0 Unported License http://creativecommons.org/licenses/by-nc-nd/3.0/ Rival A and Levang P. 2014. Palms of...»

«CONTAINER STORE GROUP, INC. FORM DEF 14A (Proxy Statement (definitive)) Filed 06/17/14 for the Period Ending 08/04/14 Address 500 Freeport Parkway Coppell, TX 75019 Telephone 972-538-6000 CIK 0001411688 Symbol TCS SIC Code 5700 Retail-Home Furniture, Furnishings & Equipment Stores Fiscal Year 02/28 http://www.edgar-online.com © Copyright 2014, EDGAR Online, Inc. All Rights Reserved. Distribution and use of this document restricted under EDGAR Online, Inc. Terms of Use. Table of Contents UNITED...»

«Gender Heroes: from grassroots to global action A COLLECTION OF STORIES FEATURING GENDER PERSPECTIVES ON THE MANAGEMENT OF HAZARDOUS CHEMICALS AND WASTES Gender Heroes: from grassroots to global action A COLLECTION OF STORIES FEATURING GENDER PERSPECTIVES ON THE MANAGEMENT OF HAZARDOUS CHEMICALS AND WASTES Acknowledgements The Secretariat of the Basel, Rotterdam and Stockholm Conventions expresses its gratitude to those who contributed to this publication, including: Sarojeni V. Rengam...»

«KIPP Academy Boston Student & Family Handbook 2015-2016 Table of Contents KIPP Academy Boston’s Mission Nondiscrimination Responsibility & Accountability Absence From the First Five Days of School To Contact Us KIPP Academy Boston Commitment to the Pride School Policies & Procedures Hours of School Operation Inclement Weather Closings Attendance Policy Lateness & Early Dismissal Make-Up Work Policies Closed Campus Shared Space Breakfast, Lunch, & Snack Restrictions on Bringing Food/Beverages...»

«Bob Dylan’s ‘Roll on John’ – lyric analysis. “Roll on John” is another masterpiece from the album ‘Tempest’ which I really love. The song has a melancholy melody, it chimes and despairs, the music lingers on as we are slowly drifting from scene to scene and Dylan’s voice is really heartfelt. When I heard the song for the first time, the lyrics somehow disappointed me. My first thought was that, no matter how great an artist John Lennon may have been and no matter how much I...»

<<  HOME   |    CONTACTS
2016 www.dis.xlibx.info - Thesis, dissertations, books

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.