A Semantic Service Oriented Architecture for Enterprise Application Integration

Transcription

1 2009 Second International Symposium on Electronic Commerce and Security A Semantic Service Oriented Architecture for Enterprise Application Integration Liyi Zhang Center for Studies of Information Resources, Wuhan University lyzhang@whu.edu.cn Si Zhou School of Information Management, Wuhan University si_chow@msn.com Mingzhu Zhu School of Information Management, Wuhan University zhumzhu@163.com Abstract Although Service Oriented Architecture (SOA) goes a long way toward providing interoperability in distributed and heterogeneous environments for Enterprise Application Integration (EAI), managing semantic differences in such environments remains a challenge. This paper proposes a framework of semantic SOA for Enterprise Application Integration, and uses Web Service Modeling Ontology (WSMO) as its semantic service model. Last, we introduce a running example using semantic SOA for Enterprise Application Integration. Keywords- Service Oriented Architectur; semantic; Enterprise Application Integration; WSMO; SOA I. INTRODUCTION Within the enterprise, information infrastructure as the mean to bring together different software applications is the key component to enable cooperation and information exchange in an open-distributed environment. Hence, most of enterprises constantly seek new ways to optimize and integrate their systems. To achieve this aim, a new technology and a new industry sector, typically known as Enterprise Application Integration technology, have emerged over the last decade. The Enterprise Application Integration has experienced an evolution from point to point integration to process integration, and now it has evolved towards Service Oriented Architectures [1]. SOA is suitable for a process oriented, distributed integration. Different enterprise systems are connected through one interface, and a cross-system data transfer and the reusage of objects or components is enabled. The SOA approach is commonly based on the Web Service technologies which allow interoperability by relying on standards like UDDI (Universal Description Discovery and Integration), WSDL (Web Services Description Language), and SOAP (Simple Object Access Protocol) etc. Within the architecture, a user wants to use a service and in doing so achieve a specific result. Moreover, the user is not interested in how the request is processed or which further requests are necessary. This is the idea of SOA, where services are defined in a specific language and referenced in a service index. Service request and data exchange occur via use of predefined protocols. Thereby a service represents a welldefined function which is generated in reaction to an electronic request. The SOA approach offers a relatively easy way to connect, add and exchange single services, which highly simplifies the integration of similar systems. Furthermore, Figure 1. Traditional SOA based Enterprise Application Integration /09 $ IEEE DOI /ISECS

2 SOA offers a high degree of interoperability and modularity, which increases the adaptability of enterprise systems [2]. Fig. 1 represents a brief description of typical SOA based Enterprise Application Integration. Although the idea of SOA targets the need for integration that is more adaptive to change in business requirements, existing SOA solutions will prove difficult to scale without a proper degree of automation, and also fail as they do not provide more flexibility and agility [3]. While today s service technologies around WSDL, SOAP, UDDI and BPEL (Business Process Execution Language) certainly brought a new potential to SOA, they only provide partial solution to interoperability, mainly by means of unified technological environments. For example, the description of web service by WSDL is based on syntax, so the retrieval of right services relies on keywords that will probably lead to unsuitable results with formally match but semantically not. Thereby, service discovery within traditional SOA is time-consuming and errorprone. Additionally, without machine understandable semantics, services must be located and bound to service requesters at design-time which in turn limits possibilities for automation. So, the semantic integration constitutes a big challenge that must be addressed in the context of large and dynamic enterprises. II. GLOBAL SEMANTIC SOA FOR ENTERPRISE INTEGRATION In this section we define the overall semantic SOA for Enterprise Application Integration, which depicted in Fig. 2. This architecture includes 5 layers: Presentation Layer, forming two groups of users of the architecture, and provide interfaces respectively; Transition Layer, formalizing semantic tasks and managing domain ontologies; Middleware Layer, providing the intelligence for the integration and interoperation of business services; Services Layer, exposing the functionality of backend applications as Business Services; Data Layer, providing available data and knowledge. A. Presentation Layer Presentation Layer provides interfaces to specific stakeholders. There are different groups of stakeholders which use the functionality of the architecture for various purposes. Two basic groups of stakeholders are identified: users, and Figure 1. Traditional SOA based enterprise application integration. 103

