1 / 20

Web Service Brokerage using Semantic Web Technologies

Web Service Brokerage using Semantic Web Technologies. By Janaka Liyanage. Why Semantics?. WSDL & UDDI based on XML syntax

tilly
Download Presentation

Web Service Brokerage using Semantic Web Technologies

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. Web Service Brokerage using Semantic Web Technologies By Janaka Liyanage

  2. Why Semantics? • WSDL & UDDI based on XML syntax • If the supplier publishes a service to sell “Published Documents” and a user wants to buy “Books” and do a search on “Books” he will not get a hit. No way to define the relationships between terms

  3. Semantic Web • Current Web based on syntax (HTML) • The proposed Semantic Web based on semantics (RDF & RDFS & OWL) and is an extension to the current one • Semantic Web out of research labs now

  4. Semantic Web • Current Web – for humans • Semantic Web –for computers • Agents – programs that collect Web content from diverse sources, process the information and exchange the results with other programs. • Distributed approach to knowledge representation: URIs used to uniquely identify meanings given to terms and to locate definitions • “Properly designed, the Semantic Web can assist the evolution of human knowledge as a whole”

  5. OWL (Ontology Web Language) • RDF based on triples (subject, predicate, object) • RDFS introduces the notion of classes • OWL introduces: • Ontologies (explicit specification of a conceptualization) which are used to organize knowledge (classes and properties) into domains • Logic OWL Classes <owl:Class rdf:ID="Region"/> Definig an instance of a class <Region rdf:ID="Asia"/> Definig a sub class of Region <owl:Class rdf:ID=“Country"> <rdfs:subClassOf rdf:resource="#Region"/> </owl:Class>

  6. Classes & Properties <owl:ObjectProperty rdf:ID="locatedIn"> <rdf:type rdf:resource="&owl;TransitiveProperty" /> <rdfs:domain rdf:resource="&owl;Thing" /> <rdfs:range rdf:resource="#Region" /> </owl:ObjectProperty> Everything (including a region itself) located in some region <Region rdf:ID="Sri Lanka"> <locatedIn rdf:resource="#Asia"/> </Region> <Region rdf:ID="Colombo"> <locatedIn rdf:resource="#Sri Lanka"/> </Region> Can infer that Colombo is located in the Asia region

  7. Semantic Web Services (SWS) • Designed to overcome the problems with conventional web services, by integrating semantic markup into web services descriptions • Agents being able to make sense of the capabilities and how to invoke these SWS • Two approaches OWL-S and WSMO • OWL-S is the W3C recommended and widely accepted

  8. OWL-Services (OWL-S) • A set of OWL ontologies to describe a web service • Service is the central class which represents a SWS • A SWS may correspond to zero or more conventional web services

  9. Service Profiles • Describes capabilities, requirements, publisher information, QoS and optionally the category • Describes the inputs, outputs, preconditions and effects (IOPE) of a service. • These details of the service are described using the ServiceProfile class’s properties hasInput, hasOutput, hasPrecondition and hasResult respectively • Allows capability based discovery of web services, rather than keyword based searching as in UDDI

  10. Sample IOPEs of Services A process for confirming a reservation of a seat <profile:Profile rdf:ID="ConfirmReservation"> <profile:hasInput rdf:resource="#ReservationID_In"/> <profile:hasInput rdf:resource="#Confirm_In"/> <profile:hasOutput rdf:resource="#SeatNum_Out"/> <profile:hasOutput rdf:resource="#ReservationID_Out"/> <profile:hasEffect rdf:resource="#HaveSeat"/> </profile:Profile> <process:Input rdf:ID="ReservationID_In"> <process:parameterType rdf:resource="&concepts;#ReservationNumber"/> </process:Input> <process:Effect rdf:ID="HaveSeat"> <process:ceEffect rdf:resource="&concepts;#HaveFlightSeat"/> </process:UnConditionalEffect>

  11. Service Models • A class called Process, describes how the underling service(s) works • Divides processes into 2 categories • AtomicProcess: corresponds to the actions a service can perform by a single interaction. An AtomicProcess directly executes a single underlying web service, and thus should contain a mandatory instance of ServiceGrounding. • CompositeProcess: is a process which is composed of atomic or other composite processes. A CompositeProcess should define the execution and data flow paths between its constituting processes, using the control constructs: Sequence, Split, Split + Join, Choice, Any-Order, Condition, If-Then-Else, Iterate, Repeat-While, and Repeat-Until.

  12. Service Grounding • Tying together a WSDL description and a OWL-S description of a service • So that OWL-S service can be executed • Inputs & outputs of Atomic Processes are mapped to the WSDL message parts • XSL transforms used to convert OWL types to WSDL types

  13. Web Service Brokers • An ideal brokerage system should contain • Automatic service discovery • Automatic service composition • Automatic mediation • No current broker with all this functionality • Either implements partial functionality or requires human intervention • E.g. OWLS-MX, XPlan, CMU OWL-S Broker

  14. My Brokerage System Three parties of the system A possible composition plan generated by broker Booking a seat to travel COL to NY in the cheapest route Executes four services sequentially and iteratively

  15. Architecture • Used Java language • Apache Axis for creating and executing web services • Apache Tomcat server hosts the broker and provider services • Uses Jena API (by HP labs) to manipulate RDF & OWL data • Uses “Pellet” Inference engine for reasoning

  16. Implementation • Extended OWL-S specification to suit my requirements • Used RDQL queries to extract information from the knowledge base • Used a tool named WSDL2OWLS to generate skeleton OWL-S descriptions for the services • Used XSL transforms to convert OWL types to SOAP messages and vice versa

  17. Implementation Issues • SOAP marshalling for complex types (not standardized) • .NET web services and Java service not compatible – when coming to complex types • Lot of defects in tools and libraries (still in primitive stages) • WSDL2OWLS • had to correct bugs by modifying code • Jena API when processing to OWL • Had to find a workaround

  18. Demonstration • Demonstrating only the tip of the iceberg • “TcpTrace” to see the interaction between the provider and services • Uses the flight booking scenario to evaluate the prototype • Get all routes from a source airport to a destination • Get the minimum cost route from a set of routes • Book a seat in a flight route • Get the credit card details of a person given the bank

  19. Sample Composite Services • Sequential execution of services • Concurrent execution of services

  20. Thank You Any Questions?

More Related