Transcript A Botom-Up Approach to Automating Web Services

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
1
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
2
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
3
Running Example
Questions:
– How are the service
partners
•
•
•
•
Selected?
Ordered?
Invoked?
Integrated?
– UserPrefs?
4
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)
5
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.
6
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
7
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
8
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
9
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
10
Architecture
Interaction flow between BPWS4J, SDS, DQL
server, and discovered service partners
The website http://ksl.stanford.edu/sds however does not (yet?)
provide a prototype.
11
Automated Semantic Translation
• authors propose a simple recursive search
algorithm with (similar to planning, I would
say) to determine a an appropriate servicechain 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)
12
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.
13
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?
14