3 engineers. Users form the group of those stakeholders to which the architecture provides end-user functionality through specialized applications via Portal. For example, users can perform electronic exchange of information to acquire or provide products or services, to send or receive orders or to perform financial transactions. Generally, the goal is to allow users to interact with business processes on-line while at the same time reduce their physical interactions with back-office operations. On the other hand, the group of engineers forms those stakeholders which perform development and administrative tasks in the architecture via Developer Interface. Different types of engineers could be involved in this process ranging from domain experts (ontology modeling, creation), system administrators (ontology deployment, monitoring) and software engineers. B. Transition Layer Transition Layer renders functionalities to specific stakeholders aforementioned. To users, it creates semantic goals through task formulation by which users describe tasks as well as interfaces through which they wish to perform conversation with potential services. To engineers, it provides functionalities cover the development process including ontology modeling, monitoring, deployment (publishing), and management. C. Middleware Layer Middleware is the core of the architecture providing the main intelligence for the integration and interoperation of business services. The Middleware Layer defines the necessary conceptual functionality that is imposed on the architecture. Each such functionality could be realized (totally or partially) by a number of so called middleware services. We further distinguish this functionality into the following layers: Vertical layer, Execution layer, and Base layer. The Vertical layer defines the middleware framework functionality that is used across the Execution and Base layers but which remains invisible to them. With this respect, framework functionality always consumes functionality of Execution and Base layers, coordinating and managing overall processes in the middleware. Fault Handling defines a handling of faults occurring within execution of end point web services. Security defines a secure communication, i.e. authentication, authorization, confidentiality, data encryption, traceability or non-repudiation support applied within execution scenarios in the architecture. The Execution layer defines the functionality which is directly required for a task based invocation of semantic web services. The Execution layer includes: Refinement defines process of creating an abstract task from a concrete task. Discovery defines tasks for identifying and locating business services which can achieve a users task. Orchestration defines the execution of a composite process (business process) together with a conversation between a service user and a service provider within that process. Adaptation defines an adaptation within particular execution scenario according to users preferences (e.g. service selection, negotiation, contracting). Mediation defines interoperability at the functional, data and process levels. Composition defines a composition of services into an executable workflow (business process). Grounding defines a link between semantic level (e.g. WSMO) and a non-semantic level (e.g. WSDL) used for service invocation. Selection defines process where one service which best satisfies a user preference is selected from candidate services returned from the service discovery stage. The Base layer defines functionality that is not directly required in an invocation of business services however they are required by the Execution Layer for successful operation. Base layer includes: Formal Languages defines syntactical operations (e.g. parsing) with semantic languages used for semantic description of services, goals and ontologies. Reasoner defines reasoning mechanism over semantic descriptions. Storage defines persistence mechanism for various elements (e.g. services, ontologies). Communication defines inbound and outbound communication of the middleware. D. Services Layer Services Layer represents various back-end applications act as encapsulated servers which provide certain functionality for certain purpose exposed as a business service to the architecture. Depending on particular architecture deployment and integration scenarios, the back-end applications could originate from one organization (one service provider) or multiple organizations (more service providers) interconnected over the network (internet, intranet or extranet). The architecture thus can serve various requirements not limited to Enterprise Application Integration, but also Business to Business (B2B) integration. In all cases, functionality of backend applications is exposed as semantically described business services. E. Data Layer Data Layer arranges all the necessary data and knowledge including database, resource, knowledge base, and standard library. All the data here will be invoked, added, or modified by Middleware Layer during the semantic execution. 104

