Orchestration Definition from Business Specification Charif Mahmoudi Logics, Algorithm, Complexity Laboratory LACL, Paris 12 University Creteil, France charif.mahmoudi@lacl.fr Fabrice Mourlin Logics, Algorithm, Complexity Laboratory LACL, Paris 12 University Creteil, France fabrice.mourlin@wanadoo.fr Abstract—The implementation of service orchestration is often seen as a convoluted process for business analysts, lead developers and architects. In this document, we propose a new approach based on a continuous process starting from the analysis phase to the architecture phase as an attempt to standardize the implementation of service orchestration. Our ultimate goal is to have a BPEL (Business Process Execution Language) script which will be interpreted by an engine residing inside a middleware generating a composition of elements where each element can be considered as an independent component equipped with a Web service. Orchestration definition contains several facets such as logical, pragmatic and architectural aspects; each of them is complementary and the interaction between them usually raises conflicts. In our approach, these issues are addressed and solved by adaptation rules and the problem of adapting the software architecture onto a physical architecture is solved by the pragmatism method. Keywords-SOA; Architecture; Web service orchestration; business process design and specification I. INTRODUCTION The component-oriented approach has emerged and has become widespread in the industry to meet the scalability of information systems [1]. It reduces software costs and allows rapid adaptation to changing business and technological developments. It also enables software components to create highly modular and integrated. The development of certain parts of the information system may be too independent. This component-oriented approach allows governing the evolution of technical and functional information system based on standard software. In addition, it covers all aspects of development and life cycle of the software. With the emergence of the component-based modeling paradigm, the OMG (Object Management Group) did not remain inactive and has proposed a new architecture based on MDA rules [2]. The development has facilitated UML modeling components. In 2001, the OMG defined the MDA approach with the aim to facilitate the integration of applications and make the specification of independent application development technologies. It also sets rules for mapping the standard specifications of different technologies [3]. UML Modeling tools generate the code source structure of applications. There is a transformation of a logic model to design model to the platform on the basis of design pattern templates and code [4]. The SOA is not far away removed from the component- oriented approach; see Peter Herzum [5]. He is one of the first authors having clearly defined the concept of components and component architecture. From his point of view, there are three types of components: Components "business process", components "business entity" that implement a core business concept, and finally, the component "business tool" used in various system components. He proposed to build a system specification based on four models. A business process model is used to identify components known as "business process" that manage one or more use cases. A model of "business entities" supports one or more business processes. A model is created to define business events. Another model is created for the definition of business rules. The component-oriented approach has been developed within companies, but the purpose of sharing common components is often wishful thinking. Projects are organized into business lines. The application needs vary greatly over time. The services are requested too often, and the code of common components is duplicated and modified directly in new applications as alternatives. Reuse requires the establishment of specific resources such as the development of cataloging tools, dissemination of information about the components, creating a team to administer the transverse components. It also requires the definition of a target upstream of urbanization of the information system. We present in this contribution our approach to defining orchestration from business specification, and to mix it with other reused components. In the next section, we explain our design process for SOA architecture. Then, we give details about the semantic model of our approach and pragmatic model also. The following section is about logical model and how we declare it. The last part is about architecture and implementation of orchestration. Finally, we provide a case study of our approach. II. DESIGN PROCESS FOR SOA ARCHITECTURE The concept of enterprise architecture management was gradually adopted in enterprises to address the problems of organization and urban information system. Different methodological approaches have been developed or 197 Copyright (c) IARIA, 2012. ISBN: 978-1-61208-230-1 ICSEA 2012 : The Seventh International Conference on Software Engineering Advances