A Bottom-Up Approach to Automating Web Service Discovery, Customization, and Semantic Translation

observancecookieΑσφάλεια

5 Νοε 2013 (πριν από 4 χρόνια και 1 μήνα)

70 εμφανίσεις

A Bottom
-
Up Approach to
Automating Web Service
Discovery, Customization,
and Semantic Translation

Dan Mandell and Sheila McIlraith

Knowledge Systems Lab

Stanford University

ESSW 2003

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


Summary: contributions, future directions

A Bottom
-
Up Approach


Web services long
-
term goal: seamless
interoperation between programs and devices


Industry provides standards, computing
infrastructure, and recently choreography
models akin to work in
process modeling


These include WSCI, BPML, XLANG, WSFL,
WSCL, WSFL, WSCL, BPSS, now BPEL4WS


Still far from seamless interoperation

A Bottom
-
Up Approach


In parallel, Semantic Web community developed
languages and computing machinery for
authoring and reasoning about unambiguous,
machine interpretable Web content


Efforts are based on AI technology, and include
RDF, RDF(S), DAML+OIL, DAML
-
S, and OWL


Though powerful, these efforts remain largely
disconnected from industrial standards and
infrastructure

A Bottom
-
Up Approach


We argue that:


Web Services must embrace representation and
reasoning ideas from Semantic Web community


Must also recognize evolutionary influence of industry
standards and machinery on Semantic Web services


From this viewpoint, we build on BPEL4WS


A leading process modeling framework


Co
-
authored by IBM, Microsoft, BEA, SAP, Siebel


Merges ideas from XLANG and WSFL


Integrate Semantic Web technology to enable
automated service discovery, customization, and
semantic translation

A Motivating Example


Consider integrating services to provide a
loan finding service:

A Motivating Example




Possible scenario:



A Motivating Example


Questions:


How are the service partners


Selected?


Ordered?


Invoked?


Integrated?

BPEL4WS
-

Automated
Service Execution


BPEL4WS


A BPEL4WS document


Provides notation for describing WS interactions as
business processes
, following in tradition of
workflow modeling


Integrates services by treating them as
partners

that fill
roles

in a
process model


Directs workflow using traditional control
constructs:
if, then, else, while
-
loop


Communication level params (e.g. service
partner bindings) are described in
accompanying WSDL docs

BPEL4WS
-

Automated
Service Execution


BPWS4J


Engine released by IBM alongside BPEL4WS


Implements subset of features defined in
BPEL4WS


Consumes a BPEL4WS doc along with
accompanying WSDL docs defining service
partner bindings to physical ports


Establishes a single endpoint for accessing
BPEL4WS process as a Web service

BPEL4WS
-

Automated
Service Execution


BPEL4WS and the loan example


A service provider writes a BPEL4WS doc
describing the loan finding process model
--

a
program that orchestrates interaction of the
service partners


BPEL4WS allows service partners to be
unbound to physical ports until runtime through
dynamic assignment of Service References


Current implementation of BPWS4J does not
implement Service Reference assignment, so
author selects service partners at design time

BPEL4WS
-

Automated
Service Execution


Critical analysis of BPEL4WS automation:


Limitations in BPWS4J


Service provider assigns partners
a priori


System cannot customize partner selection for each
user.


Loan finder example: user may wish to use in
-
state
lender to benefit from in
-
state tax incentives


If service provider defines lending partner prior to
receiving user’s request, the preference is ignored


Manual work means more responsibility and
maintenance time demands for service provider

BPEL4WS
-

Automated
Service Execution


Critical analysis of BPEL4WS automation:


Limitations in BPEL4WS


Relies on expressivity of XML / XML Schema


Interface
-
oriented: insufficient for automating many
tasks.


E.g., credit assessor for an ex
-
UK resident provides
UKCreditReport
s, while lending service comsumes
USCreditReport
s. Even if differ only in
representation of dates, failing to recognize their
semantic compatibility leaves a potentially
successful integration unrealized


Need service
-
oriented descriptions of service form
and function in an well
-
defined ontology language

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

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

Automated, Customized,
Service Discovery with SDS


Form and function of the SDS


Sits between a BPWS4J process and
potential service partners


Locates appropriate partners, acts as
dynamic proxy between them and BPWS4J

Automated, Customized,
Service Discovery with SDS


The SDS is portable between BPWS4J
actions and processes because it is:


Agnostic as to the content of the service
descriptions and invocation messages it
receives


Stateless, with no knowledge of prior
interactions or service
-
specific properties


The SDS enables automated
service
customization

and
semantic translation

Automated, Customized,
Service Discovery with SDS


Automated service customization:

Automated, Customized,
Service Discovery with SDS









Interaction flow between BPWS4J, SDS, DQL
server, and discovered service partners

Automated, Customized,
Service Discovery with SDS


Automated semantic translation


In the Web services context,
semantic
translation

means redefining well
-
defined data
types in terms of their relationships to each
other via translational axioms


Enables integration of service partners
operating on messages that differ syntactically
but are semantically translatable

Automated, Customized,
Service Discovery with SDS


Automated semantic translation


Uses translational axioms encoded as Web
services to integrate partner inputs and outputs


Uses a back
-
chaining algorithm to find
sequence of service invocations, or
service
chain

Automated, Customized,
Service Discovery with SDS


SDS and the loan example


Recall ex
-
UK resident seeking a loan from
an in
-
state lender


BPWS4J could not satisfy request given
the constraints


Lender located in user’s state


UKCreditReport

represents dates as
MM/DD/YYYY
, US version uses
DD/MM/YYYY


Automated, Customized,
Service Discovery with SDS


SDS and the loan example


With SDS, the request is satisfiable


Automated service customization: include DAML
-
S
restriction that lender partner be physically located in
the user’s state in request message


Automated semantic translation: back
-
chaining
algorithm inserts a
DateTranslator

translational
axiom:


DateTranslator

translates between
UKCreditReport

and
USCreditReport



Forms service chain (
Assessor

-
>
DateTranslator

-
>
Lender
) which can successfully complete request

Summary


Seamless interoperability is critical for
Web services to provide an infrastructure
for ubiquitous computing


Towards this goal, the bottom
-
up
approach brings Semantic Web
technology to industrial standards and
computing machinery

Summary


By integrating the SDS with BPEL4WS,
the industrial system gained the following
abilities:


Automatic, runtime binding of service partners


Selection between multiple service partners
based on user
-
defined constraints


Integration of service partners with
syntactically different but semantically
translatable service descriptions

Summary


To work towards seamless interoperation, it is
critical that:


Web service providers publish descriptions of
Web service form and function in a well
-
defined ontology language like DAML
-
S


Web service interoperation frameworks
embed semantic technology into their
systems and specificaitons that is capable of
reasoning about such descriptions

THANKS
-

Q/A