Get documents about "Web Service Semantics - WSDL-S
Document Sample
Semantic Web Process Lifecycle:
Annotation, Discovery, Publication, and
Composition
Amit Sheth
Professor, University of Georgia
Director, LSDIS Lab
CTO/co-founder, Semagix
Semantics at Different Layers
Description Layer
Why:
Flow • Unambiguously understand the functionality of the services,
the semantics of input/output data, and QoS of services
Discovery How:
• Using Ontologies to semantically annotate WSDL
Publication constructs (conforming to extensibility allowed in WSDL
specification version 1.2/2.0)
– WSDL-S : Incorporates many types of semantics in
Description the service description
– Tools for (semi-)automatic semantic annotation of
Messaging Web Services (e.g., METEOR-S MWSAF)
Network Present scenario:
• WSDL descriptions are mainly syntactic (provides
operational information and not functional information)
• Semantic matchmaking is not possible
WSDL-S
<?xml version="1.0" encoding="UTF-8"?>
<definitions
name = "BatterySupplier"
targetNamespace = "http://lsdis.cs.uga.edu/meteor/BatterySupplier.wsdl20"
xmlns = "http://www.w3.org/2004/03/wsdl"
xmlns:tns = "http://lsdis.cs.uga.edu/BatterySupplier.wsdl20"
xmlns:rosetta = " http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/pips.owl "
xmlns:mep=http://www.w3. rosetta:PurchaseOrderStatusResponse org/TR/wsdl20-patterns>
<interface name = "BatterySupplierInterface" description = "Computer PowerSupply Battery Buy Quote Order
Status "
domain="naics:Computer and Electronic Product Manufacturing" > from
Function
<operation name = "getQuote" pattern = "mep:in-out" action = "rosetta:#RequestQuote" > Rosetta Net
<input messageLabel = ”qRequest” element = "rosetta:#QuoteRequest" /> Ontology
<output messageLabel = ”quote” element = "rosetta:#QuoteConfirmation" />
</operation>
<operation name = "placeOrder" pattern = "mep:in-out" action = "rosetta:#RequestPurchaseOrder" >
<input messageLabel = ”order” element = "rosetta:#PurchaseOrderRequest" />
<output messageLabel = ”orderConfirmation” element = "rosetta:#PurchaseOrderConfirmation" />
<exception element = "rosetta:#DiscountinuedItemException" /> Data from
<pre condition = " order.PurchaseOrder.PurchaseOrderLineItem.RequestedQuantity > 7" />
</operation>
Rosetta Net
<operation name = "checkStatus" pattern="mep:in-out" action = "rosetta:#QueryOrderStatus" > Ontology
<input messageLabel = ”statusQuery” element = "rosetta:#PurchaseOrderStatusQuery" />
<output messageLabel = ”status” element = "rosetta:#PurchaseOrderStatusResponse" />
<exception element = "rosetta:#OrderNumberInvalidException" />
</operation>
</interface>
</definitions>
Semantics at Different Layers (contd..)
Publication and Discovery Layers
Why:
Flow • Enable scalable, efficient and dynamic publication and
discovery (machine processable / automation)
Discovery
How:
Publication • Use federated registries categorized by domans
• Publish services based on domains
• Capture the WSDL-S annotations in UDDI
Description
Messaging Present scenario:
• Suitable for simple searches ( like services offered by a
Network provider, services that implement an interface, services
that have a common technical fingerprint, etc.)
• Categories are too broad
• Automated service discovery (based on functionality)
and selecting the best suited service is not possible
MWSDI
Registry
Federation
belongsTo
Federation belongsTo
Registry
supports
Ontology
Domain
consistsOf
subDomainOf
Semantics at Different Layers (contd..)
Flow Layer:
Why:
• Design (composition), analysis (verification), validation
Flow (simulation) and execution (exception handling) of the process
models
• To employ mediator architectures for dynamic composition, control
Discovery flow and data flow based on requirements
How: Using
Publication • Templates to capture semantics
(functionality/preconditions/effects/QoS) of the participating
services and for the process
Description • Knowledge of conversation patterns supported by the service
• Formal mathematical models like process algebra, concurrency
Messaging formalisms like State Machines, Petri nets etc.
• Simulation techniques
Network Present Scenario:
• Composition of Web services is static
• Dynamic service discovery, run-time binding, analysis and
simulation are not directly supported
Using Colored Petri nets
Semantic Web Processes and Services
(METEOR-S)
– Service Advertisements (WSDL-S)
• Functional Aspects (IOPE’s)
• Non functional Aspects (QoS ontology)
• Interaction Protocol (State Machine / Colored Petri nets)
• Semi-automatic annotation of WSDL
– Discovery of services (MWSDI)
• Subsumption based discovery
• Peer to peer network of UDDI Registries
– Composition (METEOR-S )
• Design time binding to BPEL along with optimization
Semantics in METEOR-S and WS stack
MWSCF: Semantic Web Process Composition
Flow Framework
Discovery MWSDI: Scalable Infrastructure of Registries for
Semantic publication and discovery of Web
Publication Services
Description MWSAF: Semantic Annotation of WSDL (WSDL-S)
Messaging
Network
METEOR-S at the LSDIS Lab exploits Workflow, Semantic Web, Web Services,
and Simulation technologies to meet these challenges in a practical and
standards based approach
http://swp.semanticweb.org, http://lsdis.cs.uga.edu/proj/meteor/swp.htm
WSDL-S
Based on Joint Technical Note with IBM
R. Akkiraju, J. Farrell, J.Miller, M. Nagarajan, M. Schmidt, A.
Sheth, K. Verma,
"Web Service Semantics -- WSDL-S," A joint UGA-IBM
Technical Note, version 1.0,
April 18, 2005.
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/
Adding semantics to WSDL – guiding
principles
• Build on existing Web Services standards
• Mechanism independent of the semantic
representation language
• Mechanism should allow the association of
multiple annotations written in different
semantic representation languages
Guiding principles...
• Support semantic annotation of Web
Services whose data types are described
in XML schema
• Provide support for rich mapping
mechanisms between Web Service schema
types and ontologies
WSDL-S approach
• evolutionary and compatible upgrade of existing
Web services standards
• describe semantics and operation level details in
WSDL - upward compatibility.
• externalize the semantic domain models -
agnostic to ontology representation languages.
WSDL-S Extension attributes and
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 construct)
– extension attribute : category
(on the interface construct)
– extension element : action (under consideration)
(on operation construct)
PurchaseOrder.wsdl
…………
<xs:element name= "processPurchaseOrderResponse" type="xs:string
wssem: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-out>
<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>
WSDL-S Annotator – snap shot
modelReference
Annotating operations
• extension element : Precondition
– A set of assertions that must be satisfied before a Web service operation can be
invoked
• ―must have an existing account with this company‖
• ―only US customers can be served‖
• extension element : Effect
– Defines the state of the world/information model after invoking an operation.
• ―item shipped to mailing address‖
• ―the credit card account will be debited‖
• extension attribute : Category
– Models a service category on a WSDL interface element.
• category = ―Electronics‖ Code = ―naics:443112‖
• extension element : Action
– Annotated with a functional ontology concept.
• action = ―Rosetta:purchaseOrder‖
Annotating message types – 1:1
correspondences
semantic match
<wsdl:types>
(...) Billing
<xs:element name= "processPurchaseOrderResponse" has_account results_in
type="xs:string
(...) OrderConfirmation
</wsdl:types> Account
has_accountID
xsd:string
WSDL message element OWL ontology
1:1 Correspondences
<xs:element name= "processPurchaseOrderResponse"
type="xs:string
wssem:modelReference="POOntology#OrderConfirmation"/>
Annotating input/output elements –
complex correspondences
semantic match
<wsdl:types>
(...) Address
<complexType name=“Address">
<sequence> hasStreetAddress
<element name=“StreetAd1“ type="xsd:string"/> StreetAddress
<element name=“StreetAd2" type="xsd:string"/>
........... hasCity
</sequence>
</complexType> xsd:string
(...)
hasZip
</wsdl:types>
xsd:string
WSDL complex type element OWL ontology
1. modelReference to establish a semantic
association
2. schemaMapping to resolve structural
heterogeneities beyond a semantic match
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‖ Address
wssem:schemaMapping=‖http://www.ibm.com/schemaMapping/POAdd
ress.xq#input-doc=doc(―POAddress.xml‖)‖>
has_StreetAddress
<all>
<element name="streetAddr1" type="string" /> xsd:string
<element name="streetAdd2" type="string" />
<element name="poBox" type="string" /> has_City
<element name="city" type="string" />
<element name="zipCode" type="string" /> xsd:string
<element name="state" type="string" />
<element name="country" type="string" /> has_Zip
<element name="recipientInstName" type="string" /> </all>
</complexType> xsd:string
WSDL complex type element OWL ontology
Alternative annotation
• modelReference at the leaf levels
– assumes a 1:1 correspondence between leaf elements and
domain model concepts
<complexType name="POItem" >
<all> Item
<element name="dueDate" nillable="true" type="dateTime"
hasDueDate
wssem:modelReference=”POOntology#DueDate”/>
<element name="qty" type="float" dueDate
wssem:modelReference=”#POOntology#Quantity”/>
<element name="EANCode" nillable="true" type="string" hasIemDesc
wssem:modelReference=”POOntology#ItemCode”/>
<element name="itemDesc" nillable="true" type="string" ItemDesc
wssem:modelReference=”POOntology#ItemDesc” />
</all> hasQuantity
</complexType>
Quantity
WSDL complex type element OWL ontology
Representing mappings
<complexType name="POAddress"
wssem:schemaMapping=”http://www.ibm.com/schemaMapping/POAddr Address
ess.xsl#input-doc=doc(“POAddress.xml”)”>
<all> has_StreetAddress
<element name="streetAddr1" type="string" />
<element name="streetAdd2" type="string" /> xsd:string
<element name="poBox" type="string" />
<element name="city" type="string" /> has_City
<element name="zipCode" type="string" />
<element name="state" type="string" /> xsd:string
<element name="country" type="string" />
<element name="recipientInstName" type="string" /> has_Zip
</all>
</complexType> 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>....
WSDL-S in perspective
Semantic Publishing and Template Based
Discovery
WSDL-S
Operation:
buyTicket
Input1:
<Operation>
TravelDetails
Output1:
Confirmation <Input1>
UDDI
Operation:
cancel Ticket Search <Output1>
Input1:
TravelDetails Service Template
Output1: Publish
Confirmation
Annotations
WSDL-S in the life cycle of a Web
services
... ...
<xs:complexType name="processPurchaseOrderRequest"> <xs:complexType name="processPurchaseOrderRequest―
<xs:element name="billingInfo" type="xsd1:POBilling"/> wssem:modelReference="POOntology#OrderDetails” >
<xs:element name="orderItem" type="xsd1:POItem"/> <xs:element name="billingInfo" type="xsd1:POBilling"/>
</xs:complexType> <xs:element name="orderItem" type="xsd1:POItem"/>
</xs:schema> </xs:complexType>
<operation name="processPurchaseOrder‖ pattern=wsdl:in-out> </xs:schema>
<input messageLabel = ‖processPurchaseOrderRequest" <operation name="processPurchaseOrder‖ pattern=wsdl:in-out>
element="tns:processPurchaseOrderRequest"/> <input messageLabel = ‖processPurchaseOrderRequest"
<output messageLabel ="processPurchaseOrderResponse" element="tns:processPurchaseOrderRequest"/>
element="processPurchaseOrderResponse"/> <output messageLabel ="processPurchaseOrderResponse"
... ... element="processPurchaseOrderResponse"/>
... Semantic Layer
WSDL <xs:complexType name="processPurchaseOrderRequest―
wssem:modelReference="POOntology#OrderDetails” >
Annotating a WSDL - S
<xs:element name="billingInfo" type="xsd1:POBilling"/>
<xs:element name="orderItem" type="xsd1:POItem"/> service
</xs:complexType>
</xs:schema>
<operation name="processPurchaseOrder‖ pattern=wsdl:in-out>
<input messageLabel = ‖processPurchaseOrderRequest"
element="tns:processPurchaseOrderRequest"/> Publishing a service
<output messageLabel ="processPurchaseOrderResponse"
element="processPurchaseOrderResponse"/>
... UDDI
WSDL - S
WSDL-S in the life cycle of a Web
process Process execution
An abstract Web process
<Operation>
<Operation> <Operation>
<Operation>
<Input1>
<Input1> <Input2>
<Input2>
<Output1>
<Output1> <Output2>
<Output2>
WSDL-S Web service 1
Service 1 Template Web service 2
Service 2 Template
WSDL-S
WSDL-S Web Service Discovery WSDL-S
modelReference modelReference
schemaMapping schemaMapping
Transformation
WSDL-S in action
• ProPreO - Experimental Proteomics
Process Ontology (CCRC / LSDIS)
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:ngp" data
……
xmlns:wssem="http://www.ibm.com/xmlns/WebServices/WSSemantics"
xmlns:ProPreO="http://lsdis.cs.uga.edu/ontologies/ProPreO.owl" >
<wsdl:types>
<schema targetNamespace="urn:ngp"
xmlns="http://www.w3.org/2001/XMLSchema">
…… sequence
</schema>
</wsdl:types>
<wsdl:message name="replaceCharacterRequest"
wssem:modelReference="ProPreO#peptide_sequence">
<wsdl:part name="in0" type="soapenc:string"/>
<wsdl:part name="in1" type="soapenc:string"/>
<wsdl:part name="in2" type="soapenc:string"/>
</wsdl:message> peptide_sequence
......
Excerpt: Bio-informatics Web service Excerpt: ProPreO – process ontology
WSDL
WSDL-S collaborations
• Collaboration with WSMO
– Using WSDL-S for grounding Web services
annotated with WSML ontologies
WSDL-S summary
• WSDL-S : A mechanism to associate
semantic annotations with Web services
that are described using WSDL
– Upward compatible, incremental approach
– WS community’s familiarity with WSDL
• External semantic models referenced via
extensibility elements
– agnostic to ontology representation languages
– Enables reuse of existing domain models
Semi-automatic Annotation (WSDL and
Ontologies)
Expressiveness
• Different reasons behind their development
– XML Schema used in WSDL for providing basic structure to data
exchanged by Web services
– Ontologies are developed to capture real world knowledge and
domain theory
• Knowledge captured
– XML Schema has minimal containment relationship
– Language used to describe ontologies model real world entities as
classes, their properties and provides named relationships
between them
Solution
• Use heuristics to create normalized
representation
• We call it SchemaGraph
Normalization – SchemaGraph
What is SchemaGraph ?
Normalized representation to capture XML Schema and DAML
Ontology
How to use SchemaGraph
• Conversion functions convert both XML Schema and Ontology
to SchemaGraph representation
– XML schema used by WSDL → W = {wc1, wc2, wc3, …, wcn}
where, wci is an element in XML schema and n is the number
of elements
– Ontology → O = {oc1, oc2, oc3, …, ocm} where, oci is a concept
in Ontology and m is the number of concepts
• Match function takes both W and O and returns a set of
mappings
MWSAF – XML Schema to
SchemaGraph
Rule XML Schema constructs SchemaGraph representation
1 Element, Node
2 simpleType Node
3 Enumeration values defined for Node with edge between simpleType
simpleType S S node and value node with name
―hasValue‖
4 ComplexType Node
5 Sub-elements of complexType C Node with edge between
which have range as basic XML complexType C node and this node
datatypes with name ―hasElement‖
6 Sub-elements of complexType C Edge between complexType C node
which have range as complexTypes and the range type node
or simpleTypes or elements defined
in same schema
MWSAF – XML Schema to SchemaGraph
- <xsd:complexType name="WeatherReport">
- <xsd:sequence>
<xsd:element name="phenomena" type="xsd1:Phenomenon" />
<xsd:element name="wind" type="xsd1:Wind" />
Rule 6
</xsd:sequence>
</xsd:complexType>
- <xsd:complexType name="Phenomenon">
- <xsd:sequence>
<xsd:element name="type" type="xsd1:PhenomenonType" />
<xsd:element name=“intensity" type="xsd1:PhenomenonIntensity" />
</xsd:sequence>
</xsd:complexType> Rule 1
- <xsd:complexType name="Wind">
- <xsd:sequence>
Rule 5 complextype => Node
<xsd:element name="gust_speed" type="xsd:double" />
<xsd:element name="prevailing_direction" type="xsd1:Direction" />
</xsd:sequence>
</xsd:complexType> WeatherReport
- <xsd:simpleType name="PhenomenonType">
- <xsd:restriction base="xsd:string">
Rule 1 wind
<xsd:enumeration value="MIST" /> phenomena
<xsd:enumeration value="FOG" />
simpletype => Node
<xsd:enumeration value=“SNOW" /> Wind
<xsd:enumeration value="DUST" /> Phenomenon
</xsd:restriction>
</xsd:simpleType> hasElement
prevailing_direction
type
intensity gust_speed Direction
PhenomenonType
Rule 1
Rule 3 oneOf PhenomenonIntensity
Element => Node
oneOf oneOf
oneOf
MIST FOG SNOW DUST
MWSAF - Ontology to SchemaGraph
Rule Ontology representation SchemaGraph representation
1 Class Node
2 Property of class D with basic Node with edge joining it to class D
datatype as range (Attribute) node with name ―hasProperty‖
3 Property of class D with other Edge between class D node and range
class R as range (Relation) class R node
4 Instance of class C Node with edge joining class C node to
instance node with name
―hasInstance‖
5 Class(X)-subclass(Y) relationship Edge between class X node and class Y
node with name ―hasSubclass‖
MWSAF - Ontology to SchemaGraph
- <daml:Class rdf:ID="WeatherPhenomenon">
<rdfs:comment>Superclass for all weather events</rdfs:comment> WeatherPhenomenon
<rdfs:label>Weather event</rdfs:label>
</daml:Class>
- <daml:Class rdf:ID="WindEvent">
<rdfs:subClassOf rdf:resource="#WeatherPhenomenon" /> WindEvent
</daml:Class>
- <daml:Property rdf:ID="windDirection">
<rdfs:domain rdf:resource="#WindEvent" /> Rule 1
</daml:Property>
- <daml:Class rdf:ID="GustingWindEvent">
windDirection Rule 5
<rdfs:subClassOf rdf:resource="#WindEvent" />
</daml:Class>
Rule 2 GustingWindEvent
- <daml:Class rdf:ID="CurrentWeatherPhenomenon">
<rdfs:subClassOf rdf:resource="#WeatherPhenomenon" /> CurrentWeatherPhenomenon
</daml:Class>
- <daml:Class rdf:ID="OtherWeatherPhenomena">
<rdfs:subClassOf rdf:resource="#CurrentWeatherPhenomenon" />
</daml:Class>
- <daml:Class rdf:ID="Duststorm">
<rdfs:subClassOf rdf:resource="#OtherWeatherPhenomena" /> OtherWeatherPhenomenon
</daml:Class>
- <daml:Class rdf:ID="PrecipitationEvent">
<rdfs:subClassOf rdf:resource="#CurrentWeatherPhenomenon" />
</daml:Class> Duststorm
- <daml:Class rdf:ID="SolidPrecipitationEvent">
<rdfs:subClassOf rdf:resource="#PrecipitationEvent" />
</daml:Class>
- <daml:Class rdf:ID="Snow">
<rdfs:subClassOf rdf:resource="#SolidPrecipitationEvent" /> PrecipitationEvent
</daml:Class>
- <daml:Class rdf:ID="ObscurationEvent">
<rdfs:subClassOf rdf:resource="#CurrentWeatherPhenomenon" />
</daml:Class> SolidPrecipitationEvent ObsucurationEvent
- <daml:Class rdf:ID="Fog">
<rdfs:subClassOf rdf:resource="#ObscurationEvent" />
</daml:Class>
- <daml:Class rdf:ID="Mist">
<rdfs:subClassOf rdf:resource="#ObscurationEvent" /> Snow Mist Fog
</daml:Class>
Semantic Web Service Discovery
in METEOR-S
METEOR-S Web Service Discovery
Infrastructure
Web Service
Discovery
Discovery new Requirements
Before Now
QoS
B3 A1
B3
B3 A1 B3 A1
A1
A1 A1
A1
Tasks B8 A4 A1 A4 A2
A1 A4 A2 A4 A1 A2
A1
A1 Web Services A2 A1 A2
A4 A1
B3
B3 A1
B3 A4 A1 A2
A5 B3
A1 A1 B3 A1
A1
A1 A4 A1 A1
A1 A4 A1 B3 A4 A1 A2
A1 A1 A1
A4 A1
A1 B3
A4 A6 A1 A1 A4 A1 A2 A1
A4 B3 A4 A1 A2
B3 A1 A1 A2 A4 A1 A2
A2 A4 A1 A2 A1A1 A1A1A1
A1
B3 A1
A2 A1 A1
A4 A1 A2
A1 A1 A1 A2
A2 A1 A4 A1 A1 A4A4 A1 A2
A4 B3A2 A2 A2
A4 A1A4
A2 A1 A1
A4 A1 A4 A1
B3 A1 A1A1 A1 A1 A4 A2 A4
B3 A4A1 A1 A2 B3
B3
A2 A2
B3 A4 A1 A1
A1 A1
B3 B3 A1 A1
A1 A1
A1
A4 A4 A1A2 A4 A1
A4 A2
B3 A1 A1 A2
A4
A1 A4 A1 A2 A2A4 A1 A1
A1 A2 A1A1 A1
A1
A4 A4 A1 A2
A1 A1
A1 A4
B3 B3B3 A1A1 B3
A1 A1
A1
QoS
Workflow
Web Process A N1 E N2 F
A N1 E N2 F
C D
C D
State of the art in discovery
UDDI Business Registry Results
Search
Keyword and
attribute-based
Provides non-semantic
match Search retrieves lot of
search
services (irrelevant
Selection results included)
Which service to select ?
How to select?
Semantic Discovery: Overview
• Annotation and Publication
– WSDL file is annotated using ontologies and the
annotations are captured in UDDI
• Discovery
– Requirements are captured as templates that are
constructed using ontologies and semantic matching is
done against UDDI entries
• Functionality of the template, its inputs, outputs, preconditions and
effects are represented using ontologies
• Use of ontologies
– brings service provider and service requestor to a common
conceptual space
– helps in semantic matching of requirements and
specifications
Semantic Publication and Discovery
Class
TravelServices Use of ontologies enables
subClassOf subClassOf shared understanding
Class
between the service provider
Class
WSDL and service requestor
Data Operations
subClassOf subClassOf subClassOf subClassOf
Class Class Class Class
Ticket Confirmation Ticket Ticket
Information Message Booking Cancellation
Operation:
buyTicket
Input1:
TravelDetails <Operation>
Output1:
Confirmation <Input1>
UDDI
Operation:
cancelTicket Search <Output1>
Input1:
TravelDetails Service Template
Output1: Publish
Confirmation
Annotations
For simplicity of depicting, the ontology is shown with classes for both operation and data
Adding Semantics to Web Services Standards
Present Discovery Mechanism Web Service
Discovery
Keyword and attribute-based search
• UDDI :Keyword and attribute-based search
• Example: ―Quote‖
– Microsoft UBR returned 12 services
– Human reading of description (Natural Language) help
me understand:
• 6 Entries are to get Famous Quotes
• 1 Entry for personal auto and homeowners quoting
• 1 Entry for multiple supplier quotes on all building materials
– Categorization suggested for UDDI is useful but
inadequate (what does the WS do?) :
• 1 Entry for Automobile Manufacturing
• 1 Entry for Insurance agents, brokers, & service
– Alternatively read and try to understand WSDL
• 1 Entry related to security details (Human Understanding)
• 1 Test Web service for Quotes (which quote?)
Discovery in Semantic Web Using
Semantics Web Service
• Functionality: What capabilities Discovery
the requestor expects from the
service (Functional semantics)
(Functional semantics)
• Inputs: What the requestor can (Data semantics)
give to the to the Web service (QoS semantics)
(Data semantics) (Syntactic description)
• Outputs: What the requestor
expects as outputs from the
service (Data semantics)
• Description:
• QoS: Quality of Service the Natural language
distributor expects from the description of the
service (QoS semantics) service
functionality
(Syntactic description)
Discovery
The Match Function
• The Web service discovery and integration
process is carried out by a key operation:
– The match function
• The matching step is dedicated to finding
correspondences between a service template
(ST, i.e., a query) and a service advertisement
(SO).
The Match Function
Semantic Similarity
• Purely syntactical methods that treat terms in
isolation from their contexts.
– It is insufficient since they deal with syntactic but not
with semantic correspondences
– Users may express the same concept in different ways.
• Therefore, we rely on semantic information to
evaluate the similarity of concepts that define
ST and SA interfaces.
• This evaluation will be used to calculate their
degree of integration.
The Match Function
0.76 SO2
0.14 SO1 SO3
0.31 0.68 Match Function
0.98 0.43
0.34 0.74 0.99
Conference Registry
Hotel Reservation
Service f(ST, SO1) f(ST, SO2) f(ST, SO3) Service
?
Date
Date
Duration
Duration
City
City
Conference
Get Itinerary
Itinerary
Conference
Start A Information
ST B End
Travel Hotel
User Name Reservation Reservation
Employee ID User Name
Address
Address
Get User
Information
Web Process
Discovery in SWS Web Service
Discovery
• Functionality: What capabilities
the distributor expects from the
service (Functional semantics)
(Functional semantics)
• Inputs: What the distributor can (Data semantics)
give to the to the Manufacturer’s (QoS semantics)
service (Data semantics) (Syntactic description)
• Outputs: What the distributor
expects as outputs from the
service (Data semantics) • Description:
• QoS: Quality of Service the Natural language
distributor expects from the description of the
service (QoS semantics)
service
functionality
(Syntactic description)
Syntactic, QoS, and Semantic Web Service
(Functional &?Data) Similarity
Similarity
Discovery
Syntactic
Name, A Name,
Description, B
X
Y
Description, Similarity
… ….
C
1SynNS ( ST .sn, SO.sn) 2 SynDS( ST .sd , SO.sd )
SynSimilarty( ST , SO) [0..1],
1 2
Web Service Web Service and 1 , 2 [0..1]
Similarity ?
QoS QoS
QoS
A
OpSimilarity(ST , SO) Similarity Buy B
X
Purchase
3 QoSdimD( ST , SO, time) * QoSdimD( ST , SO, cost ) * QoSdimD( ST , SO, reliability)
Y
C
Web Service Web Service
Functional & Data
Similarity ?
Calendar-Date
Event Similarity
A1 … A2
… {x,
Coordinates y}
… Information Function
Area {name}
Forrest
Web Service Web Service
Get Information Get Date
The Match Function
Semantic Similarity ((O) = (I))
• When comparing concepts defined with
the same ontology four distinct scenarios
need to be considered:
– a) the concepts are the same (O=I)
– b) the concept I subsumes concept O (O>I)
– c) the concept O subsumes concept I (O<I),
or
– d) concept O is not directly related to concept
I (OI).
The Match Function
Semantic Similarity ((O) = (I))
Similarity ?
Calendar-Date
Event
A1 … A2
…
…
Web Service Web Service
ST1,2 (output) SO1,2,3,4 (input)
Time ontology b) Time ontology
Temporal-Entity Temporal-Entity
2
Time Time Time-Point {absolute_time} a) Time Time Time-Point {absolute_time}
Interval Domain Interval Domain
1 1
{year, month, day} Date Time {hour, minute, second} {year, month, day} Date Time {hour, minute, second}
2 3 4
Calendar-Date Event Calendar-Date Event
{dayOftheWeek, monthOftheYear} c) {dayOftheWeek, monthOftheYear}
Scientific-Event {millisecond} Scientific-Event {millisecond}
d)
Semantic Process Composition
Web Process
Composition
Semantic Process Composition
Composition is the task of combining and
linking existing Web Services and other
components to create new processes.
Types of Composition
– Static Composition - services to be composed are
decided at design time
– Dynamic Composition - services to be composed
are decided at run-time
SCET, Semantic Web Process Composition
Composition of Web Processes Web Process
Web Process
Composition Composition
Web Service Discovery Web Service Integration
Once the desired This is because the
Web Services have heterogeneous Web
been found
(Discovery), services found in the
mechanisms are first step need to
needed to facilitate interoperate with
the resolution of other components
structural and present in a process
semantic differences
(integration) host
Integration Web Process
Composition
New Requirements
• When Web services are put together
– Their interfaces need to interoperate.
– Structural and semantic heterogeneity need to be resolved*.
• Structural heterogeneity exists because Web
services use different data structures and class
hierarchies to define the parameters of their
interfaces.
• Semantic heterogeneity considers the intended
meaning of the terms employed in labeling interface
parameters. The data that is interchanged among
Web services has to be understood.
* Kashyap and Sheth 1996
QoS
QoS Computation Graph Reduction
Technique
pj
ti tj tij
(a) (b)
Reduction of a
Sequential System T(tij) = T(ti) + T(tj)
C(tij)= C(ti) + C(tj)
R(tij) = R(ti) * R(tj)
F(tij).ar = f(F(ti), F(tj))
QoS
QoS Computation Graph Reduction
Technique
t1
pa1 p1b
* pa2 p2b * p1n pb
ta t2 tb ta t1n tb
pan pnb
tn
(a) (b)
Reduction of a
Parallel System T(t1n) = MaxI{1..n} {T(ti)}
C(t1n) =
1i .n
C(ti)
R(t1n) =
1i .n
R(ti)
F(t1n).ar = f(F(t1), F(t2), …, F(tn))
Constraint Based Process Composition
• User defines High level goals
– Abstract BPEL process (control flow without
actual service bindings )
– Process constraints on QoS parameters
• Generic parameters like time, cost, reliability
• Domain specific parameters like supplyTime
• Business constraints captured in
ontologies or databases
– E.g preferred suppliers, domain constraints
Sample Abstract BPEL Process
<process name="orderProcess"
DEFINITIONS
targetNamespace="http://tempuri.org/"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:tns="http://tempuri.org/">
<partnerLinks>
<partnerLink name="User" xmlns:ns1="tns" partnerLinkType="ns1:UserSLT"/>
<partnerLink name="orderPartner" xmlns:ns2="?" partnerLinkType="ns2:?"/>
<partnerLink name="orderPartner2" xmlns:ns8="?" partnerLinkType="ns8:?"/>
</partnerLinks>
Unknown
partners
<flow name="start">
FLOW
<invoke name="orderPArt" partnerLink="orderPartner" xmlns:ns7="?" portType="ns7:?"
operation="?" inputVariable="orderInput" outputVariable="orderOutput">
</invoke>
<invoke name="orderPArt2" partnerLink="orderPartner2" xmlns:ns9="?" portType="ns9:?"
operation="?" inputVariable="orderInput" outputVariable="orderOutput">
</invoke>
</flow>
</process>
Constraint Analyzer/Optimizer
• Constraints can be specified on each activity or
on the process as a whole.
• An objective function can also be specified e.g.
minimize cost and supply-time etc
• The Web service publishers provide constraints
on the web services.
• The constraint optimizer makes sure that the
discovered services satisfy the client constraints
and then optimizes the service sets according to
the objective function.
Constraint Representation – Domain
Constraints
Fact OWL expression
Supplier1 is an instance of network <NetworkAdaptorSupplier
adaptor supplier rdf:ID="Supplier1">
Supplier1 supplies #Type1 <supplies rdf:resource="#Type1"/>
Supplier1 is a preferred supplier. <supplierStatus>preferred
</supplierStatus>
</NetworkAdaptorSupplier>
Type1 is an instance of <NetworkAdaptor rdf:ID="Type1">
NetworkAdaptor <worksWith>
Type1 works with Type1Battery <Battery rdf:ID="Type1Battery">
</worksWith></ NetworkAdaptor >
Constraint Representation – Process
Constraints
Feature Goal Value Unit Aggregation
Cost Optimize Dollars Σ (minimize total
process cost)
supplytime Satisfy <7 Days MAX (Max. supply
time below
Value)
partnerStatus Optimize MIN (Select best
partner level;
lower value for
preferred
partner)
Working of Constraint Analyzer
Service Abstract Process
Service Specifications Discovery
Template 2 Service templates Engine
Template 1
and service
Process constraints
Supply-time<=7
constraints
Supply-time <= 4 Supply-time <= 3
Cost<=400
Cost <=200 Cost <=300 Min (Cost, Supply-time)
Network Adaptor Battery ST=4 ST=3
C=200 C=180
Domain constraints in
Objective Function ST=3 ST=1
ontologies C=200 C=300
Domain and Process constraints
Optimizer Min (supply-time + cost)
Reasoner (ILP) ST=3
ST=2
(DL) C=100 C=250
Most optimal set cannot be chosen because of
inter service dependencies ST=2
ST=3 ST=3
ST=2
Network Adator from supplier 1 does not work
C=100 C=250 C=100 C=250
battery from supplier 2
ST=4 ST=3 ST=4 ST=3
C=200 C=180 C=200 C=180
Ranked Set Ranked Set
Ongoing Projects
• OWL-S: http://www.daml.org/services/
– Set of ontologies to describe functionalties of web services
• OWL-S Matchmaker: http://www-
2.cs.cmu.edu/%7Esoftagents/daml_Mmaker/OWL-
S_matchmaker.htm
– Match service requestors with service providers
– Semantic Matchmaking for Web Services Discovery
• Web Service Composer:
http://www.mindswap.org/~evren/composer/
– Semi-automatic process for the dynamic composition of web
services
• Web Services: http://www-
106.ibm.com/developerworks/webservices/
– WSDL, UDDI, SOAP
– Business Process with BPEL4WS
Ongoing Projects
• SWSI
– SWSA Semantic Web Services Architecture
– SWSL Semantic Web Services Language
• WonderWeb: http://wonderweb.man.ac.uk/
– Development of a framework of techniques and
methodologies that provide an engineering approach to
the building and use of ontologies.
– Development of a set of foundational ontologies covering
a wide range of application domains.
– Development of infrastructures and tool support that will
be required by real world applications in the Semantic
Web.
OWL-S 1.1
• Represents Semantic Web Services via 4 files
• Each service is created as an instance of service
ontology
• Language: OWL + SWRL
WSMO –Web Service Modeling Ontology
• Represents Semantic Web Services by F-logic
• F-logic is used to
– Describe ontologies
– Describe rules and
goals
– Uses Mediators to
bring about
inter-operability
METEOR-S Architecture
Front-End
Back-End
METEOR-S Front-End
• Semantic Web Service Designer
– Developing Semantic Web Services
• Semantic Description Generator
– Various types of semantic definitions for a service
• Publishing Interface
– Making them available through UDDI registries
(Enhanced UDDI)
• Enhanced UDDI
– Reorganized UDDI to discover relevant service based on
semantics
• Discovery Engine
– To discover the relevant services according to requestor
requirements
Semantic Web Service Designer
• Eclipse plug-in to design Semantic Web
Services
• User Interface for developing semantic
web services
• Facilitates annotation of source code with
semantic information
Semantic Web Service
Designer(contd.)
Source Code Annotation
• Easy to incorporate appropriate semantic
descriptions while developing code
• Similar to java documentation
• Used to generate semantically enhanced
annotated WSDL or WSDL-S
Generates
• Annotations Service Interfaces
• Uses jdk1.5 Metadata feature (JSR 175 &
JSR 181)
Annotated Java Source Code
- Semantic Concept
Semantic Description Generator
• Input
– Annotated Source Code - semantically rich
to enable semantic web service
• Output
– WSDL 1.1 annotated with semantic
information via extensible tags
– WSDL-S –WSDL 2.0 with semantic annotation
– OWL-S files – Profile, Grounding, Process
(basic) and associated WSDL
WSDL-S
• WSDL-S (WSDL with Semantic Annotation)
• Mapping Input and Output Message Parts to Ontology
– XML Schema elements used in Input/Output messages do not reflect the
semantics of the data involved in Web Service operation
– Use of ontologies or standard vocabulary* provides well defined semantics for
operational data
• Mapping Operations to Ontology
– Service selection involves discovering appropriate WSDL description and locating
an operation to invoke
– Operations with same signature could have different functionalities
– Ontology or vocabulary* depicting functionality is used for annotation
• Additional tags to represent pre-conditions and
effects/post-conditions of each operation
– Pre-conditions and Post-Conditions are added for each operation
– Can be optionally used for service discovery and selection
* RosettaNet Business/Technical dictionary or ebXML Core Component catalog/dictionary
* Current implementation uses vocabularies
The focus of our work is not in developing ontologies for representing functionality/preconditions/effects but to use
such ontologies for semantic annotation
Enhanced UDDI
Annotated Java Source Code Enhanced UDDI
@interface ( domain = "naics:Computer and Electronic Product Manufacturing" ,
description = "Computer PowerSupply Battery Buy Quote Order Status ",
businessService = "Battery Outlet")
public interface BatterySupplier {
@operation (name = "placeOrder", action = "rosetta: #RequestPurchaseOrder " )
@parameters ({
@inParam ( name = "order", element = "rosetta: #PurchaseOrderRequest
@outParam( name="orderConfirmation",
element="rosetta: #PurchaseOrderConfirmation" )
})
QuoteConfirmation getQuote (QuoteRequest qRequest );
.
.
.
- Publishing Interface
Discovery Engine
• Input
– Semantic service template built by user
/execution engine
• Output
– List of services ranked by relevance to query
• Ranking algorithm employed
-Matches operation/input/output semantic
concepts of Published Services Vs. service
template.
-Employs heuristic based subsumption relations
of ontological concepts
Discovery Engine
Service Template
<serviceTemplate>
<namespace
rosetta=“http://lsdis.cs.uga.edu\METEOR-S\Rosetta.owl/>
<namespace …
.
user .
<domain name=Computer and
Electronic Product Manufacturing
<operations>
uses <operation name=“placeOrder “
concept= "rosetta: #RequestPurchaseOrder" >
<input name=“order”
concept="rosetta: #PurchaseOrderRequest" />
Execution Engine <output name=“orderConfirmation”
Discovery Engine
concept="rosetta: #PurchaseOrderConfirmation" />
</operation>
<operation….
.
</operation>
</operations>
.
</serviceTemplate> Ranked Response
METEOR-S Back-End
DesignTime
uses Abstract Process Abstract
Designer Process
Binder Executable
Process
BPWS4J
Execution
Process Instance Service
Process Process Engine
Template(s)
Initiation Time Annotation Tool Repository
(PUBLISH)
Optimized
Service Set
query Constraint
Discovery Engine
Analyzer
Ranked Response
Enhanced
UDDI
Conclusions
Conclusions
• SOA, Web processes, and Semantic Web processes
• Semantics can help address big challenges related to
scalability, dynamic environments.
• But comprehensive approach to semantics will be needed:
– Data/information, function/operation, execution, QoS
• Semantic (Web) principles and technology bring new tools
and capabilities that we did not have in EAI, workflow
management of the past
• SWP
– Semantics: Data, Function, QoS, Execution
– Affects full Web Service/Process lifecycle: Annotation,
Publication, Discovery, Composition, Binding, Execution
More at: http://lsdis.cs.uga.edu/proj/meteor/SWP.htm
Semantic Web Processes
Questions?
References
Extensive related work at: IBM, Karlsruhe, U. Manchester, OWL-S (CMU, Stanford, UMD)
• Resources: http://lsdis.cs.uga.edu/lib/presentations/SWSP-tutorial-
resource.htm
• [Kreger] http://www-
3.ibm.com/software/solutions/webservices/pdf/WSCA.pdf
• [Sivashanmugam et al.-1] Adding Semantics to Web Services Standards
• [Sivashanmugam et al.-2] Framework for Semantic Web Process
Composition
• [Verma et al.] MWSDI: A Scalable Infrastructure of Registries for
Semantic Publication and Discovery of Web Services
• [Chandrasekaran et al.] Performance Analysis and Simulation of
Composite Web Services
• [Cardoso et al.] Modeling Quality of Service for Workflows and Web
Service Processes
• [Silver et al.] Modeling and Simulation of Quality of Service for
Composition of Web Services
• [Paolucci et al.] Importing Semantic Web in UDDI
• [UDDI-v3] http://uddi.org/pubs/uddi-v3.00-published-20020719.htm
• http://www.daml.org/services/
• http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/
More at: http://lsdis.cs.uga.edu/SWP.htm
References – Partial List
• [WSMO] www.wsmo.org
• [OWL-S] www.daml.org/services/owl-s/
• [METEOR-S] lsdis.cs.uga.edu/Projects/METEOR-S
• [Aggarwal et al., 2004] Constraint Based Web Service Composition
• [Cardoso et al., 2004] Semantic e-Service Composition
• [Sivashanmugam et al., 2003] Adding Semantics to Web Services
Standards
• [Sivashanmugam et al., 2004] Framework for Semantic Web Process
Composition
• Sivashanmugam et al., 2004] Discovery of Web Services in a Federated
Registries Environment
• [Verma et al. 2004] MWSDI: A Scalable Infrastructure of Registries for
Semantic Publication and Discovery of Web Services
• [Verma et al. 2004] Accommodating Inter-Service Dependencies in Web
Process Flow Composition
SOA and
Semantic Web Processes
End
