Adapting BPEL4WS for the Semantic Web

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/iswc200
  3sam-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 BPEL4WSBPWS4J 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
  DAMLOIL, 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 servers 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 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?