1 / 14

Adapting BPEL4WS for the Semantic Web

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. Overview.

deepak
Télécharger la présentation

Adapting BPEL4WS for the Semantic Web

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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?

More Related