talk papazoglou

Slide1: 

Planning for Services on Demand& & the service request language XSRL Mike P. Papazoglou INFOLAB, Tilburg University, & DIT, Trento Univ., The Netherlands/Italy email: mikep@kub.nl http://infolab.kub.nl/people/mikep

Service-oriented Architecture: 

Service-oriented Architecture

Slide3: 

Extended Service-oriented Architecture

e-Marketplace:Vertical Web-services: 

e-Marketplace:Vertical Web-services Customer Knowledge Product Knowledge Business Models & Processes e-Marketplace Customer Information Service Airline booking Service Travel Service Hotel booking Service Restaurant reservation Service Reservation Service Weather Service Standard Business Terminology

Collaborative Business Semantics: 

Collaborative Business Semantics Agreements required on the following: Meaning of terms Process definitions Syntax (common) Communication Layer (SOAP) Define vocabulary and processes Define contracts (SLAs) and standard interaction between collaborators within a community Requires ownership and support Map to the technology of the day (e.g., WSDL/BPEL)

e-Marketplaces & Planning 4WS: 

e-Marketplaces & Planning 4WS A serious challenge is to design a service request language for e-marketplaces that results in the generation of executable plans describing the sequence of actions to satisfy a user request. Plans should deal with non-deterministic effects of the business domain and the set of potentially executable actions may change during the course of planning (reactive plans) to deal with exogenous events, e.g., information supplied by the UDDI, and contingency plans that deal with uncertain outcomes of non-deterministic actions. Plans should be amenable to refinement and revision as new information is accumulated (via interaction with the user or UDDI) and as execution circumstances necessitate change.

XSRL & WS standards: 

XSRL & WS standards

Slide8: 

<XSRL> FOR $a in document(PkgTravelSegment.xml)//AirSegment [CarrierName = "Alitlaia"| "United Airlines" AND DepartureAirport = "NewYork" AND ArrivalAirport = "Rome" | "Venice" AND (Price <= 800 AND Price >=500) AND SeatQty = 3 AND ArrivalDate = "1 June, 2002" AND DepartureDate = "10 June, 2002"] RETURN <ArrivalAirport>{ $a/ArrivalAirport}</ArrivalAirport> <price>{ $a/price}</price> <ArrivalDate>{ $a/ArrivalDate}</ArrivalDate> <DepartureDate>{ $a/DepartureDate}</DepartureDate> <HotelList> { FOR $h in document (hotelReference.xml)//HotelReference [ChainHotel = "Hilton"] WHERE ($h/Area =$a/ArrivalAirport AND $h/HotelArrivalDate = $a/ArrivalDate + 1 AND $h/HotelDepartureDate = $a/DepartureDate -1) RETURN <HotelName>{ $h/HotelName }</HotelName> <HotelAddress>{ $h/HotelAddress }</HotelAddress> }</HotelList> <GOAL> <Then><Vital>receive_confirmation($a)</Vital> <Optional> receive_confirmation ($h)</Optional></Then> </GOAL> </XSRL> XSRL definition

Slide9: 

UDDI XSRL parser BPEL sub-schema (created incrementally) XSRL-goal Services on-demand require interleaving of planning & execution High-level view of the XSRL framework

Slide10: 

Web-service definitions-interface Web-service providers Web-service access UDDI Planner XML input Schemas XML return Schemas Business Process Specifica- tion Domain Model in BPEL e-Marketplace return XML-schema compliant plan instances XSRL-goal plans

Slide12: 

UDDI Domain Model (BPEL) Plan acceptance Plan revision Plan action sequence PLANNER XML domain schemas Business Process Specification XML return schemas fail XSRL request Executed plan in BPEL

Slide13: 

UDDI Business Process specification Service Broker requests repository service fingerprint & binding info. service request return values port type operations find_tModel( ) get_tModel( ) service return details Model Based Planner

Wrapping it up: XSRL extensions: 

Wrapping it up: XSRL extensions There are a number of additional features to further enhance the usability and expressive power of XSRL: Distinguish between different types of goals and sequencing preferences, e.g., it should be possible not only to state that a goal is vital or that it is optional but also to express an explicit ordering of goals based on personal preferences The language could be enriched with similarity operators. There are three levels at which such semantic operators can work: at the constraint objects level: a user could specify that they want something similar to a compact car (topology), or some location close to a given city (proximity), and so on; at the service level: a user could specify that they wants something functionally similar to a specific service, e.g., we may choose to replace a train service by a plane service; at the plan level: a user could specify a goal similar to an already successfully executed plan, e.g., make a trip similar to the one the user has previously done.

A Final Remark: 

A Final Remark More info. on XSRL & other SOC publications, e.g., service compositions, transactions, P2P services can be found in: http://www.uvt.nl/infolab/pub/db/