Semantic Web Process Lifecycle:

Annotation, Discovery, Publication, and Composition

Amit ShethProfessor, University of Georgia

Director, LSDIS LabCTO/co-founder, Semagix

Semantics at Different Layers

Publication

Discovery

Description

Messaging

Network

Flow

Description Layer Why: • Unambiguously understand the functionality of the services,

the semantics of input/output data, and QoS of services

How: • Using Ontologies to semantically annotate WSDL

constructs (conforming to extensibility allowed in WSDL specification version 1.2/2.0) – WSDL-S : Incorporates many types of semantics in

the service description – Tools for (semi-)automatic semantic annotation of

Web Services (e.g., METEOR-S MWSAF)

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" > <operation name = "getQuote" pattern = "mep:in-out" action = "rosetta:#RequestQuote" >

<input messageLabel = ”qRequest” element = "rosetta:#QuoteRequest" /> <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" /> <pre condition = " order.PurchaseOrder.PurchaseOrderLineItem.RequestedQuantity > 7" /> </operation> <operation name = "checkStatus" pattern="mep:in-out" action = "rosetta:#QueryOrderStatus" >

<input messageLabel = ”statusQuery” element = "rosetta:#PurchaseOrderStatusQuery" /> <output messageLabel = ”status” element = "rosetta:#PurchaseOrderStatusResponse" /> <exception element = "rosetta:#OrderNumberInvalidException" />

</operation> </interface></definitions>

Function from Rosetta Net

Ontology

Data from Rosetta Net

Ontology

Semantics at Different Layers (contd..)

Publication

Discovery

Description

Messaging

Network

Flow

Publication and Discovery Layers Why: • Enable scalable, efficient and dynamic publication and

discovery (machine processable / automation)

How: • Use federated registries categorized by domans • Publish services based on domains• Capture the WSDL-S annotations in UDDI

Present scenario:

