1 Adapting BPEL4WS for the Semantic Web The Bottom-Up Approach to Web Service Interoperation Daniel J. Mandell and Sheila McIlraith Presented by Axel Polleres cf.

2 Overview Bottom-Up approach to Web service interoperation Motivating example BPEL4WS and automated Web service execution The Semantic Discovery Service (SDS) and automated Web service discovery, customization, and semantic translation

3 Bottom-Up Approach XLANG, BPML, WSFL, WSCL, or finally BPEL4WS are still a long way from seamingless interoperability of Web This paper presents an aproach to integrate SemWeb technologies (particularly OWL-S) on top of BPEL4WS+BPWS4J wrt. – Discovery – Customization – Semantic translation – (Composition, not really) Bottom-up: build on BPEL instead of grounding OWL-S directly to WSDL

4 Running Example Questions: – How are the service partners Selected? Ordered? Invoked? Integrated? – UserPrefs?

5 BPEL4WS - Automatic Execution WS modelled as business processes, based on workflow modelling Traditional control structures such as if, then, else and while-loop The communication layer is described in WSDL (partners, variables, fault handlers)

6 BPWS4J implements a subset of BPEL4WS a BPEL4WS file and a WSDL interface as input provides a single endpoint for accessing a BPEL4WS process as a WS prohibiting dynamic service/partner binding! (in the current implementation)  only offers automatic execution of hard-wired composition of fixed web services, no discovery.

7 Restrictions on BPEL4WS itself process descriptions are not declarative, purely syntactic. Problem: syntactically matching WSDL interface might not match semantically and vice versa  Approach: “plug-in” Semantic Discovery Service

8 Automated, Customized, Service Discovery with SDS To alleviate shortcomings in BPEL4WS / BPWS4J, introduce a Semantic Discovery Service (SDS) to enable – automated service discovery – automated service customization – automated semantic translation Use Semantic Web technologies to enable description of services in computer interpretable format and discovery of services with desirable properties

9 Automated, Customized, Service Discovery with SDS Supporting technologies – DAML-S: A well-defined ontology based on DAML+OIL, used to describe services – DAML Query Language (DQL): Language and protocol used for querying repositories of DAML-S service profiles. DQL server interfaces with automated reasoner operating over knowledge base (KB) of DAML-S profiles – Java Theorem Prover (JTP): Hybrid reasoning system based on FOL model elimination. Use as DQL server’s automated reasoner

10 SDS: Approach Describe known services as DAML-S service profiles Store/query and reason about such descriptions: using DQL (query language, similar to QBE, OWL-”patterns” with variables: must-bind, may-bind and don't bind). Reasoner: JTP Integrate SDS as a “proxy”: The SDS enables automated service customization and semantic translation

11 Architecture Interaction flow between BPWS4J, SDS, DQL server, and discovered service partners The website however does not (yet?) provide a prototype.

12 Automated Semantic Translation authors propose a simple recursive search algorithm with (similar to planning, I would say) to determine a an appropriate service- chain of simple translator services in the knowledge base, by use of the DQL Server. Improvements, heuristics: – favoring services with few inputs/outputs or – based on distance functions between inputs/outputs (distance wrt. to the underlying ontology/taxonomy)

13 This is NOT Composition! BPEL4WS as such is not suitable for composition, since the composition (control flow) is already defined a priori and not declaratively. if the SDS would try to recompose it would REPLACE the framework rather than complementing it.

14 Discussion: oes the suggested architecture work also for any service description formalism such as WSMO, i.e. would our framework fit in here? In their "mediator-chain" search they do not really distinguish between mediators and services, why do we? an the proposed mediator-chain finding algorithm be improved by common AI planning techniques? not clear how the mediator-chain deals with SETS of outputs. Is the next service called for all or for some outputs only? How can this be extended to complex message patterns? The use case proposed is very simple, does this scale?