1 / 27

Combining Query and Preference – An Approach to Fully Automatize Dynamic Service Binding

This paper presents an approach to fully automate the dynamic binding of services by combining query and preference, enhancing efficiency and robustness in business processes.

phart
Download Presentation

Combining Query and Preference – An Approach to Fully Automatize Dynamic Service Binding

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. IEEE International Conference on Web Services (ICWS 2004) San Diego, CA, July 6-9, 2004 Combining Query and Preference – An Approach to Fully Automatize Dynamic Service Binding Michael KleinInstitute for Program Structures and Data Organization Universität Karlsruhe, Germany Birgitta König-RiesInstitute for Computer Science Technical University Munich, Germany DIANE Project http://www.ipd.uni-karlsruhe.de/DIANE/en

  2. Dynamic Service Binding Business Process Application Service C Service D Service A • Agile Networks • change inefficient or unavailable service providers on runtime •  Enhance efficiency and robustness Service B

  3. Matcher invoke [0..1] State of the Art • How is this typically achieved? • Attach service description to application and services • In case of a call, a matcher calculates similarity between request and all offers • Best offer is chosen and invoked Application Description of the desired service Description of the offered service Service B

  4. Difficulties EASY: • If descriptions are exactly equal: Matcher returns 1.0 • If descriptions are obviously different: Matcher returns 0.0 DIFFICULT: • In the common intermediate situations: • The offer differs somewhat from the request • What value in (0,1) is appropriate?

  5. Example for a Service Request :Service Service Request: I want a Service which books me a seat for Spider Man 2 presents :Profile :Booked effect entity price :CinemaTicket <= 8.00 validFor 2004-07-10 date spiderman2:Movie :SeatInShow visible 20:00 time cinema hortonPlaza:Cinema

  6. Example for a Service Offer :Service Service Offer: I can book you a ticket for Spider Man 2, this saturday at 8:15 pm in the Cinerama 6. presents :Profile :Booked effect entity :CinemaTicket validFor 2004-07-10 date spiderman2:Movie :SeatInShow visible 20:15 time cinema cinerama6:Cinema

  7. time :SeatInShow 20:00 The requestor wanted …but the offer can only book a ticket for 20:15. This is not ok, or is it? So assign 0.9? price :CinemaTicket <= 8.00 cinema The requestor wanted :SeatInShow hortonPlaza:Cinema The requestor wanted …but this information is missing in the offer. Return 0.0 and skip the service? Or just assign 0.5? Or 1.0? …but the offer can only book a ticket in the Cinerama 6. Is this ok? Say yes, because it‘s in the same city  Assign 0.8? Is it a Match? What is more important for the offerer: A good price, a good time, a near cinema?  Simply take the average, or the minimum, or…?

  8. Would you rely on such a matcher to select and execute a service automatically for you? automatically = you are not asked again  No! • But: It‘s not the matcher‘s fault • Even best matcher can only guess what is still ok for you and what deviation you are willing to accept

  9. Main Problem Main Problem Matcher does not know the preference/tolerance of the requestor. The Matcher • has to use general deviation heuristics • or is very conservative and only allows exact matchs • biased matching • often provides manyor no matching offers • Requestor has to choose manually or blindly rely on it.  Cannot or is not used for automatic service binding.

  10. FROM TO offers request offers Generic Matcher Personal Matcher creates request - generic - based on heuristics  biased - special - only based on the specified preferences  unbiased Our Approach • Tell the matcher exactly what the preferences are

  11. Preference-Containing Requests • Request != single instance describing the perfect service • But: Set of suitable services • degrees of membership from (0,1] determines preference for this service

  12. represents a set of movies Membership conditions are defined in a structured manner Movie Introduction of Object Sets Movie contains all existing movies spiderman2 represents one single movie

  13. Movie Double Defintion of an Object Set – Type Conditions Type Conditions • Limits the type of objects in the set • An object can only be member of the set, if it has exactly the given type Contains only Movie objects Contains only double values

  14. Movie Double Defintion of an Object Set – Direct Conditions Direct Conditions • Tests directly on the name or value of the object • An object can only be member of the set, if it fulfills the condition == spiderman2 < 8.00 Contains only one object: spiderman2 Contains only double values that are smaller than 8.00

  15. Movie Actor Duration Defintion of an Object Set – Property Conditions Property Conditions (only complex types) • Tests on attributs of the object • An object can only be member of the set, if it has the given attribut and its value is in the attached set mainActor == danielRadcliffe duration Contains all movies with mainactor danielRadcliffe and a Duration below 3 hours < PT180M

  16. CinemaTicket Double Missing Strategy Missing Strategy • Specifies the behavior in case of missing attributes • Possible values: assume_failed (–), ignore ( ), assume_fulfilled (+) price <= 8.00 Contains tickets that cost $8.00 or less. Tickets without a price specified are in the set too.

  17. Movie Actor Genre Connecting Strategy Connecting Strategy • Specifies how the single property conditions are connected • Possible value: expression from „and“ and „or“ of property conditions mainActor == danielRadcliffe mainActor or genre genre Contains movies with Daniel Radcliff as well as action movies and thrillers in {action, thriller}

  18. Movie Type Check Strategy Type Check Strategy • Weakens the type condition • Possible values: =, sub, super, sub[n], super[n] sub Contains objects of type Movie and of subtypes of Movies

  19. Set Definition – Summary <Type> tcs prop. condition Set direct conditions ms connection strategy

  20. Set Definition – Fuzzy Extensions <Type> tcs prop. condition Set direct conditions ms connection strategy assume_failed ignore assume_fulfilled assume_value[x] = sub super fsub fsuper … and or min max ws ^ … = in <= ~< ~= sim …

  21. Cinema Request (Revisited) Service presents Profile Booked effect entity Double price CinemaTicket ~<= 8.00 validFor Date date Movie SeatInShow == 2004-07-10 visible ==spiderman2 min(date, time^2, cinema, visible) time Time cinema Cinema ~< 20:00 <= 21:00 near(hortonPlaza)

  22. Unbiased Matching • Now: Unbiased Matcher • Matching = Calculating the membership value of the request set • Matcher exactly takes the preferences of the requestor into account  Personal Matcher •  Automatically gained matching result is accepted.

  23. Summary • Main Goal of Service Oriented Computing: Dynamic Service Binding • Up to now: Generic Matcher tests similarity between the offer instance and the request as perfect service instance •  Problem: Unknown preferences of the requestor in case of deviations •  Matcher uses heuristics and is biased •  Result is not accepted and must be postprocessed manually • Our Thesis: Tell the matcher exactly what the preferences are • Possible technique: Fuzzy object sets • Matching is test on set membership unbiased •  Result is accepted without further manual processing

  24. Further Work • Difficult for the requestor to adjust the conditions and strategies Guide user through process • Offer descriptions can contain variables. Is it possible to derive the assignment from the requestor‘s preferences?

  25. DIANE Project http://www.ipd.uni-karlsruhe.de/DIANE/en Thank you for your attention!

  26. APPENDIX

  27. Difference between Offer and Request • Offer description • Provider knows all details • possible to write down single instance • open parts can be specified as variables • Request description • needs a functionality • does not think of a certain service • several services can be suitable • has preferences among these suitable services •  Needs special request description language •  Possible to exactly define desired services

More Related