Extending ESB for Semantic Web Services ... - Springer Link

Extending ESB for Semantic Web Services Understanding Antonio J. Roa-Valverde and José F. Aldana-Montes Universidad de M´ alaga, Departamento de Lenguajes y Ciencias de la Computaci´ on Boulevard Louis Pasteur s/n 29071 M´ alaga Spain {roa,jfam}@lcc.uma.es http://www.lcc.uma.es

Abstract. The potential growth of applications distributed over a network and the large number of users has created the need for an infrastructure which can support increasing interaction not only among such users and applications but also an aplication to aplication interaction. This problem known as application integration has been addressed throughout time using different approaches such as Service Oriented Architecture (SOA), Enterprise Application Integration (EAI) and Web Services. The Enterprise Service Bus (ESB) draws the best traits from these and other technology trends. In this work, we propose the use of an ESB combined with Semantic Web technology with the aim of building an “intelligent” middleware which facilitates the Semantic Web Services life cycle and the deployment of new computation resources over the architecture.

1

Introduction

Nowadays, ESB has become the most promising solution to build a SOA infrastructure from several heterogeneous sources. Moreover, there are a lot of projects and work being carried out by researchers in the area of Semantic Web Services. However, many of those works have focused on the search for a suitable technology to model traditional Web Services applying the acquired knowledge in the Semantic Web. Proof of this fact can be seen in the number of proposals submitted to the W3C1 . Although there is not an official standard for modelling Semantic Web Services we believe that developed approaches must be put in practice. In this way it is possible to use Semantic Web Services in conjunction with an ESB to overcome the problem of enterprise integration. The use of the Semantic Web Services technology in enterprises would not be possible without the existence of an infrastructure that allows covering the life cycle of Web Services using semantic annotation techniques. This necessary infrastructure could be an ESB, which would facilitate the integration of various heterogeneous systems. An ESB allows the cooperation and the exchange of data between services. It is a logical architecture based on the principles of 1

http://www.w3.org/2002/ws/swsig/

R. Meersman, Z. Tari, and P. Herrero (Eds.): OTM 2008 Workshops, LNCS 5333, pp. 957–964, 2008. c Springer-Verlag Berlin Heidelberg 2008

958

A.J. Roa-Valverde and J.F. Aldana-Montes

SOA, which aims to define services explicitly and independently of the implementation details. It also pays close attention to securing a transparent location and excellent interoperability. An ESB makes Web Services, XML, and other integration technologies immediately usable with the mature technology that exists today. The core tenets of SOA are vital to the success of a pervasive integration project, and are already implemented quite thoroughly in the ESB. The Web Service standards are heading in the right direction, but remain incomplete with respect to the enterprise-grade capabilities such as security, reliability, transaction management, and business process orchestration. The ESB is based on today’s established standards in these areas, and has real implementations that are already being deployed across a number of industries. The ESB is quite capable of keeping in step with the ongoing evolution of the Web Services equivalents of these capabilities as they mature [1]. It would be interesting to maintain these capabilities over the use of Semantic Web Services. In this paper we propose the implementation of an infrastructure composed of different layers where the ESB is the foundation on which the others are based. The objective is to define a Semantic Enterprise Service Bus (SESB), providing mechanisms to collect all these technologies together and acting as a layer to access services through the invocation paradigm based on goals. This idea relies on a combination of several standards from the field of Web Services and Semantic Web technologies within the ESB: SAWSDL [7], for creating semantically annotated descriptions of service interfaces, and OWL [8], for modelling relationships among deployable artifacts across the ESB and performing the integration process via DL reasoning. The remaining of this paper is structured as follows. In Section 2, we introduce the motivation that guides this work. In Section 3, we describe the two possible approaches to build a Semantic Enterprise Service Bus. We also show a schematic vision of both architectures. In Section 4 we summarize current trends that aim to extend the use of Semantic Web Services, and Section 5 discusses future work and concludes this paper.

2

Motivation

For several years many approaches to overcome the application integration problem have been proposed, i.e. CORBA2 , EAI, ESB, etc. Despite, these approaches relying on different technologies and mechanisms they share a common point of view: software engineers are responsible for understanding the different application specifications and coordinating them to build a more complex system. Figure 1 depicts the necessary process to deploy a solution using an ESB. This process consists of two phases. Firstly, the software engineer must create the configuration file used for the ESB to initialize listeners in the startup phase. In this way, the software engineer must know with a high level of detail the different applications that he/she wants to integrate, i.e. accepted inputs and 2

