Using WSMX to Bind Requester & Provider at Runtime when Executing Semantic Web Services Matthew Moran, Michal Zaremba, Adrian Mocan, Christoph Bussler Digital Enterprise Research Institute {matthew.moran, michal.zaremba, adrian.mocan, WSMO Implementation Workshop Frankfurt, Germany, September 2004

Agenda The problem –Why runtime binding is good –Problem with current web service technology Requirements for a solution –Conceptual –Environment Proposed solution –WSMX and runtime binding –WSMX architecture and operation –Mediation Wrap-up –Related work –Summary

The Problem Ideal world –Businesses able to discover and bind to services at runtime –Issues of security, reliability, trust and interoperability of data, process and protocol automatically resolved Less ideal world –Businesses have trading partner agreements with multiple companies offering a wide variety of services –Business specify a requirement to be achieved and have that requirement satisfied by a service from one of these companies –Businesses don’t want to have to reprogram their systems each time a new service provider becomes known to them –Runtime binding of requester to provider

The Problem Current Web Service technology is syntactic –WSDL for service interface and binding description –UDDI registries for service descriptions written in free text Assumptions: –Shared understanding of terms used in WSDL –Shared understanding of terms used in UDDI Automatic stub generation is possible from WSDL but … –Code has to be written to invoke the stub for each service –Shared understanding assumption is made again for the meaning of the service input and output Positive aspect of current Web Services –Programming language independent e.g. Service in Java, requester in Lisp

Requirements Semantic descriptions of various aspects of Web Services needed –Service capabilities: what a service can do –Requester goals: what a requester seeks –Mediators to bridge between goals and capabilities –Non-functional properties: aspects like security, reliability, pricing … Descriptions written in terms of ontologies No assumption that provider & requester use same ontologies –Mediators required to provide the bridge –Data mediation is the first step, process and protocol mediation to follow Computer systems must be able to precisely interpret and reason about the semantic descriptions

Requirements: Environment Be able to interpret the semantic descriptions Carry out the activities of: –Service discovery –Service selection –Mediation –Service invocation Should have a modular construction –Clear well defined interfaces shielding implementation details –As technology improves components can be upgraded or replaced without affecting the stability of the system Should provide access to a registry of service descriptions Overall enable a complete round trip from requester to provider

Solution: WSMX & Runtime Binding WSMX is a software framework that allows runtime binding of service requester and provider Requester provides semantic description of goal WSMX interprets the goal to: –Discover matching services –Select the service that best fits –Provide data mediation if required –Make the service invocation Based on the conceptual model provided by WSMO –Add-ons required for WSMXGoal, BusinessPartner, Preferences WSMX has a formal execution semantics –Describes how WSMX gets from requester goal to service invocation

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Architecture

Solution: WSMX Mediation

Solution: WSMX Discovery Based on matching of logical Goals with WS Capabilities Goals and capabilities have postconditions and effects. Capabilities additionally have preconditions and assumptions WSMX adds concept of conditional Web Service to capability Conditional WS1 Conditional WS2 WSMO Registry WSMX Matchmaker Possible Matches Network Goal Collection of WS Step 2 Step 3 Step 1 Step 4 Match requester

Solution: WSMX Implementation Event based component architecture Current status –Version 1 codebase implemented –Opensource at –Data mediation component implemented –Other component interfaces defined and partially implemented Main technologies used –Apache Tomcat and Apache Axis –Database – MySQL –Eclipse IDE and Ant as build tool

Wrap-up: Related Work IRS3 –Interoperable, slightly different focus BPEL4WS + DAML-S + SDS –Bottom-up approach –Not clear how the discovery works Meteor-S –Research into adding semantics to Web Services and publishing these in UDDI directories Biztalk –Services used in processes must be bound at design time

Wrap-up: WSMX Summary Runtime binding of requester and provider Conceptual model is WSMO with some add-ons End-to-end functionality for executing SWS Formal execution semantics Real implementation – demo later Open source code base at SourceForge Event driven component architecture Developers welcome – –

Wrap-up Questions?