Embed Size (px)
Citation preview
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,
chris.bussler}@deri.orgWSMO Implementation Workshop
Frankfurt, Germany, 28-29 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 Mediation
Data Base
Mapping Rules Creator
Rules Execution Environment
MappingsMappings
Mapping Rules
Source Instance
Target Instance
Source Ontology
Target Ontology
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
ConditionalWS1
ConditionalWS2
WSMO RegistryWSMX 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
http://sourceforge.net/projects/wsmx– 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
– http://www.wsmx.org– http://sourceforge.net/projects/wsmx
