Creating Semantic Web Services with the Web Service Modeling Toolkit (WSMT) Mick Kerrigan, Adrian Mocan, Martin Tanler and Werner Bliem Digital Enterprise Research Institute (DERI), Leopold-Franzens Universit¨ at Innsbruck, Austria
[email protected]
Abstract. Semantic Web Services aim to reduce the human effort required to build Service Oriented Architectures by enabling machines to understand the function and interfaces of Web services through the addition of semantics; However to enable the adoption of Semantic Web Service technologies by business it is crucial that adequate tool support exists which supports the engineer of Semantic Web Services and Semantically enabled Service Oriented Architectures through the full life cycle. The Web Service Modeling Toolkit (WSMT) is an Integrated Development Environment for Semantic Web Services through the WSMO Paradigm. This paper describes how the WSMT provides the engineer with such support at each stage of the development process.
1
Introduction
Research into the Semantic Web aims to make the vast quantities of information available on the Web machine-understandable, by the use of ontologies to annotate Web content. Web services have machine-processable annotations that are well structured (using XML) and describe how to interface with these services; However these annotations are purely syntactic and not machineunderstandable, thus large amounts of human effort is required to build Service Oriented Architectures (SOA). Semantic Web Services (SWS) are the extension of ontologies to describe Web services such that a machine can reason about the functionality they provide, the mechanism to invoke them, and the data they expect as input and return as output. Using these additional semantic descriptions of Web services it is possible for many parts of the process of building Service Oriented Architectures to be automated. Most importantly service providers and service requesters can be dynamically bound together at runtime, rather than hardwired to one another at application design time. Such runtime binding involves tasks like service discovery, selection, composition, adaptation, mediation of both data and process, and invocation. In order to perform these tasks a rich conceptual model is required that can be used to describe a services functionality and interface, a requesters requirements, and the underlying data models used by each. The Web Service Modeling Ontology (WSMO)[2], formalized in the Web Service Modeling Language (WSML)[6], is such a conceptual model for describing Semantic Web Services.
Page 6
2
M. Kerrigan, A. Mocan, M. Tanler and W. Bliem
Using a Semantic Execution Environment (SEE) for WSMO, like the Web Service Execution Environment (WSMX)[3] or IRSIII[1], semantic descriptions of Semantic Web Services can be used to automate many parts of the process of building SOAs. However the process of creating these semantic descriptions is not a trivial task and without tool support many of the tasks that need to be performed by the engineer can be lengthy and involved, essentially discouraging the adoption of Semantic Web Service Technology by business. In this paper we describe the Web Service Modeling Toolkit (WSMT)1 [5] an Integrated Development Environment for Semantic Web Services that supports the engineer through the full life cycle of their semantic descriptions, from creation to deployment on a Semantic Execution Environment. The rest of the paper is structured as follows, in section 2 we describe WSMO, WSML and Semantic Execution Environments in more detail. We then move on to describe the aims and goals of the WSMT, specifically mentioning the current tool support in section 3. In section 4 we go on to describe the process that the engineer would use to create, validate, test and deploy Semantic Web Services with the WSMT. Finally we provide some conclusions and future work in section 5.
2
Background
The Web Service Modeling Ontology (WSMO)[2] is a conceptual model for describing Semantic Web Services and provides four top level elements, namely Ontologies, Web Services, Goals and Mediators. Obviously WSMO Web Services are used to describe the function and interfaces of Web services, while WSMO Goals are used to describe the users requirements in terms of requested function and interface. The process of service discovery at runtime involves matching the WSMO Goal provided by the service requester against WSMO Web Services available from service providers. Ontologies act as the data model for all elements within WSMO, ensuring that unambiguous descriptions of services are available in a machine understandable manner. Finally, WSMO mediators can be used to resolve heterogeneity issues between Ontologies, Web Services and Goals. Mediators are essential as the Web is a diverse and highly changeable environment where consensus is very rarely reached. The Web Service Modeling Language (WSML)[6] is a formalization of the WSMO ontology, providing a language within which the properties of Semantic Web Services can be described. There are five language variants, based on Description Logic and Logic Programming. Each language variant provides different levels of logical expressiveness[6]. These variants are: WSML-Core, WSML-DL, WSML-Flight, WSML-Rule and WSML-Full. WSML-Core, which corresponds to the intersection of Description Logic and Horn Logic, provides the basis for all the variants, while WSML-Full unites the functionality of all variants. WSML Core is extended in the direction of more expressive Description Logic by WSMLDL and towards Logic Programming by WSML-Flight and WSML-Rule. This 1
Available for download from http://wsmt.sourceforge.net
Page 7
Creating Semantic Web Services with the WSMT
3
array of languages allows for services to be described in the most appropriate manner for the job at hand, with an obvious tradeoff in the selection of a language between language expressiveness and reasoning complexity. Of course mechanisms are needed to process and use these semantic descriptions in order to exploit the benefit of semantics. A Semantic Execution Environment (SEE) for Semantic Web Services can be used to bind service requesters and providers together at runtime using semantic descriptions of the requester’s goal and the provider’s Web service. SEEs provide functionality for discovering, selecting, adapting, composing, mediating, and invoking Web services that match the end users requirements. There are currently two Semantic Execution Environments for WSMO, namely the Web Service Execution Environment (WSMX)[3] and IRSIII[1]. Ongoing work in the OASIS Semantic Execution Environment Technical Committee2 aims to provide a standard reference architecture for SEEs based upon the WSMX and IRSIII efforts.
3
The Web Service Modeling Toolkit (WSMT)
The Web Services Modeling Toolkit (WSMT)[5] is an Integrated Development Environment (IDE) for Semantic Web Services implemented in the Eclipse framework. The WSMT aims to aid developers of Semantic Web Services through the WSMO paradigm, by providing a seamless set of tools to improve their productivity. An Integrated Development Environment (IDE) is defined as a type of computer software that assists computer programmers to develop software 3 . IDE’s like the Eclipse Java Development Toolkit (JDT)4 and NetBeans5 for developing java software have proven that good tool support can improve the productivity of engineers. It could be said that the time of ontology and Semantic Web Service engineers is a more precious commodity, as the number of people who are currently skilled in conceptual modeling is much less than those that can code in Java, thus underscoring the need for adequate tool support for such skilled engineers. The WSMT has three Eclipse perspectives, each grouping together editors and views related around a particular task: – The WSML perspective: Engineers can use the WSML perspective for the engineering of WSMO descriptions through the WSML formalism. This perspective provides multiple editors at different levels of abstraction (Text, Form and Graph based) for creating and maintaining semantic descriptions of WSMO Ontologies, Web Services, Goals and Mediators, along with full validation support providing inline realtime notification of errors as the user creates them. The reasoner view provides testing functionality for WSMO Ontologies by giving the engineer access to multiple underlying reasoners for 2 3 4 5
http://www.oasis-open.org/committees/tc home.php?wg abbrev=semantic-ex http://en.wikipedia.org/wiki/Integrated development environment http://www.eclipse.org/jdt/ http://www.netbeans.org
Page 8
4
M. Kerrigan, A. Mocan, M. Tanler and W. Bliem
WSML using the WSML2Reasoner6 framework. While the discovery view allows the integration of discovery engines from Semantic Execution Environments to test that Goals and Web Services match each other as expected. – The SEE perspective: The aim of this perspective is to reduce the effort of the engineer in performing maintenance and deployment tasks on Semantic Execution Environments. This perspective allows the engineer to take the semantic description they have created in the WSML perspective and register them with the SEE, alternatively the user can browse and check-out content from a given SEE in order to examine or edit these semantic descriptions. The SEE perspective also allows the engineer to access the entry points of the environment in order to invoke specific functionality. For example, the engineer can choose a given Goal from the workspace and invoke the achieveGoal 7 entry point to ensure the result of the invocation is as expected. – The Mapping perspective: This perspective is used to create ontology to ontology mappings. These mappings are crucial in resolving heterogeneity issues with respect to the data models used by the requesters Goal and the providers Web Service. These mappings can be registered with a SEE, which can then use these mappings at runtime to perform translation of ontology instances receiving from the requester into ontology instances expected by the provider. Ontology mediation is required as a one-world ontology will never exist and it must be possible to resolve heterogeneity issues that exist when two or more groups describe overlapping domains with different ontologies. In the WSMT we use a semi-automatic approach to mapping creation, in that the engineer is guided through the process of creating mappings using suggestions. While automatic approaches to mapping creation do exist, we believe that for real B2B integration the engineer must be involved in the mapping process to ensure a high accuracy of mappings.
4
Using the WSMT to create Semantic Web Services
The first step in the process of creating any semantic description is of course the use of a methodology for gathering requirements with respect to what needs to be modeled. The WSMT does not prescribe any given methodology for gathering requirements and conceptual modeling with WSML, but aims to provide generic tools that can slot into any process for conceptual modeling. Once the methodology has been chosen, a crucial step is obviously the creation of the first version of the semantic descriptions. As described in [5] we believe that users of different experience levels must be supported through the process of creating semantic descriptions. Thus we provide a number of different tools for creating and maintaining WSMO Ontologies, Web Services, Goals and Mediators through the WSML Perspective. The WSML Text Editor provides a low level editor 6 7
http://tools.deri.org/wsml2reasoner/ The achieveGoal entry point of a SEE will perform an end to end invocation of the Goal, from discovery through adaptation, selection, mediation and invocation of a given service or composition of services.
Page 9
Creating Semantic Web Services with the WSMT
5
where the engineer deals directly with the human readable syntax of WSML, this tool is particularly useful for those users who are already familiar and comfortable with the WSML syntax. The editor provides useful functionality like syntax highlighting and content completion to improve the users experience. The WSML Form based Editor is at higher level of abstraction providing a number of forms distributed over a number of tabs where the user can enter data that ultimately can be saved in WSML. Finally the WSML Visualizer[4] provides an integrated graph based approach to ontology engineering and visualization. The visualizer exposes complexities of the semantic descriptions to the engineer that may be missed in other editors and provides full editing support within the visualization. As the user is modeling their Ontologies, Web Services, Goals or Mediators the WSMT is validating these descriptions in real-time. Thus the user receives immediate feedback from the Eclipse Problems View and inline in the editors themselves as the engineer creates errors. This validation ensures that syntactic or structural mistakes are caught early in the process and do not linger until the user attempts to test or deploy their descriptions. Of course validity is only the tip of the iceberg in terms of testing. With respect to Ontologies the engineer can use the Reasoner View to perform test queries over the model. The reasoner view provides access to reasoners for both the logic programming and description logic branches of WSML through the WSML2Reasoner framework. For testing Web Services and Goals, the Discovery View provides access to a number of discovery engines so that the engineer can discover which Web Services in the workspace match a given Goal. The cycle of edit-validate-test continues until the engineer is happy that all the necessary modeling has finished and the descriptions behave as expected in the target reasoners and discovery engines. The engineer can now perform a deploy operation for each semantic description using the tools provided by the SEE Perspective. At this point it is possible for the engineer to perform live testing of the descriptions using the tools provided by the SEE perspective for executing SEEs. During live testing the engineer may find that some services use a different ontology for modeling domain knowledge and it may be necessary to create mappings between the ontologies created (or adopted) by the engineer, for describing his Web Service and Goals, in order to enable interoperation between his semantic descriptions and those of others. The Mapping Perspective follows the same approach as the WSML Perspective and provides editors at different levels of abstraction for creating mappings using the Abstract Mapping Language (AML)[8]. The AML Text Editor provides low level access to the XML syntax of the AML for editing descriptions, with similar features to the WSML Text Editor, for example syntax highlighting. The AML View based Editor[7] provides a graphical means to create mappings between ontologies. The user sees the source and target ontologies as trees and create mappings by choosing nodes in the source and the target. Real time validation is also available to the user in the editors and the Eclipse Problems View. The Mapping Perspective also contains the MUnit View which provides automated unit testing functionality
Page 10
6
M. Kerrigan, A. Mocan, M. Tanler and W. Bliem
for mappings. The user can define tests between the source and target ontologies and execute these tests as the mappings and underlying ontologies evolve to ensure that the mappings behave as expected. It will be possible to register mappings through the SEE perspective in the next version of the WSMT.
5
Conclusion
In this paper we have given a brief overview of the major functions of the Web Service Modeling Toolkit (WSMT) as an Integrated Development Environment for description Semantic Web Services through the WSMO paradigm and deploying them to Semantic Execution Environments. We believe that this effort to create a unified toolkit for Semantic Web Services will ease the ability with which business can adopt semantic technologies for Web services by reducing the overall cost of creating, validating, testing and deploying these descriptions. In terms of future work, firstly we aim to automate many of the testing tools available in the WSML Perspective. Automation of the tools in the Mapping Perspective has shown us that we can seriously reduce the effort of testing by providing the user with a mechanism for providing tests up front and being able to quickly and simply execute hundreds of tests with the click of a button. Also research will be performed on one area of SEE integration that currently lacks any tool support, namely the process of lifting and lowering XML data to and from ontologies. This research will lead to the development of tools for creating mappings between XML and WSML, enchancing the Mapping Perspective.
References 1. L. Cabral, J. Domingue, S. Galizia, A. Gugliotta, B. Norton, V. Tanasescu, and C. Pedrinaci. IRS-III: A Broker for Semantic Web Services Based Applications. In Proc. of the 5th Int’l Semantic Web Conf (ISWC), 2006. 2. C. Feier, A. Polleres, D. Roman, J. Domingue, M. Stollberg, and D. Fensel. Towards Intelligent Web Services: The Web Service Modeling Ontology (WSMO). In Proc. of the Int’l Conf on Intelligent Computing (ICIC), 2005. 3. A. Haller, E. Cimpian, A. Mocan, E. Oren, and C. Bussler. WSMX - A Semantic Service-Oriented Architecture. In Proc. of the Int’l Conf on Web Services (ICWS), 2005. 4. M. Kerrigan. WSMOViz: An Ontology Visualization Approach for WSMO. In Proc. of the 10th Int’l Conf on Information Visualization, 2006. 5. M. Kerrigan, A. Mocan, M. Tanler, and D. Fensel. The Web Service Modeling Toolkit - An Integrated Development Environment for Semantic Web Services (System Description). In Proc. of the 4th European Semantic Web Conf (ESWC), 2007. 6. H. Lausen, J. de Bruijn, A. Polleres, and D. Fensel. WSML - A Language Framework for Semantic Web Services. In Proc. of the W3C Workshop on Rule Languages for Interoperability, 2005. 7. A. Mocan and E. Cimpian. Mapping creation using a view based approach. 1st Int’l Workshop on Mediation in Semantic Web Services (Mediate 2005), 2005. 8. F. Scharffe and J. de Bruijn. A language to specify mappings between ontologies. In IEEE Conference on Internet-Based Systems SITIS6, 2005.
Page 11