4 III. IMPLEMENTATION TECHNOLOGIES FOR SEMANTIC SOA In this section we describe a concrete semantic service model and technology we choose for realization of the global semantic service oriented architecture for enterprise integration described in section 2. Compare to the traditional SOA based Enterprise Application Integration depicted in Figure 1, the most critical improvements of semantic SOA for Enterprise Application Integration are the additional Transition Layer and the reformative semantic service process mechanism of Middleware Layer build on the top of service stack by introducing a semantic mark-up for functional, non-functional and behavioral aspects of service descriptions. Today, several initiatives exist in this area such as WSMO (Web Service Modeling Ontology) [4], OWL-S (Ontology Web Language for Services) [5] and WSDL-S (Web Service Description Language with Semantics) [6]. With respect to characteristics of different technologies [7], we choose the WSMO model for our work. Because WSMO covers most of the description elements introduced in OWL-S, and introduces additional elements that increase its applicability in real domains. Aspects such as mediation and compensation are key issues to be solved for the realization of Semantic Web Services (SWS), and to make this technology applicable for e-commerce and EAI. In addition, WSMO is being developed as a complete framework including: the conceptual model describing all relevant aspects of Web services ontologies, goals, web services and mediators, Web Service Modeling Language (WSML) a family of ontology languages based on different logical formalisms and different levels of logical expressiveness, Web Service Execution Environment (WSMX) a reference implementation for the middleware system, and the Web Service Modeling Toolkit (WSMT) an IDE used for engineering of WSMO descriptions (services, goals, and ontologies), creation of mediation mappings, and interfacing with architecture middleware and external systems. WSMO thus provides comprehensive semantic modeling of services and semantic technology for semi-automated discovery, composition and execution of Web Services which are based on logical inference-mechanisms [8]. WSMO defines four main modeling elements for describing several aspects of semantic web services: Ontologies: They represent the key element in WSMO, firstly to define the information s formal semantics and secondly to link machine and human terminologies. WSMO ontologies give meaning to the other elements (Web Services, goals and mediators), and provide common semantics, understandable by all the involved entities (both humans and machines). Goals: Goals represent the objectives of the service requester to be fulfilled when consulting a Web Service. The advantage of using goals is that users only have to provide a declarative specification of what they want. It is not necessary for them to have a prior knowledge of the web service or to browse through a UDDI registry to find services providing the appropriate functionality. The WSMO goal is characterized by a requested capability and a requested interface. Web Services: These provide the functionality in this framework, to process data or changing states in the physical world. They must be described semantically in order to allow at least their semi-automated use. Additionally the interface and functional capability they offered have to be defined. Mediators: These are used to map between WSMO elements if they are based on different technologies, e.g. input and output data structures, business logics, message exchange protocols. IV. A RUNNING EXAMPLE In this section we introduce a simplified running example to demonstrate potentials of the semantic service oriented architecture for enterprise integration depicted in Fig. 3. Company A is a multinational enterprise with more than employees operating in more than 30 countries in Asia, and has a specific e-procurement system named AEPS which gathering more than Asian suppliers. For market expansion in Europe, company A merged a European company B with its own e-procurement system named BEPS which connecting more than 500 suppliers in Europe. Company A wants to have a unified e-procurement Platform (EPP) that contains both Asian and European suppliers, without building a new e-procurement system. So it plans to integrate these existing e-procurement systems using semantic service oriented architecture. Following are the prerequisites of the scenario. Service users and providers are using various back-end systems for handling interactions in their environment. In particular, suppler A from Asia using AEPS while suppler B from Europe using BEPS, and product manager of company A using unified e-procurement Platform. Engineers representing service users and service providers respectively model services and requests using the WSMO model while at the same time different ontologies as well as different descriptions of choreographies are used by service user and provider. In particular, product manager sends his request to and expects to receive a response from EPP via intranet. On the other hand, suppler A from AEPS in order to Service User WSMO Goal Capability Interface EPP Middleware Domain Ontologies Service Discovery Selection Orchestration Figure 1. Running example. Service Providers Supplier A Service Supplier B Service Capability Interface AEPS BEPS 105

