Prototype of a Framework for Ontology-aided semantic conflict resolution in enterprise integration Željko Vuković * , Nikola Milanović * , Gregor Bauhoff ** * Faculty of Technical Sciences, University of Novi Sad, Serbia ** PI Informatik GmbH, Berlin, Germany zeljkov@uns.ac.rs, mnikola@gmail.com, bauhoff@pi-informatik.de Abstract — Enterprise integration carries the need for resolution of various semantic conflicts. These conflicts come in many forms and each of those may appear in a different context. Conflict detection and resolution can be made easier if a semantic description of the involved systems is available. We have developed a prototype, based on existing software - Talend Open Studio ESB, for a framework where a user may attach an ontology to interface elements and have those interfaces mapped automatically. We present how this prototype was tested on a scenario for which a solution was previously developed manually at Model Labs GmbH/PI Informatik GmbH, Berlin. I. INTRODUCTION Developing enterprise integration solutions presents various challenges: unreliable and slow networks, heterogeneous applications, inevitable changes over time [1]. Differences between applications may be technical or semantic. Data may be stored in different format (e.g. 32 vs. 64 byte, little- vs. big-endian), interface elements with the same semantics may have different names, interface elements with the same name may have differing semantics and so on. One system may return data as a collection, while another one may expect elements of that collection one at a time. Manually detecting and resolving these conflicts is a tedious, error prone work. Often, a lot of glue code is needed to make systems work together [1]. We have developed a prototype for a framework that can help automate some of the steps in conflict resolution. Interfaces and their elements can be semantically described using ontologies in order to facilitate this automation. In this paper, we describe a prototype for this framework and how we have tested it on a real-world integration scenario. II. RELATED WORK In [2] a framework is given for conflict analysis and composition at the component level. Components that originate in object oriented middleware are represented canonically on common denominator basis. The framework is model based. A classification of semantic conflicts is given in [3]. Here, three dimensions are used for classification: naming, abstraction and level of heterogeneity. One (meta) model-based platform for integration is given in [4] along with the accompanying methodology. It allows for a tight cooperation with the domain expert. The platform enables semi-automatic conflict analysis. An example of using ontologies expressed using the Web Ontology Language (OWL) and available on a network is shown in [5]. It was concluded that by adding classes to an existing ontology, enterprise integration was possible in hours time. An approach called ODSOI (Ontology- Driven Service-Oriented Integration) was proposed for using a combination of ontologies and web services in [6] to address some problems of enterprise integration, along with a vision of an integration framework. Following Model-Driven Architecture and using a Domain Specific Language (DSL) was proposed in [7]. A DSL called Guaraná was proposed for design and automatic deployment of integration solutions. Another (internal) DSL for enterprise integration called Highway is presented in [8]. It is based on Apache Camel and Clojure. An executable DSL that is platform-independent and message-based is described in [9]. In [10] chapter 10 discusses using Ontology Architectural Patterns in order to achieve semantic enterprise interoperability. III. SCENARIO DESCRIPTION To test our approach, we have chosen to recreate an existing integration solution. The scenario is part of a project management portal. The portal is designed to query a web service in order to get data about projects, tasks, etc. However, some legacy data is stored in a SAP system. An integration solution is therefore needed that will expose a web service. Upon getting a Simple Object Access Protocol (SOAP) request for that service it should fetch data from SAP and then wrap the data in a SOAP response. Data is retrieved from the SAP system by placing a Business Application Programming Interface (BAPI) call to a function. A schematic view of the scenario is shown in Fig. 1. The existing solution was manually coded in Java and uses Hibersap 1 for mapping data from SAP to an object model. It is being executed in the SAP Process Integration 1 A library for mapping Java classes to SAP backend via annotations, http://hibersap.org ICIST 2015 5th International Conference on Information Society and Technology Page 257 of 522