http://www.corba.org/

Extending ESB for Semantic Web Services Understanding

959

Fig. 1. Typical ESB usage

outputs, listener ports, protocols, etc. In the execution phase the ESB is ready to accept messages and transport them among applications using the information stored in the configuration file. As we can see, the entire process relies on the configuration file coded manually by the software engineer. Until today, proposals have been focused on providing a middleware to solve heterogeneity and communication problems among applications without taking into account information relative to the meaning of the data that these applications can process. So, a tool capable of processing this kind of information would be very helpful for software engineers. Our aim relies on applying this idea to Semantic Web Services. In this way, a tool like this could facilitate frequent tasks in this field such as service composition and discovery. The desired idea tries to avoid writing the configuration file manually. We can imagine a software engineer trying to integrate several Semantic Web Services with the aim of bulding a more complex service in a composition process. Ideally, the software engineer could introduce the required goal and the ESB would be able to create the configuration file in an automatic or semi-automatic way using the available semantic annotations (see Figure 2).

3

SESB Architecture

SESB aims at providing developers with a middleware that facilitates application integration tasks through Semantic Web Service technology. There are two different ways to build such infrastructure using an ESB. The first one uses the ESB as the basis layer for building the topology on which different components are deployed. The second one tries to extend the ESB adding a new module responsible for understanding the semantic annotations over the artifacts deployed on the ESB.

960


Fig. 2. SESB architecture

3.1

Building on the ESB

The first approach uses an ESB as platform to deploy different components that fulfill each process of the Semantic Web Services life cycle in an independent way. It means that there exists a component responsible for discovery, another component responsible for composition, etc. Each one of these components are deployed as different Web Services on the ESB. Therefore, the ESB acts as the mechanism that manages the communication and coordination processes among these components. Such architecture provides the user with the sensation of an existing semantic layer. Several works have used this approach. In [9] authors present what they have called a “semantic-based dynamic service composition and adaptation” framework. In this work, they have focused on the composition and execution processes. The composer uses WSML [10] descriptions of basic services to build more complex services using a backward-chaining reasoning method. Basically, the composition algorithm relies on looking for an appropiate set of services using the precondition and postcondition descriptions until the required goal is satisfied. If the goal has been fulfilled then an ordered list of basic services is later passed to the executor, in this case the ESB. INFRAWEBS3 is a European IST project in the 6th FP that also exploits this approach. The main objective of INFRAWEBS is the development of a set of tools which will help users to create, maintain and execute Semantic Web 3

http://www.infrawebs.org/


961

Services. The developed platform known as the Infraweb Integrated Framework (IIF) is WSMO [4] compliant and it relies on the Eclipse IDE. The system generated consist of loosely coupled INFRAWEBS units, with each unit providing tools and adaptable system components. Developers will be able to use these components to analyse, design and maintain WSMO-based Semantic Web Services throughout the whole lifecycle. Each set of tools is deployed within the ESB which is also considered an Infrawebs Unit. The IIF defines two distinctive (but linked) parts: a Design Time Phase and a Runtime Phase. The Design Time Phase consists of the tools involved during the design of Semantic Web Services (using the Eclipse IDE), whereas the Runtime Phase consists of those tools involved during the execution of Semantic Web Services (using the ESB). Some of the tools may of course be involved in both phases. This approach ensures that system users (whether developers or normal end-users) deal with the minimum (but complete) set of tools required. Furthermore, it also provides an environment which is focused on the specific needs of the users. The INFRAWEBS Integrated Framework acts as a middleware to intercommunicate components using Web Service technology, so this network of interconnected components constitutes a SOA. INFRAWEBS delegates to the ESB the management and execution of these components. The ESB will be also able to check if the components are alive or not. The components that INFRAWEBS defines are the following: – SWS-D (Semantic Web Service Designer): Responsible for the design of Semantic Web Service descriptions (in particular the capabilities of the Web Service descriptions), plus goals. – SWS-C (Semantic Web Service Composer): Responsible for the static composition of existing WSMO-based Semantic Web Services. – DSWS-R (Distributed Semantic Web Service Repository): Responsible for the persistent storage of WSMO-based descriptions and the registry and advertisement of the available services. – SIR (Semantic Information Router): Responsible for handling the formal descriptions (based on RDF) that are submitted in the service registration process. – OM (Organizational Memory): Represents an organizational memory and a case-based recommender tool. – SAM (Service Access Middleware): Responsible for guiding the user applications through the steps of semantic web service usage, including service discovery, selection and execution. – SWS-E (Semantic Web Service Executor): Responsible for executing the Semantic Web Service descriptions. – QoS-Monitor (Quality of Service Monitor): Responsible for collecting monitor data and calculate the metric values for the Semantic Web Service being executed. – Security components: Offer methods for ensuring and measuring trust values to the application providers. These methods are used by the end-users applications.