• Suitable for simple searches ( like services offered by a 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

subDomainOf

supports

belongsTo

consistsOf

belongsToFederation

Ontology

Registry

Domain

RegistryFederation

Semantics at Different Layers (contd..)

Publication

Discovery

Description

Messaging

Network

Flow

Flow Layer: Why: • Design (composition), analysis (verification), validation

(simulation) and execution (exception handling) of the process models

• To employ mediator architectures for dynamic composition, control flow and data flow based on requirements

How: Using• Templates to capture semantics

(functionality/preconditions/effects/QoS) of the participating services and for the process

• Knowledge of conversation patterns supported by the service• Formal mathematical models like process algebra, concurrency

formalisms like State Machines, Petri nets etc.• Simulation techniques 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

Publication

Discovery

Description

Messaging

Network

Flow

MWSDI: Scalable Infrastructure of Registries for Semantic publication and discovery of Web Services

MWSAF: Semantic Annotation of WSDL (WSDL-S)

MWSCF: Semantic Web Process Composition Framework

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

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

PurchaseOrder.wsdl

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

<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

Annotating input/output elements – 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

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

Alternative annotation• 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

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

WSDL-S in perspective

Semantic Publishing and Template Based Discovery

WSDL-S

<Operation>

<Input1>

<Output1>

Service Template

Operation:buyTicket

Input1:TravelDetails

Output1:Confirmation

Annotations

Publish

Search

UDDIOperation:

cancel Ticket

Input1:TravelDetails

Output1:Confirmation

...<xs:complexType name="processPurchaseOrderRequest"><xs:element name="billingInfo" type="xsd1:POBilling"/><xs:element name="orderItem" type="xsd1:POItem"/></xs:complexType></xs:schema><operation name="processPurchaseOrder” pattern=wsdl:in-out><input messageLabel = ”processPurchaseOrderRequest"element="tns:processPurchaseOrderRequest"/><output messageLabel ="processPurchaseOrderResponse"element="processPurchaseOrderResponse"/>...

WSDL

...<xs:complexType name="processPurchaseOrderRequest“wssem:modelReference="POOntology#OrderDetails” ><xs:element name="billingInfo" type="xsd1:POBilling"/><xs:element name="orderItem" type="xsd1:POItem"/></xs:complexType></xs:schema><operation name="processPurchaseOrder” pattern=wsdl:in-out><input messageLabel = ”processPurchaseOrderRequest"element="tns:processPurchaseOrderRequest"/><output messageLabel ="processPurchaseOrderResponse"element="processPurchaseOrderResponse"/>...

WSDL - SAnnotating a service

...<xs:complexType name="processPurchaseOrderRequest“wssem:modelReference="POOntology#OrderDetails” ><xs:element name="billingInfo" type="xsd1:POBilling"/><xs:element name="orderItem" type="xsd1:POItem"/></xs:complexType></xs:schema><operation name="processPurchaseOrder” pattern=wsdl:in-out><input messageLabel = ”processPurchaseOrderRequest"element="tns:processPurchaseOrderRequest"/><output messageLabel ="processPurchaseOrderResponse"element="processPurchaseOrderResponse"/>...

WSDL - S

UDDI

Semantic Layer

Publishing a service

WSDL-S in the life cycle of a Web services

WSDL-S in the life cycle of a Web process

Web Service Discovery

<Operation>

<Input2>

<Output2>

Service 2 Template

An abstract Web process

WSDL-SWSDL-S

<Operation>

<Output1>

Service 1 Template

<Input1>

<Operation>

<Output1>

Web service 1

<Input1>

<Operation>

<Output2>

Web service 2

<Input2>

WSDL-SmodelReferenceschemaMapping

Transformation

WSDL-SmodelReferenceschemaMapping

Process execution

WSDL-S in action• ProPreO - Experimental Proteomics

Process Ontology (CCRC / LSDIS)

data

sequence

peptide_sequence

Excerpt: ProPreO – process ontology

<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace="urn:ngp" ……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"> ……</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>......

Excerpt: Bio-informatics Web service 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 – SchemaGraphWhat 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 SchemaGraphRule XML Schema constructs SchemaGraph representation

1 Element, Node

2 simpleType Node

3 Enumeration values defined for simpleType S

Node with edge between simpleType S node and value node with name “hasValue”

4 ComplexType Node

5 Sub-elements of complexType C which have range as basic XML datatypes

Node with edge between complexType C node and this node with name “hasElement”

6 Sub-elements of complexType C which have range as complexTypes or simpleTypes or elements defined in same schema

Edge between complexType C node and the range type node

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" />   </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>- <xsd:complexType name="Wind">- <xsd:sequence>  <xsd:element name="gust_speed" type="xsd:double" />   <xsd:element name="prevailing_direction" type="xsd1:Direction" />   </xsd:sequence>  </xsd:complexType>- <xsd:simpleType name="PhenomenonType">- <xsd:restriction base="xsd:string">  <xsd:enumeration value="MIST" />   <xsd:enumeration value="FOG" />   <xsd:enumeration value=“SNOW" />   <xsd:enumeration value="DUST" />   </xsd:restriction>  </xsd:simpleType>

WeatherReport

WindPhenomenon

Directiongust_speedPhenomenonType

PhenomenonIntensity

MIST FOG SNOW DUST

phenomenawind

prevailing_directionhasElement

intensity

type

oneOf oneOf

oneOfoneOf

Rule 3

Rule 1 simpletype => Node

Rule 1complextype => Node

Rule 6

Rule 5

Rule 1Element => Node

MWSAF - Ontology to SchemaGraphRule Ontology representation SchemaGraph representation

1 Class Node

2 Property of class D with basic datatype as range (Attribute)

Node with edge joining it to class D node with name “hasProperty”

3 Property of class D with other class R as range (Relation)

Edge between class D node and range 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>   <rdfs:label>Weather event</rdfs:label>   </daml:Class>- <daml:Class rdf:ID="WindEvent">  <rdfs:subClassOf rdf:resource="#WeatherPhenomenon" />   </daml:Class>- <daml:Property rdf:ID="windDirection">  <rdfs:domain rdf:resource="#WindEvent" />   </daml:Property>- <daml:Class rdf:ID="GustingWindEvent">  <rdfs:subClassOf rdf:resource="#WindEvent" />   </daml:Class>- <daml:Class rdf:ID="CurrentWeatherPhenomenon">  <rdfs:subClassOf rdf:resource="#WeatherPhenomenon" />   </daml:Class>- <daml:Class rdf:ID="OtherWeatherPhenomena">  <rdfs:subClassOf rdf:resource="#CurrentWeatherPhenomenon" />   </daml:Class> - <daml:Class rdf:ID="Duststorm">  <rdfs:subClassOf rdf:resource="#OtherWeatherPhenomena" />   </daml:Class>- <daml:Class rdf:ID="PrecipitationEvent">  <rdfs:subClassOf rdf:resource="#CurrentWeatherPhenomenon" />   </daml:Class>- <daml:Class rdf:ID="SolidPrecipitationEvent">  <rdfs:subClassOf rdf:resource="#PrecipitationEvent" />   </daml:Class>- <daml:Class rdf:ID="Snow">  <rdfs:subClassOf rdf:resource="#SolidPrecipitationEvent" />   </daml:Class>- <daml:Class rdf:ID="ObscurationEvent">  <rdfs:subClassOf rdf:resource="#CurrentWeatherPhenomenon" />   </daml:Class>- <daml:Class rdf:ID="Fog">  <rdfs:subClassOf rdf:resource="#ObscurationEvent" />   </daml:Class>- <daml:Class rdf:ID="Mist">  <rdfs:subClassOf rdf:resource="#ObscurationEvent" />   </daml:Class>

WeatherPhenomenon

CurrentWeatherPhenomenon

WindEvent

GustingWindEvent

windDirection

ObsucurationEvent

PrecipitationEvent

OtherWeatherPhenomenon

Duststorm

Snow Mist Fog

SolidPrecipitationEvent

Rule 1

Rule 2Rule 5

Semantic Web Service Discovery in METEOR-S

METEOR-S Web Service Discovery Infrastructure

Discovery new Requirements

A

C D

N1 N2 FE

B8

A1A4 A1 A2

A4

B3

A1A4 A6

A2A2

A5

Before

A

C D

N1 N2 FE

A4 A1A1

A4 A1 A4 A1 A2A1 A1A1 A1B3 A1

B3

A1

A2A1

B3

A1A4 A1 A2

A1B3

A1A4 A1 A2

A1

B3

A1

A1

B3

A1A4 A1 A2

A1

B3

A1A4 A2

A1

B3 A1A4 A1 A2

B3 A1A1

B3

A1A4 A1 A2

A1

B3

A1A4 A1

A2A1

B3 A1A4 A1 A2

A1B3

A1A4 A1 A2

A1

A1A4 A1

A1A4 A1 A2B3

A1A4

A1A2A1

B3

A1

A4A1 A2

A1

B3

A1A4 A1 A2

B3A1

A4 A1 A2A1

B3

A1A4 A1 A2

A1B3

A1A4 A1 A2

A1

A4

A4

A1

A4 A1

A1 A4 A1 A2

B3

A1A4 A1

A2

A1

B3

A1

A4

A1

A2B3

A1

A4 A1 A2A1

A4

A1

A4 A1

A1A4 A1 A2

A1

A1

A4 A1 A2A1

A1A4

A1

B3A1

A1A1

B3

A1A4 A1 A2

A1B3

A1A4 A1 A2

A1

A1 A2

A1

A4 A2A4 A2A2

A1

A1

B3

A1A4 A1 A2

A1

Now

QoS

QoS

Tasks

Workflow

Web Services

Web Process

Web ServiceDiscovery

Web ServiceDiscovery

State of the art in discovery

Provides non-semantic search

Keyword and attribute-based

match Search retrieves lot of services (irrelevant

results included)

UDDI Business Registry

Which service to select ? How to select?

Search

Results

Selection

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

Use of ontologies enables shared understanding between the service provider and service requestor

Semantic Publication and Discovery

WSDL

<Operation>

<Input1>

<Output1>

Service Template

Operation:buyTicket

Input1:TravelDetails

Output1:Confirmation

Annotations

Publish

Search

UDDI

Class

TravelServices

Class

DataClass

Operations

subClassOf subClassOf

subClassOfsubClassOf subClassOf subClassOf

ClassTicket

Information

ClassTicket

Booking

ClassTicket

Cancellation

ClassConfirmation

Message

Operation:cancelTicket

Input1:TravelDetails

Output1:Confirmation

For simplicity of depicting, the ontology is shown with classes for both operation and dataAdding Semantics to Web Services Standards

Present Discovery MechanismKeyword 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?)

