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. http://www.ksl.stanford.edu/people/sam/iswc2003sam-djm-FINAL.pdf

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 Interaction flow between BPWS4J, SDS, DQL server, and discovered service partnersserver, and discovered service partners

The website http://ksl.stanford.edu/sds 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?