962

3.2


Extending the ESB’s Capabilities

ESB draws from traditional Enterprise Application Integration (EAI) approaches functionality in that it provides integration services such as data transformation, routing of data, adapters to applications and protocol conversion. The main difference between EAI and ESB relies on the use of propietary internal formats. The ESB is based on today’s established standards such as XSLT, WSDL, BPEL4WS, etc. This fact makes application integration not specific to each provider. Another feature that makes ESB attractive to users is that it exploits configuration more than codification. There is nothing wrong with writing code, but there is plenty of code to be written elsewhere that does not have to do with interdependencies between applications and services. In this work, our aim is to introduce semantic into the core of the ESB taking advantage of its features. The idea consists of adding semantic annotations to the different objects that the ESB can manage, such as transports, connectors or filters. Therefore, developing a component with such behaviour provides us with reasoning capabilities to the artifacts deployed on the ESB. In this way, we could use this information to facilitate several tasks in the Semantic Web Services life cycle such as the discovery and composition. Figure 2 depicts the architecture of the proposed SESB. As we explained in Section 2, SESB will be responsible for creating the logical path among required Web Services. To achieve this, we must start from a couple of assumptions: SESB uses available information stored as instances of an OWL-DL ontology which models the objects that the SESB can understand (filters, transports, endpoints, etc.); Web Services are annotated using SAWSDL to concepts in the ESB’s object ontology and concepts in a domain ontology. The startup phase begins when the user (the software engineer) introduces the required goal. Goals represents the user’s preferences and they will be introduced to the system using WSML. Therefore the developed tool will be WSMO compliant. After that, a parser processes the goal and sends the information to the reasoner. This component relies on the ESB’s object ontology and domain ontology to get information about suitable Web Services. The system generates a first version of the configuration file using the information provided by the reasoner. In this way, the user does not have to know low level details about Web Services. The SESB will be able to check the compatibility between different Web Services and ask the user for required code such as the creation of adapters to overcome the heterogeneity of inputs and outputs. The assistant is the component responsible for providing this functionality and completing the configuration file. This file can be stored in a repository for later use. When the configuration file is completed the configuration manager processes it and prepares the system to receive messages in the execution phase.

4

Related Work

The main challenge among researchers in the Semantic Web Service field lies in overcoming the technological gap between the use of syntactic technology and


963

semantic technology. As we can see, many R&D projects are ongoing with the aim of bringing semantics into SOA. In many cases, the goal of these projects is to build a platform enabling the use of Semantic Web Services (INFRAWEBS4 , WSMX5 , IRS-III6 ). These platforms cover the whole Semantic Web Service life cycle enabling discovery of services based on goals, composition, registry and mediation. The developed tools rely on a top-down design, i.e., they assume that users start with an ontology implementation from which Web Services will be annotated. In this way, the first step would be to specify goals, mediators and others semantic restrictions in order to build a semantic layer that Web Services will use. Despite being the most common way to begin a new project based on Semantic Web Service technology in the future, now it is not the most suitable way to evolve current SOA applications towards a Semantic SOA. The reason for this is that with a top-down design it is not possible to take advantage of the existing Web Services. Nowadays, a bottom-up design is necessary, which allows developers to re-use the existing applications and adapt them to the Semantic Web. At present, some researchers have noticed this necessity and have begun to provide solutions. In this sense, a first approach has been the recent recommendation of SAWSDL7 by W3C, after developing a mechanism to enable semantic annotation of Web Service descriptions in WSDL 2.0. SAWSDL is independent of the language used for the ontology description. This fact makes SAWSDL suitable for being combined with different approaches such as WSMO [4] or OWL-S [5] as we can see in the recent works in this field [6][3][2]. Current effort shows that researchers have become aware of the actual technological transition in SOA. In this sense, it is difficult to know when Semantic Web Services may be used among ICT enterprises without any limitation. For the moment, researchers should postpone the development of new platforms that cover the SWS life cycle focusing their effort on obtaining a solution to overcome the current transition problem between SOA and Semantic SOA. This last issue has contributed to the development of the described work.

