1 Dynamic Binding for BPEL Processes A Lightweight Approach to Integrate Semantics into Web Services Ulrich Küster and Birgitta König-Ries (also contains work by Michael Klein) University Jena Germany

2 WESOA06 - Chicago, Il, USA - December 2006 Introduction  SOC / web services as promising computing paradigm  loosely coupled distributed systems  combine heterogeneous systems, ease switching of components  Semantic Services  (semi-)automate time-consuming tasks (composition, selection, binding, …)  Leverage full potential of SOC  Semantic Services and Industry?  Lack of trust into reliability and correctness  Lack of comprehensive domain ontologies  high entry cost

3 WESOA06 - Chicago, Il, USA - December 2006 Goal  Provide approach for gradual transition to usage of semantic services in legacy systems  small steps, not all at once  lower entry cost  Explicitly encourage combined usage of semantics and standard technologies  combine strengths  Motivating running example

4 WESOA06 - Chicago, Il, USA - December 2006 COS-tec Computer Online Store

5 WESOA06 - Chicago, Il, USA - December 2006 What is DIANE and DSD?  DIANE project goal: Complete efficient automation of service discovery, matchmaking and invocation  Diane Service Descriptions (DSD)  Own lightweight ontology language  Specific elements for service descriptions  limited expressivity  intuitive modelling  efficient but precise matchmaking

6 WESOA06 - Chicago, Il, USA - December 2006 Characteristics of DSD (1)  Fixed state ontologies  to capture world altering effects (Owned, Known, Printed, Shipped, Accessible, …)  Domain ontologies  to describe service details (domain.location, domain.economy, domain.electronics, …)

7 WESOA06 - Chicago, Il, USA - December 2006 Characteristics of DSD (2)  Set-based declarative descriptions  Amazon sells millions of articles  Shipper provide transportation to a multitude of locations  Offer described as set of possible effects  Requests envision perfect service,  but accept deviations in details  Request described as set of acceptable effects  Standard semantics: One out of the described set of effects is requested / will be created

8 WESOA06 - Chicago, Il, USA - December 2006 Characteristics of DSD (3)  Preferences in request descriptions  fuzzy sets (the higher the membership, the higher the preference)  strategies (specify how to i.e. trade-off price versus shipping time, underspecified offers, …)  unbiased, deterministic, precise matching preferably 0 (preference 1.0), but up to 20 acceptable (linearly descreasing preference) Cargo requirements must be met, shipping time is more important than price…

9 WESOA06 - Chicago, Il, USA - December 2006 Characteristics of DSD (4)  Variables  Offer-In-Variables (configure offers / provide input)  Offer-Out-Variables (provide output)  Request-In-Variables (configurable request templates)  Request-Out-Variables (require output information) Input: German city Output: Complete address in that city

10 WESOA06 - Chicago, Il, USA - December 2006 Matching DSD-Descriptions  Given fuzzy request set r and configurable offer set o solve the following problem: a)Compute fuzzy containment value subset Є [0, 1] of o in r (How well is the offer contained in the requested effects?) b)Where possible, configure o such as to maximize subset  Implementation descends through description graphs, fills variables with optimal values, recursively computes subset for each element, combines subset values according to strategies

11 WESOA06 - Chicago, Il, USA - December 2006 Integration architecture

12 WESOA06 - Chicago, Il, USA - December 2006 From BPEL to DSD Requests  Main problem: data mediation necessary, lightweight mapping from legacy COS-tec xml to DSD (and from DSD to legacy xml of shipper)  Solved by specifying mapping rules in service description's groundings

13 WESOA06 - Chicago, Il, USA - December 2006 XmlDsdMapping  empty XML message deployed at middleware  DSD variable used to fill message  variables identified by unique variable name  variable attributes specified by path to attribute  xml node specified using XPath  Marshalling/Unmarshalling  standard serialization/deserialization available  custom serialization can be plugged in  Nested mappings used to handle (nested) lists  Example

14 WESOA06 - Chicago, Il, USA - December 2006 XmlDsdMapping Example... mapping += anonymous XmlDsdMapping [ variable = $cargo, dataNodePath = "package" attributeMappings += anonymous XmlDsdAttributeMapping [ attributePath = "weight/val", subNodePath = "weight" ], attributeMappings += anonymousXmlDsdAttributeMapping [ attributePath = "dimension/length/val", subNodePath = "length" ],... ], mapping += anonymous XmlDsdMapping [ variable = $price, dataNodePath = "maximumPrice", converterClassName = "MaxPriceConverter", converterMethodName = "convertToPriceDescription" ],...

15 WESOA06 - Chicago, Il, USA - December 2006 Integration architecture

16 WESOA06 - Chicago, Il, USA - December 2006 Execution process  Receive template name and parameters  Lifting: Use xml to fill request template  Matchmaking: find and configure best matching offer  Send offer inputs to provider-side middleware  Lowering: Create xml invocation message  Lifting: Extract return parameters  Return parameters to client-side middleware  Lowering: Create xml reply message  System has been implemented and tested.  Elaborate scenario including selection, binding and invocation of a shipping service has been peer-reviewed within Semantic Web Services Challenge 2006 (

17 WESOA06 - Chicago, Il, USA - December 2006 Summary  Goal: gradual transition to usage of semantic services in legacy systems  in particular support fully dynamic selection and binding  Presented lightweight integration of semantic requests into BPEL processes by  leveraging previous work on semantic service descriptions and matchmaking  providing easy to use, yet flexible data mediation mechanism

18 WESOA06 - Chicago, Il, USA - December 2006 Thank you for your attendance! Questions? Ulrich Küster DIANE project (services in ad hoc networks)

19 WESOA06 - Chicago, Il, USA - December 2006 Example shipping offer service instance offered effect(s)

20 WESOA06 - Chicago, Il, USA - December 2006 Example shipping request service instance requested effect(s) preferrably 0 but up to 20 accepted

21 WESOA06 - Chicago, Il, USA - December 2006