Web Service Semantics - WSDL-S

Amit Sheth

for theWSDL-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

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

…………<xs:element name= "processPurchaseOrderResponse" type="xs:stringwssem:modelReference="POOntology#OrderConfirmation"/></xs:schema></types><interface name="PurchaseOrder"><wssem:category name= “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:precondition name="ExistingAcctPrecond"wssem:modelReference="POOntology#AccountExists"><wssem:effect name="ItemReservedEffect"wssem:modelReference="POOntology#ItemReserved"/></operation></interface>

PurchaseOrder.wsdls

7

WSDL-S evolution

Action Attribute for Functional Annotation

Pre and Post Conditions

Can use XML, OWL

or UML types

Extension

Adaptation

schemaMapping

8

WSDL-S Tool Support - Radiant

More tools available at IBM aphaWorks:

http://www.alphaworks.ibm.com/tech/wssem

9

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

10

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

11

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!

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

13

WSDL-S

<Operation>

<Input1>

<Output1>

Service Template

Operation:buyTicket

Input1:TravelDetails

Output1:Confirmation

Annotations

Publish

SearchSemantic UDDIOperation:

cancel Ticket

Input1:TravelDetails

Output1:Confirmation

WSDL-S : scope, proposal and the bigger picture

Sivashanmugam, K., Verma, K., Sheth, A., Miller, J., Adding Semantics to Web Services Standards, ICWS 2003

<Operation>

<Output1>

Web service 1

<Input1>

<Operation>

<Output2>

Web service 2

<Input2>

Composition

14

Annotating message types - simple correspondences

<wsdl:types> (...)

<xs:element name= "processPurchaseOrderResponse" type="xs:string (...)</wsdl:types>

Billing

AccountOrderConfirmation

xsd:string

OWL ontology

has_account

has_accountID

WSDL message element

1:1 Correspondences<xs:element name= "processPurchaseOrderResponse"

type="xs:string wssem:modelReference="POOntology#OrderConfirmation"/>

results_in

semantic match

15

Annotating message types - complex correspondences

<wsdl:types> (...) <complexType name=“Address"> <sequence> <element name=“StreetAd1“ type="xsd:string"/> <element name=“StreetAd2" type="xsd:string"/> ........... </sequence> </complexType> (...)</wsdl:types>

Address

StreetAddress

xsd:string

xsd:string

OWL ontology

hasCity

hasStreetAddress

hasZip

WSDL complex type element

1. modelReference to establish a semantic association

2. schemaMapping to resolve structural heterogeneities beyond a semantic match

semantic match

16

Using modelReference and schemaMapping

<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

xsd:string

xsd:string

xsd:string

OWL ontology

has_City

has_StreetAddress

has_Zip

WSDL complex type element

• 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

17

• 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

dueDate

ItemDesc

Quantity

OWL ontology

hasIemDesc

hasDueDate

hasQuantity

WSDL complex type element

Using modelReference and schemaMapping

18

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

xsd:string

xsd:string

xsd:string

OWL ontology

has_City

has_StreetAddress

has_Zip

WSDL complex type element

.... <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>....

Mapping using XSLT