150 likes | 257 Views
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 Description. Service Provider. Bind SOAP. Publish.
E N D
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 Description Service Provider Bind SOAP Publish (WSDL, UDDI) Service Registry Service Requester (client) Find (WSDL, UDDI) Service Description Service-oriented Architecture
Market maker Service operator Mana-gement Role actions performs • Market • Certification • Rating • SLAs Managed services publishes uses • Operations • Assurance • Support becomes Composition Composite services • Coordination • Conformance • Monitoring, Verification • QoS Service provider Basic services Description & Basic Operations • Capability • Interface • Behavior • QoS • Publication • Discovery • Selection • Binding Service client Service aggregator Extended Service-oriented Architecture
e-Marketplace:Vertical Web-services Travel Service Customer Information Service Restaurant reservation Service Business Models & Processes Product Knowledge Customer Knowledge e-Marketplace Airline booking Service Weather Service Standard Business Terminology Reservation Service Hotel booking Service
Agreements required on the following: Meaning of terms Process definitions Syntax (common) Communication Layer (SOAP) Definevocabulary 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) Collaborative Business Semantics
A serious challenge is to design a service request language for e-marketplaces that results in thegeneration of executable plans describing the sequence ofactions to satisfy a user request. Plans should deal with non-deterministiceffects of the business domain and the set of potentially executable actions maychange during the course of planning (reactive plans) to deal with exogenous events, e.g., informationsupplied by the UDDI, and contingency plans that deal with uncertain outcomesof non-deterministic actions. Plans should be amenable to refinement and revision as new information is accumulated (via interaction with theuser or UDDI) and as execution circumstances necessitate change. e-Marketplaces & Planning 4WS
XSRL WS-Transaction UDDI BPEL4WS WSDL SOAP XSRL & WS standards
<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) ANDSeatQty = 3 AND ArrivalDate = "1 June, 2002" ANDDepartureDate = "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
High-level view of the XSRL framework BPEL Standard Process definitions Planner XSRL-goal XSRL parser UDDI BPEL sub-schema (created incrementally) Services on-demand require interleaving of planning & execution
return XML-schema compliant plan instances XSRL-goal Web-service definitions-interface UDDI plans Planner Web-service access Business Process Specifica- tion Web-service providers XML input Schemas XML return Schemas e-Marketplace Domain Model in BPEL
User Application Travel Agent Tour Operator Dept. airport, arriv. airport, arriv. & dept. dates, nr. of seats Request document Plan Package Request Package Package Availability air-segment details Dept. airport, arriv. airport, arriv. & dept. dates, nr. of seats Create Alternative Packages send Package air-segment details Create Package air-segment details Request Booking credit card details Reserve Capacity Receive Invoice credit card details Evaluate Package invoice Send Invoice Reject Package Send Payment Accept Package Receive Payment payment authorisation Revise Package Receive Booking Reference Receive Confirmation Details booking reference Payment Refused Create Booking Entity voucher Responce document Send Confirmation Details
result serialization invoke UDDI-API Plan rejection XML domain schemas Business Process Specification XML return schemas XSRL request Domain Model (BPEL) Plan action sequence fail UDDI PLANNER Plan acceptance Plan revision Executed planin BPEL
XSRL Enquiry API Plan executor Business Process specification requests repository Service Broker port type operations service return details find_tModel( ) get_tModel( ) Model Based Planner service request return values service fingerprint & binding info. UDDI
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 bepossible not only to state that a goal is vital or that it is optionalbut 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 whichsuch semantic operators can work: at the constraint objects level: a user could specifythat they wantsomethingsimilar to a compact car (topology), or some location close toa 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 atrain service by a plane service; at the plan level: a user could specify a goal similarto an already successfully executed plan, e.g., make a trip similar to the one the user haspreviously done. Wrapping it up: XSRL extensions
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/ A Final Remark