5 process the request must perform more interactions with EPP according to the RosettaNet specification, and supplier B from BEPS according to the ebxml specification. Thus, data and process interoperability issues exist between product manager and suppliers: product manager uses information model and choreography defined by the intranet, suppler A and suppler B use information model and choreography defined by the RosettaNet and ebxml respectively. Service users and service providers maintain the integration with their respective systems through the implementation of necessary web services (adapters for their systems). Both AEPS and BEPS are responsible for maintaining these adapters and their integration with the EPP through semantic descriptions and/or through interfaces with the EPP. Engineers representing service users and service requesters respectively publish ontologies they use for WSMO goal and service descriptions in the Domain ontologies repositories. In addition, they publish mapping rules between their ontologies and existing domain ontologies. The scenario runs as follows: firstly, all the business partners model their business services using WSMO. After that, product manager sends the purchase order request captured in WSMO goal to the middleware which on receipt of the goal executes the execution semantics including: discovery, selection and orchestration. During discovery, the matching is performed for the goal and potential services. During selection, the best service is selected (in our case Supplier B Service) based on preferences provided by product manager as part of the WSMO goal description. Finally during orchestration, the execution and conversation of product manager and Supplier B services is performed by processing the choreography descriptions from product manager s goal and Supplier B s service. V. CONCLUSIONS In this paper we have proposed a semantic service oriented architectures for Enterprise Application Integration. We applied the principles of the Web Service Modeling Ontology (WSMO) to this new type of architecture. From the running example of company A, some merits of semantic service oriented architecture for enterprise integration can be draw out. First, it improves the service discovery. Semantic web search technology allows users to search on ontological concepts rather than by keyword. This will allow users to find the most appropriate services more quickly, and then narrow down their search via more expressive queries if required. This is important both within the enterprise and when searching for services provided externally. Second, it simplifies change management. Changes to models and services are inevitable over time. The key thing is to reduce the knock-on effect of change or at least manage it. A semantic approach will significantly reduce the overhead and simplify the process. Third, it supports semi-automatic service composition and enhanced interoperability between services. Services can be chosen at run time based upon their availability or other factors, such as quality. This leads to the situation where competing services from multiple business partners can be evaluated and chosen. ACKNOWLEDGMENT The authors were supported in part by the MOE Project of Key Research Institute of Humanities and Social Science in Chinese Universities (NO: 07JJD870220). The authors would like to express our sincere gratitude to the contributing author and to the referees for reviewing papers for this special issue. REFERENCES [1] A. Lämmer, S. Eggert, and N. Gronau, A Procedure model for a SOA- Based integration of enterprise systems, International Journal of Enterprise Information Systems, vol. 4, pp. 1 12, April-June [2] A. Duke, J. Davies, and M. Richardson, Enabling a scalable serviceoriented architecture with semantic Web Services, BT Technology Journal, vol. 23, pp , July [3] M. Contreras and L. Sheremetov, Industrial application integration using the unification approach to agent-enabled semantic SOA, Robotics and Computer-Integrated Manufacturing, vol. 24, pp , October [4] D. Roman, U. Keller, H. Lausen, J. de Bruijn, R. Lara, M. Stollberg, A. Polleres, C. Feier, C. Bussler, and D. Fensel, Web Service Modeling Ontology, Applied Ontologies, vol. 1, pp , [5] D. Martin, et al. Owl-s: Semantic markup for web services, version 1.1 available at [6] A. Patil, S. Oundhakar, A. Sheth, K. Verma, SemanticWeb Services: Meteor-SWeb service annotation framework, In: 13th International Conference on World Wide Web, pp , [7] L. Rubén, R. Dumitru, P. Axel, F. Dieter, A Conceptual comparison of WSMO and OWL-S, Lecture Notes in Computer Science, vol. 3250, pp , September [8] V. Tomas, et al. Semantically-enabled service oriented architecture: concepts, technology and spplication, Service Oriented Computing and Applications, vol. 1, pp. 1 36, June