1. 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.org WSMO Implementation Workshop Frankfurt, Germany, 28-29 September 2004

2. matthew.moran@deri.org2 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

3. matthew.moran@deri.org3 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

4. matthew.moran@deri.org4 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

5. matthew.moran@deri.org5 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

6. matthew.moran@deri.org6 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

7. matthew.moran@deri.org7 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

8. matthew.moran@deri.org8 Solution: WSMX Architecture

9. matthew.moran@deri.org9 Solution: WSMX Architecture

10. matthew.moran@deri.org10 Solution: WSMX Architecture

11. matthew.moran@deri.org11 Solution: WSMX Architecture

12. matthew.moran@deri.org12 Solution: WSMX Architecture

13. matthew.moran@deri.org13 Solution: WSMX Architecture

14. matthew.moran@deri.org14 Solution: WSMX Architecture

15. matthew.moran@deri.org15 Solution: WSMX Architecture

16. matthew.moran@deri.org16 Solution: WSMX Architecture

17. matthew.moran@deri.org17 Solution: WSMX Architecture

18. matthew.moran@deri.org18 Solution: WSMX Architecture

19. matthew.moran@deri.org19 Solution: WSMX Architecture

20. matthew.moran@deri.org20 Solution: WSMX Architecture

21. matthew.moran@deri.org21 Solution: WSMX Mediation

22. matthew.moran@deri.org22 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

23. matthew.moran@deri.org23 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

24. matthew.moran@deri.org24 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

25. matthew.moran@deri.org25 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.orghttp://www.wsmx.org –http://sourceforge.net/projects/wsmxhttp://sourceforge.net/projects/wsmx

26. matthew.moran@deri.org26 Wrap-up Questions?