5

Conclusion and Future Work

In this paper, we describe how to build a Semantic Enterprise Service Bus combining several technologies such as OWL, SAWSDL and SOA. This kind of tool allows software engineers to apply a bottom-up design to deploy a solution that relying on the Semantic Web Services approach. This is an ongoing project that aims to develop a platform to overcome the problems of the current SOA, i.e. finding the most suitable service for a certain requirement among thousands of different services or building a complex service from other simple services. We 4 5 6 7

http://www.infrawebs.org/ http://www.wsmx.org http://kmi.open.ac.uk/projects/irs/ http://w3.org/TR/sawsdl

964


are now focused on developing and improving some of the described components within the SESB. As future work we plan to validate the platform using a real use case. For that, we propose the development of adapters or wrappers over existing SOA applications as a future extension of the described work. These adapters will allow the application of a semantic layer over implemented Web Services which will be reusable in the proposed SESB. In this way, we expect to implement an automatic or semi-automatic tool to annotate Web Services using SAWSDL over concepts in an ontology. For that proposal, we have even considered evaluating and reusing an existing tool known as Radiant [11]. This tool will be incorporated into the SESB to facilitate the deployment of non-annotated Web Services.

Acknowledgements Supported by Grants CVI-267 (Junta de Andaluc´ıa), TIN2005-09098-C05-01 (Spanish Ministry of Education and Science), P07-TIC-02978 (Junta de Andaluc´ıa) and FIT-350503-2007-6 (Spanish Ministry of Industry, Tourism and Commerce: Plan Avanza)

References 1. Chappell, D.A.: Enterprise Service Bus. O’Reilly, Sebastopol (2004) 2. Kourtesis, D., Paraskakis, I.: Combining SAWSDL, OWL-DL and UDDI for Semantically Enhanced Web Service Discovery. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 614–628. Springer, Heidelberg (2008) 3. Paolucci, M., Wagner, M., Martin, D.: Grounding OWL-S in SAWSDL. In: Kr¨ amer, B.J., Lin, K.-J., Narasimhan, P. (eds.) ICSOC 2007. LNCS, vol. 4749, pp. 416–421. Springer, Heidelberg (2007) 4. Roman, D., et al.: Web Service Modeling Ontology. Applied Ontology 1(1), 77–106 (2005) 5. The OWL Services Coalition. OWL-S 1.1 Release (2004) 6. Vitvar, T., Kopecky, J., Viskova, J., Fensel, D.: WSMO-Lite Annotations for Web Services. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 674–689. Springer, Heidelberg (2008) 7. Farrell, J., Lausen, H. (eds.): Semantic Annotations for WSDL and XML Schema. W3C Recommendation (August 2007) 8. McGuinness, D.L., van Harmelen, F.: OWL Web Ontology Language Overview. W3C Recommendation (February 2004) 9. Hibner, A., Zielinski, K.: Semantic-based Dynamic Service Composition and Adaptation. In: IEEE SCW 2007, pp. 213–220 (2007) 10. de Bruijn, J., Fensel, D., Lausen, H.: D34v0.1: The Web Compliance of WSML. Technical report, DERI (2007), http://www.wsmo.org/TR/d34/v0.1/ 11. Gomadam, K., Verma, K., Brewer, D., Sheth, A.P., Miller, J.A.: A tool for semantic annotation of Web Services. In: Gil, Y., Motta, E., Benjamins, V.R., Musen, M.A. (eds.) ISWC 2005, vol. 3729, Springer, Heidelberg (2005)