The Dynamic Discovery of Web Services Using WSMX

Presented by Robert Zaremba

Requirements of Web Services in the B2B Domain Discovery

Web Service directories are not machine-understandable

Interoperability Differences in communication patterns that must be solved on the

semantic level

Composition Current Web Service composition languages cannot bind services

dynamically

Security and Reliability The complex interactions introduced by a reliance on Web Services

introduces security concerns

Web Service Modeling Ontology (WSMO)

Developed by the ESSI WSMO working group

Aims to enable the partial automation of the registration, discovery, and execution of Web Services

Incorporates semantic mark-up into all aspects of Web Services

Has its conceptual basis in the Web Service Modeling Framework (WSMF)

WSMO Design Goals Web Compliance Ontology-Based Strict Decoupling Centrality of Mediation Ontological Role Separation Description versus Implementation Execution Semantics Service versus Web Service

Top-Level Elements of WSMO Ontologies

Terminology used to describe the relevant domains to the WSMO elements

Web Services Computational entities which provide a service that has value in the

domain

Goals The functionality that is desired by the user

Mediators Handles various interoperability problems between elements

Web Service Modeling Language (WSML) Developed by the ESSI WSML working group, which is a part of

the ESSI WSMO working group

Is a formalization of WSMO

Has several variants with different levels of logical

expressiveness

Provides a framework to describe semantic Web Services

Avoids complex logical expressions

Adopts namespace and datatype concepts from XML

WSML - Ontologies

Ontologies may be imported Mediators resolve mismatches between imported ontologies Concepts are the basic elements from the problem domain Relations model interdependencies between concepts Functions allow for transformations of data Instances need not be specified; may link to an external store Axioms are logical expressions together with non-functional properties

Example of a WSML Ontology1 wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-flight"

2

3 namespace {_"http://www.example.org/Family#",

4 dc _"http://purl.org/dc/elements/1.1#"}

5

6 ontology Family

7 concept Human

8 hasParent inverseOf(hasChild) ofType Human

9 hasChild ofType Human

10 hasAgeInYears ofType (0 1) _integer

11

12 axiom DefinitionTeenager

13 nonFunctionalProperties

14 dc#source hasValue _"http://dictionary.reference.com/search?q=teenager"

15 endNonFunctionalProperties

16 definedBy

17 forall {?teen,?age} (

18 ?teen memberOf Teenager impliedBy

19 ?teen[hasAgeInYears hasValue ?age] memberOf Human and

20 ?age >= 13 and ?age =< 19).

WSML – Web Services

NonFunctionalProperties include QoS, Accuracy, Owner, etc. Ontologies are imported to provide the vocabulary of the Web Service

specification ooMediators can be used to resolve conflicts between imported Ontologies wwMediators resolve incompatibilities when interacting with other Web

Services Capability describes the functionality provided by the Web Service including

necessary preconditions, assumptions, postconditions, and effects Interface describes the choreography and orchestration of the Web Service

WSML - Goals

Ontologies may be imported ooMediators are used to resolve conflicts in imported

Ontologies ggMediators allow for the reuse and refinement of an

existing goal Capability describes the requested functionality

An Example Goal

WSML - Mediators

Ontologies may be imported Source specifies the WSMO element that will be transformed Target is the WSMO element that receives the mediated

element A mediation service is a service that will provide the

mapping

Web Service Execution Environment (WSMX) Developed by DERI International under SDK cluster

Is a reference implementation of WSMO

An implementation is available from http://www.wsmx.org/ Implemented in Java Runs its own micro-kernel Provides a HTTP GUI as well as support for SSH Exposes Mbean interfaces for the management of components Currently lacks documentation

WSMX Architecture

Components have well-defined interfaces Components may be separated by network(s) Communication is event-based

Adapter Outside of WSMX Transforms incoming messages to WSMX format Handles mismatches on the communication layer

Compiler Validates WSML documents Used in all operations

Matchmaker Matches Web Services to Goals Input: set of registered Web Services and the requester’s

Goal Output: set of Web Services that match the Goal

Data Mediator Maps source ontology to target ontology Based on ooMediator from the WSMO specification Provides design-time component for analyzing ontologies and

creating mappings for run-time use

Choreography Engine Uses Mediators to compensate for communication pattern

mismatches Generates dummy acknowledgement messages and can group and

reorder messages Choreography rules are created at design-time and stored

Communication Manager Handles invocations from requesters Invoke Web Services and retrieve the results back to WSMX Data needed for invocation must be in XML format

Other Components WSMX Manager coordinates the other components Resource Manager provides access to the persistence components Composition component will handle complex service compositions Security component will handle security aspects

Web Service Registration

1) The WSML description of the Web Service is defined in the editor

2) The Communication Manager handles the actual invocation

3) The Compiler checks the syntax of the WSML document

4) The WSML document is added to the repository

Web Service Discovery

1) The Adapter converts the request into a WSML Goal

2) The Communication Manager receives the invocation

3) The Compiler checks the syntax of the WSML document

4) The Matchmaker selects Web Services that match the Goal, using the Data Mediator if necessary

Web Service Invocation1) The requestor specifies the Web Service and

provides an Ontology instance, not necessarily in WSML format

2) The Adapter ensures that the request is in WSML format

3) The requester’s Communication Manager sends the Ontology instance and Web Service to the Choreography Engine and Compiler

4) The Choreography Engine mediates the communication between the Communication Managers while the Compiler verifies that the documents are syntactically correct

5) The provider’s Communication Manager converts the required data into XML format, using the Data Mediator when necessary

6) The service provider provides the service, returning data if necessary either synchronously or asynchronously

My Impressions

WSML is easy to understand and use

HTTP GUI simplifies the management of the components

It incorporates support for Apache’s Axis, a popular free Web Service design and deployment platform

Requires an understanding of J2EE’s Java Management Extensions (JMX)

The lack of documentation is a problem

Sources A. Haller, E. Cimpian, A. Mocan, E. Oren, C. Bussler: WSMX - A Semantic Service-Oriented

Architecture, in Proceedings of the International Conference on Web Service (ICWS 2005). Orlando, Florida, 2005.

M. Zaremba, C. Bussler: Towards Dynamic Execution Semantics in Semantic Web Services, In Proceedings of the Workshop on Web Service Semantics: Towards Dynamic Business Integration, International Conference on the World Wide Web (WWW2005). Chiba, Japan, 2005.

Dumitru Roman, Uwe Keller, Holger Lausen, Jos de Bruijn, Rub�n Lara, Michael Stollberg, Axel Polleres, Cristina Feier, Christoph Bussler, and Dieter Fensel: Web Service Modeling Ontology, Applied Ontology, 1(1): 77 - 106, 2005.

K. Verma, A. Mocan, M. Zaremba, A. Sheth, J. A. Miller: Linking Semantic Web Service Efforts, In Proceedings of the ICWS 2005 Second International Workshop on Semantic and Dynamic Web Processes (SDWP 2005). Orlando, Florida, 2005.

D16.1v0.21 The Web Service Modeling Language WSML. Retrieved on March 22, 2007 from http://www.wsmo.org/TR/d16/d16.1/v0.21/#cha:wsml-basic-syntax

Questions?