Web ServiceDiscovery

Web ServiceDiscovery

Discovery in Semantic Web Using Semantics

• Functionality: What capabilities the requestor expects from the service (Functional semantics)

• Inputs: What the requestor can give to the to the Web service (Data semantics)

• Outputs: What the requestor expects as outputs from the service (Data semantics)

• QoS: Quality of Service the distributor expects from the service (QoS semantics)

Web ServiceDiscovery

Web ServiceDiscovery

(Functional semantics)(Data semantics)(QoS semantics)(Syntactic description)

• Description: Natural language description of the service functionality (Syntactic description)

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

DiscoveryThe Match Function

The Match FunctionSemantic 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

HotelReservation

HotelReservation

TravelReservation

Get UserInformationGet User

Information

Get ConferenceInformation

Get ConferenceInformation

Conference

Employee ID

DateDuration

City

DateDuration

City

User NameAddress

User NameAddress

ItineraryItinerary

Conference RegistryService

Hotel Reservation Service

?

A BStart End

SO2SO2

SO3SO3

0.990.34 0.74

Match FunctionSO1SO10.14

0.980.68

0.430.31

0.76

ST

f(ST, SO1) f(ST, SO2) f(ST, SO3)

ST

Web Process

Discovery in SWS• Functionality: What capabilities

