1 / 17

Web Service Semantics - WSDL-S

Web Service Semantics - WSDL-S. Amit Sheth for the WSDL-S team R. Akkiraju * , J. Farrell * , J.Miller, M. Nagarajan, M. Schmidt * , A. Sheth, K. Verma LSDIS Lab, University of Georgia and IBM “Web Service Semantics - WSDL-S”, W3C Member Submission, November 2005

wesley-wallace
Télécharger la présentation

Web Service Semantics - WSDL-S

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 Semantics - WSDL-S Amit Sheth for the WSDL-S teamR. Akkiraju*, J. Farrell*, J.Miller, M. Nagarajan, M. Schmidt*, A. Sheth, K. Verma LSDIS Lab, University of Georgia and IBM “Web Service Semantics - WSDL-S”, W3C Member Submission, November 2005 http://www.w3.org/Submission/WSDL-S/

  2. Existing problems for WS Vendors • Key objectives of Web services (WS) • Easy integration of distributed components • XML schema based description of data • Allow reuse of components • Tooling support for easily converting components to WS • Current problems • Integration is difficult; even selection is difficult • XML schema alone does not resolve schema level heterogeneities, not provide semantics of elements • Not adequate documentation of WS • Interface level and textual definitions may not be enough for effective discovery, selection, reuse, invocation

  3. Why use WSDL-S • Build on existing Web Services standardsusing only extensibility elements • Mechanism independent of the semantic representation language (though OWL is supported well) • WSDL-S provides an elegant solution • Help integration by providing mapping to agreed upon domain models (ontologies, standards like Rosetta Net, ebXML) • Better documentation by adding functional annotation • Ease in tool upgrades • e.g. wsif / axis invocation

  4. Semantic annotations on WSDL elements • Annotating message types (XSD complex types and elements) • extension attribute : modelReference(semantic association) • extension attribute : schemaMapping(schema/data mapping) • Annotating operations • extension elements : precondition and effect(child elements of the operation element) • extension attribute : category(on the interface element) • extension attribute : modelreference (action) (on operation element) * Also supported in other proposals (eg, OWL-S, WSMO)

  5. PurchaseOrder.wsdls ………… <xs:element name= "processPurchaseOrderResponse" type="xs:string wssem:modelReference="POOntology#OrderConfirmation"/> </xs:schema> </types> <interface name="PurchaseOrder"> <wssem:categoryname= “Electronics” taxonomyURI=http://www.naics.com/ taxonomyCode=”443112” /> <operation name="processPurchaseOrder” pattern=wsdl:in-outmodelReference= "rosetta:#RequestQuote" > <input messageLabel = ”processPurchaseOrderRequest" element="tns:processPurchaseOrderRequest"/> <output messageLabel ="processPurchaseOrderResponse" element="processPurchaseOrderResponse"/> <!—Precondition and effect are added as extensible elements on an operation> <wssem:preconditionname="ExistingAcctPrecond" wssem:modelReference="POOntology#AccountExists"> <wssem:effectname="ItemReservedEffect" wssem:modelReference="POOntology#ItemReserved"/> </operation> </interface>

  6. WSDL-S evolution Action Attribute for Functional Annotation Extension Adaptation Can use XML, OWL or UML types schemaMapping Pre and Post Conditions

  7. WSDL-S Tool Support - Radiant More tools available at IBM aphaWorks: http://www.alphaworks.ibm.com/tech/wssem

  8. W3C Charters Proposed • Semantics for Web Services Characterization Group Charter • Primary objective to gather use cases and suggest further activity • Recognizes WSDL-S as an important input • Charter of the Semantic Annotations for WSDL Working Group • Primary objective to use WSDL’s extensibility mechanism to add more information to data definitions in WSDL • Also, recognizes WSDL-S as an important input

  9. Conclusions and The Next Steps • Simplicity is the always the key for adoption • WSDL-S may be the evolutionary solution for some real problems – reuse and interoperability • Although preliminary work and prototyping is completed, more work needs to be done • Use cases • Tooling support • Greater adoption by vendors

  10. Q&A • How can the complexity of the current SWS approaches be reduced to help gain some wider adoption? After all, the primary goal of the SWS efforts is to facilitate the usage of Web services. • Focus on Reuse and Interoperability, and consequently Annotation and Mapping first. • 2.        Is a folksonomy-type approach a better, more realistic, alternative to adding semantics to Web services? • Not if money and business contracts are involved. • 3.        Should the SWS community take a pragmatic approach to adding semantics to Web services by heavily leveraging and extending the existing Web services stack as was done with WSDL-S? Or, is that a flawed approach since it inherits any limitations of the stack? • Don’t swim against the flow! • 4.        Should the SWS community agree on some basic standards and help extend and improve the current Web services stack? And what are advantages and disadvantages? • Yes. Do not fight business (investment in human capital and tools) and technology at the same time. • 5.        What are some of the low-hanging fruits that the SWS community should strive for first and progressively address the vision questions? What are some basic use-cases (e.g., semi-automated Web services usages with human in the loop and automated Web services usages via software agents)? • Walk before you run. Show semi-autonomic approaches work before advocating fully automatic approaches. • 6.        Should SWS ontology annotation be limited to OWL-type, FOL DL-type languages? Or, should we look into adopting other languages for ontology/taxonomy constructions, e.g., UML? • Need to support what industry needs. Always be open to other options while giving clear solution for one language. • 7.        Can formal approaches like FLOWS, which provides complete semantics of processes, help the implementation of use cases and achieve results that demonstrate clear advantages for businesses over well accepted languages like BPEL? What are some example use cases that show these advantages? Or should such formal approaches instead leverage and extend languages like BPEL? • Is the more important issue of data handled (focusing on control/flow won’t solve the problem). • 8.        What have we learned from current efforts that should drive the SWS roadmap? • One step at a time!

  11. Backup slides Lot more information at WSDL-S resource page: http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/ Also see W3C SWS proposed charters

  12. <Operation> <Input2> <Output2> Web service 2 <Operation> <Input1> <Output1> Web service 1 WSDL-S : scope, proposal and the bigger picture WSDL-S Composition Operation: buyTicket Input1: <Operation> TravelDetails Output1: <Input1> Confirmation Semantic UDDI Operation: Search <Output1> cancel Ticket Input1: Service Template TravelDetails Publish Output1: Confirmation Annotations Sivashanmugam, K., Verma, K., Sheth, A., Miller, J., Adding Semantics to Web Services Standards, ICWS 2003

  13. Annotating message types - simple correspondences semantic match 1:1 Correspondences <xs:element name= "processPurchaseOrderResponse" type="xs:string wssem:modelReference="POOntology#OrderConfirmation"/> <wsdl:types> (...) <xs:element name= "processPurchaseOrderResponse" type="xs:string (...) </wsdl:types> Billing has_account results_in OrderConfirmation Account has_accountID xsd:string WSDL message element OWL ontology

  14. Annotating message types - complex correspondences semantic match • modelReference to establish a semantic association • schemaMapping to resolve structural heterogeneities beyond a semantic match <wsdl:types> (...) <complexType name=“Address"> <sequence> <element name=“StreetAd1“ type="xsd:string"/> <element name=“StreetAd2" type="xsd:string"/> ........... </sequence> </complexType> (...) </wsdl:types> Address hasStreetAddress StreetAddress hasCity xsd:string hasZip xsd:string WSDL complex type element OWL ontology

  15. Using modelReference and schemaMapping • modelReference at the complex type level • Typically used when specifying complex associations at leaf level is not possible • Allows for specification of a mapping function semantic match <complexType name="POAddress“wssem:modelReference="POOntology#Address”wssem:schemaMapping=”http://www.ibm.com/schemaMapping/POAddress.xq#input-doc=doc(“POAddress.xml”)”> <all><element name="streetAddr1" type="string" /> <element name="streetAdd2" type="string" /> <element name="poBox" type="string" /><element name="city" type="string" /> <element name="zipCode" type="string" /><element name="state" type="string" /><element name="country" type="string" /><element name="recipientInstName" type="string" /> </all></complexType> Address has_StreetAddress xsd:string has_City xsd:string has_Zip xsd:string WSDL complex type element OWL ontology

  16. Using modelReference and schemaMapping • modelReference at the leaf levels • assumes a 1:1 correspondence between leaf elements and domain model concepts <complexType name="POItem" > <all> <element name="dueDate" nillable="true" type="dateTime" wssem:modelReference=”POOntology#DueDate”/> <element name="qty" type="float" wssem:modelReference=”#POOntology#Quantity”/> <element name="EANCode" nillable="true" type="string" wssem:modelReference=”POOntology#ItemCode”/> <element name="itemDesc" nillable="true" type="string" wssem:modelReference=”POOntology#ItemDesc” /> </all> </complexType> Item hasDueDate dueDate hasIemDesc ItemDesc hasQuantity Quantity WSDL complex type element OWL ontology

  17. Representing mappings <complexType name="POAddress" wssem:schemaMapping=”http://www.ibm.com/schemaMapping/POAddress.xsl#input-doc=doc(“POAddress.xml”)”> <all><element name="streetAddr1" type="string" /> <element name="streetAdd2" type="string" /> <element name="poBox" type="string" /><element name="city" type="string" /> <element name="zipCode" type="string" /><element name="state" type="string" /><element name="country" type="string" /><element name="recipientInstName" type="string" /> </all></complexType> Address has_StreetAddress xsd:string has_City xsd:string has_Zip xsd:string WSDL complex type element OWL ontology Mapping using XSLT .... <xsl:template match="/"> <POOntology:Address rdf:ID="Address1"> <POOntology:has_StreetAddress rdf:datatype="xs:string"> <xsl:value-of select="concat(POAddress/streetAddr1,POAddress/streetAddr2)"/> </POOntology:has_StreetAddress > <POOntology:has_City rdf:datatype="xs:string"> <xsl:value-of select="POAddress/city"/> </POOntology:has_City> <POOntology:has_State rdf:datatype="xs:string"> <xsl:value-of select="POAddress/state"/> </POOntology:has_State>....

More Related