Adapting BPEL 4 WS for the Semantic Web

Зарегистрируйтесь, чтобы просмотреть полный документ!

Adapting BPEL 4 WS for the Semantic Web The Bottom-Up Approach to Web Service Interoperation Daniel J. Mandell and Sheila Mc. Ilraith Presented by Axel Polleres cf. http: //www. ksl. stanford. edu/people/sam/iswc 2003 sam-djm-FINAL. pdf 1

Overview • Bottom-Up approach to Web service interoperation • Motivating example • BPEL 4 WS 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 BPEL 4 WS are still a long way from seamingless interoperability of Web • This paper presents an aproach to integrate Sem. Web technologies (particularly OWL-S) on top of BPEL 4 WS+BPWS 4 J 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? – User. Prefs? 4

BPEL 4 WS - 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

BPWS 4 J • implements a subset of BPEL 4 WS • a BPEL 4 WS file and a WSDL interface as input • provides a single endpoint for accessing a BPEL 4 WS 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 BPEL 4 WS 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 BPEL 4 WS / BPWS 4 J, 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 BPWS 4 J, 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! • BPEL 4 WS 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

Скачать презентацию Adapting BPEL 4 WS for the Semantic Web

7e80cbcb7f308067ed51543f8be665fa.ppt

Количество слайдов: 14