the distributor expects from the service (Functional semantics)

• Inputs: What the distributor can give to the to the Manufacturer’s service (Data semantics)

• Outputs: What the distributor expects as outputs from the service (Data semantics)

• QoS: Quality of Service the distributor expects from the service (QoS semantics)

Web ServiceDiscovery

Web ServiceDiscovery

(Functional semantics)(Data semantics)(QoS semantics)(Syntactic description)

• Description: Natural language description of the service functionality (Syntactic description)

Syntactic, QoS, and Semantic (Functional & Data) Similarity

Name,Description,

….

Name,Description,

….

Name,Description,

…

Name,Description,

…

XY

ABC

Web Service Web Service

Similarity ?

A2A2A1A1Calendar-Date

…

…

Event

…

Similarity ?

Web Service Web Service

Functional & Data Similarity

Functional & Data Similarity

]1..0[, and

],1..0[).,.().,.(

),(

21

21

21

sdSOsdSTSynDSsnSOsnSTSynNS

SOSTtySynSimilar

3 ),,(QoSdimD*),,(QoSdimD*),,(QoSdimD

),ty(OpSimilari

yreliabilitSOSTcostSOSTtimeSOST

SOST

SyntacticSimilaritySyntacticSimilarity

PurchasePurchaseBuyBuy

XY

ABC

QoS QoS

Web Service Web Service

Similarity ?

QoSSimilarity

QoSSimilarity

Web ServiceDiscovery

Web ServiceDiscovery

Area

Coordinates

Forrest

{name}

{x, y}

Information Function

Get Information Get Date

The Match FunctionSemantic 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 FunctionSemantic Similarity ((O) = (I))

Temporal-Entity

TimeInterval

Time-Point

Date Time

TimeDomain

Event

Scientific-Event

Calendar-Date

{absolute_time}

{hour, minute, second}

{millisecond}

{year, month, day}

{dayOftheWeek, monthOftheYear}

Temporal-Entity

TimeInterval

Time-Point

Date Time

TimeDomain

Event

Scientific-Event

Calendar-Date

{absolute_time}

{hour, minute, second}

{millisecond}

{year, month, day}

{dayOftheWeek, monthOftheYear}

a)

b)

c)

d)

ST1,2 (output) SO1,2,3,4 (input)

Time ontology Time ontology

1

2

1

2

3 4

A2A2A1A1Calendar-Date

…

…

Event

…

Similarity ?

Web Service Web Service

Semantic 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

Web Process Composition

Web Process Composition

SCET, Semantic Web Process Composition

Composition of Web Processes

Once the desired Web Services have been found (Discovery), mechanisms are needed to facilitate the resolution of structural and semantic differences (integration)

Web Process Composition

Web Process Composition

Web Process

Composition

Web Service Discovery Web Service Integration

This is because the heterogeneous Web services found in the first step need to interoperate with other components present in a process host

IntegrationNew 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

Web Process Composition

Web Process Composition

tij

pj

(a) (b)

ti tj

Graph Reduction Technique

Graph Reduction Technique

QoS Computation

Reduction of a Sequential System

QoSQoS

tbta*

(a) (b)

*tbta t1n

pa1p1b

pnb

p2b

pan

pa2p1n pb

t1

t2

tn

Graph Reduction Technique

Graph Reduction Technique

Reduction of a Parallel System

QoS Computation QoSQoS

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"

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>

<flow name="start"> <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>

DEFINITIONS

Unknown partners

FLOW

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 adaptor supplier

Supplier1 supplies #Type1Supplier1 is a preferred supplier.

<NetworkAdaptorSupplier rdf:ID="Supplier1">

<supplies rdf:resource="#Type1"/><supplierStatus>preferred</supplierStatus></NetworkAdaptorSupplier>

Type1 is an instance of NetworkAdaptor

Type1 works with Type1Battery

<NetworkAdaptor rdf:ID="Type1"> <worksWith><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

DiscoveryEngine

Optimizer (ILP)

Service Template 1

Service Template 2

ST=2C=100

ST=3C=250

ST=3C=200

ST=1C=300

ST=4C=200

ST=3C=180

Ranked Set

Objective Functionand Process constraintsMin (supply-time + cost)

Supply-time <= 4

Cost <=200

Network Adaptor

Supply-time <= 3

Cost <=300

Battery

Process constraintsSupply-time<=7

Cost<=400Min (Cost, Supply-time)

ST=2C=100

ST=3C=250

ST=4C=200

ST=3C=180

Abstract ProcessSpecifications

Domain Reasoner

(DL)

ST=2C=100

ST=3C=250

ST=4C=200

ST=3C=180

Ranked Set

Service templates and service constraints

Domain constraints in ontologies

Most optimal set cannot be chosen because of inter service dependenciesNetwork Adator from supplier 1 does not work battery from supplier 2

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• Annotations Service Interfaces• Uses jdk1.5 Metadata feature (JSR 175 &

JSR 181)

Generates

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 @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 );

.

.

.

Annotated Java Source Code Enhanced UDDI

- 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

<serviceTemplate><namespace rosetta=“http://lsdis.cs.uga.edu\METEOR-S\Rosetta.owl/><namespace …..<domain name=Computer and Electronic Product Manufacturing <operations><operation name=“placeOrder “ concept= "rosetta: #RequestPurchaseOrder" ><input name=“order” concept="rosetta: #PurchaseOrderRequest" /><output name=“orderConfirmation” concept="rosetta: #PurchaseOrderConfirmation" /></operation>

<operation….. </operation> </operations>.</serviceTemplate>

Service Template

Execution Engine

uses

Ranked Response

user

Discovery Engine

uses Abstract Process

Enhanced UDDI

Ranked Response

Discovery Engine

Service Template(s)

(PUBLISH)

METEOR-S Back-EndAbstract Process

Designer

query Constraint Analyzer

Optimized

Service Set

Process Repository

Process Annotation Tool

Executable Process

Binder

BPWS4J Execution

Engine

DesignTime

Process Instance

Initiation Time

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

• 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

Extensive related work at: IBM, Karlsruhe, U. Manchester, OWL-S (CMU, Stanford, UMD)

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 andSemantic Web Processes

End