Transcript The METEOR-S Framework for Semantic Web Process Composition

The METOER-S Framework for
Semantic Web Process Composition
Kaarthik Sivashanmugam
Large Scale Distributed Information Systems (LSDIS) Lab,
Department of Computer Science,
The University of Georgia
Acknowledgements
• Advisory Committee
– Dr. John A. Miller (Major Advisor)
– Dr. Amit P. Sheth (Co-advisor)
– Dr. Hamid R. Arabnia
• LSDIS Student Members
– Kunal Verma, Deepti Chafekar, Ivan Vasquez, Preeda
Rajasekaran and others
Outline
• Introduction to Web services, Web services conceptual
stack and Web processes
• Challenges in Web services adoption
• Semantics at different layers of Web services conceptual
stack
• Semantics for Web service life-cycle
• METEOR-S project at LSDIS lab
– Discovery Infrastructure (MWSDI)
– Composition Framework (MWSCF)
Outline (contd)
• MWSDI
– P2P network of Web service registries
– Semantics based publication and discovery of Web services
• MWSCF
– Need and advantages of Semantic Web process composition
– Template based process generation
– Tool for Template construction, Web service discovery and Process
generation
• Conclusion and Future Work
• References
Web Services
• Software applications (conforming set of standards) that
can communicate with other software applications
independent of their operating systems, programming
languages etc.
to enable interoperability and to deliver complex value added services
• A Web service is a software application identified by a
URI, whose interfaces and binding** are capable of being
defined, described and discovered by XML artifacts and
supports direct interactions with other software applications
using XML based messages via Internet-based protocols.
(W3C definition)
**- An association between an Interface, a concrete protocol and a data format
Web Service Conceptual Stack1
Description:Web Service Description Language
(WSDL)
–
To describe Web Service interfaces and
implementations
–
Details in WSDL files (data types, operations,
binding details, access location) are used for service
invocation
Description
Messaging
Network
Messaging:(SOAP)
–
Network:(HTTP)
–
1
[Kreger]
XML based messaging protocol
Network protocol
Web Service Conceptual Stack1
Publication:(UDDI)
Flow
Discovery
Publication
Description
Messaging
Network
1
[Kreger]
–
To make service descriptions available for
search
Discovery:(UDDI)
–
To locate service descriptions
Flow:(BPEL4WS, WSCI etc.)
–
To compose web services to form a composite
web service / process
Web Processes
• Web Processes are next generation workflow
technology to facilitate the interaction of
organizations with markets, competitors, suppliers,
customers etc. supporting enterprise-level and core
business activities
– encompass the ideas of both intra and inter organizational workflow.
– created from the composition of Web Services
• When all the tasks involved in a Web process are
semantically described, we may call such process as
Semantic Web Processes
Globalization of Processes
B2B
Workflows
Enterprise
Distributed
Workflows
Inter-Enterprise
E-Services
Web Processes
Global
BIG Challenges
• Heterogeneity and Autonomy
– Solution: Machine understandable descriptions
• Dynamic nature of business interactions
– Demands: Efficient Discovery, Composition etc.
• Scalability (Enterprises  Web)
– Needs: Automated service discovery/selection and
composition
Proposition: Semantics is the most important
enabler to address these challenges
METEOR-S Project @ LSDIS lab
• METEOR-S exploits Workflow, Semantic Web,
Web Services, and Simulation technologies to
meet these challenges in a practical and standards
based approach.
– Applying Semantics in Annotation, Quality of Service, Discovery,
Composition, Execution of Web Services
– Adding semantics to different layers of Web services conceptual
stack
– Use of ontologies to provide underpinning for information sharing
and semantic interoperability
Semantics at Different Layers
Description Layer:
Flow
Discovery
Publication
Description
Messaging
Network
Why:
•
Unambiguously understand the functionality of the services
and the semantics of the operational data
How:
•
Using Ontologies to semantically annotate WSDL
constructs (conforming to extensibility allowed in WSDL
specification version 1.2) to sufficiently explicate the
semantics of the
–
–
data types used in the service description and
functionality of the service
Present scenario:
•
WSDL descriptions are mainly syntactic (provides
operational information and not functional information)
•
Semantic matchmaking is not possible
Semantics at Different Layers
(contd..)
Publication and Discovery Layers:
Flow
Discovery
Publication
Why:
•
Enable scalable, efficient and dynamic publication and
discovery (machine processable / automation)
How:
•
Use of ontology to categorize registries based on domains
and characterize them by maintaining the
1.
2.
Description
Messaging
Network
•
properties of each registry
relationships between the registries
Capturing the WSDL 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
Semantics at Different Layers
(contd..)
Flow Layer:
Flow
Discovery
Publication
Description
Messaging
Network
Why:
•
Design (composition), analysis (verification), validation
(simulation) and execution (exception handling) of the
process models
•
To employ mediator architectures for automated
composition, control flow and data flow based on
requirements
•
To employ user interface to capture template requirements
and generate template based on that
How:
•
Using
–
–
–
–
Functionality/preconditions/effects of the participating
services
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 supported directly
Semantics in WS stack and METEOR-S
Flow
Discovery
Publication
Description
Messaging
Network
MWSCF: Semantic Web Process Composition
Framework
MWSDI: Scalable Infrastructure of Registries for
Semantic publication and discovery of Web
Services
MWSDI: Semantic Annotation of WSDL (WSDL-S)
Semantics for Web Services
•
Data/Information Semantics
–
–
–
•
Functional/Operational Semantics
–
–
–
•
Formally representing capabilities of web service
for discovery and composition of Web Services
by annotating operations of Web Services as well as provide preconditions and effects;
Annotating TPA/SLA
Execution Semantics
–
–
–
•
What: Formal definition of data in input and output messages of a web service
Why: for discovery and interoperability
How: by annotating input/output data of web services using ontologies
Formally representing the execution or flow of a services in a process or operations in a service
for analysis (verification), validation (simulation) and execution (exception handling) of the
process models
using State Machines, Petri nets, activity diagrams etc.
QoS Semantics
–
–
–
Formally describing operational metrics of a web service/process
To select the most suitable service to carry out an activity in a process
using QoS model [Cardoso and Sheth, 2002] for web services
Semantics for Web Service Life-Cycle
Development
/ Description
/ Annotation
Execution
BPWS4J,
Commercial BPEL
Execution Engines,
Intalio n3, HP
eFlow
BPEL, BPML,
WSCI, WSCL,
DAML-S,
METEOR-S
(SCET,SPTB)
WSDL, WSEL
DAML-S
Data
/ Information
Semantics
Meteor-S (WSDL
Annotation)
UDDI
WSIL, DAML-S
Composition
Publication
/ Discovery
METEOR-S (P2P
model of registries)
Semantics for Web Service Life-Cycle
Development
/ Description
/ Annotation
Execution
BPWS4J,
Commercial BPEL
Execution Engines,
Intalio n3, HP
eFlow
BPEL, BPML,
WSCI, WSCL,
DAML-S,
METEOR-S
(SCET,SPTB)
WSDL, WSEL
DAML-S
Data
/ Information
Semantics
Meteor-S (WSDL
Annotation)
UDDI
WSIL, DAML-S
Composition
Publication
/ Discovery
METEOR-S (P2P
model of registries)
Semantics for Web Service Life-Cycle
Development
/ Description
/ Annotation
Execution
BPWS4J,
Commercial BPEL
Execution Engines,
Intalio n3, HP
eFlow
BPEL, BPML,
WSCI, WSCL,
DAML-S,
METEOR-S
(SCET,SPTB)
WSDL, WSEL
DAML-S
Meteor-S (WSDL
Annotation)
Functional
/ Operational
Semantics
UDDI
WSIL, DAML-S
Composition
Publication
/ Discovery
METEOR-S (P2P
model of registries)
Semantics for Web Service Life-Cycle
Development
/ Description
/ Annotation
Execution
BPWS4J,
Commercial BPEL
Execution Engines,
Intalio n3, HP
eFlow
WSDL, WSEL
DAML-S
Meteor-S (WSDL
Annotation)
QoS
Semantics
BPEL, BPML,
WSCI, WSCL,
DAML-S,
METEOR-S
(SCET,SPTB)
UDDI
WSIL, DAML-S
Composition
Publication
/ Discovery
METEOR-S (P2P
model of registries)
Semantics for Web Service Life-Cycle
Development
/ Description
/ Annotation
Execution
BPWS4J,
Commercial BPEL
Execution Engines,
Intalio n3, HP
eFlow
BPEL, BPML,
WSCI, WSCL,
DAML-S,
METEOR-S
(SCET,SPTB)
WSDL, WSEL
DAML-S
Meteor-S (WSDL
Annotation)
Execution
Semantics
UDDI
WSIL, DAML-S
Composition
Publication
/ Discovery
METEOR-S (P2P
model of registries)
Semantics for Web Service Life-Cycle
Development
/ Description
/ Annotation
Execution
BPWS4J,
Commercial BPEL
Execution Engines,
Intalio n3, HP
eFlow
WSDL, WSEL
DAML-S
Execution
Semantics
Data
/ Information
Semantics
Meteor-S (WSDL
Annotation)
Semantics Required for
Web Processes
QoS
Semantics
BPEL, BPML,
WSCI, WSCL,
DAML-S,
METEOR-S
(SCET, SPTB)
Functional
/ Operational
Semantics
UDDI
WSIL, DAML-S
Composition
Publication
/ Discovery
METEOR-S (P2P
model of registries)
METEOR-S components for Semantic
Web Services
• Discovery Infrastructure (MWSDI)
– Semantic Annotation and Discovery of Web Services 1
– Semantic Peer-to-Peer network of Web Services Registries 2
• Composer
– SCET: Service Composition and Execution Tool 3
– Semantics Process Template Builder and Process Generator 4
– QoS Management
• Specify, compute, monitor and control QoS (SWR algorithm) 5
• Orchestrator (Under development)
– Analysis and Simulation 6
– Execution
– Monitoring 6
1
[Sivashanmugam et al.-1], 2 [Verma et al.], 3 [Chandrasekaran et al.], 4 [Sivashanmugam et al.-2],
5 [Cardoso et al.], 6 [Silver et al.]
METEOR-S Web Service Discovery
Infrastructure (MWSDI)
- uses Functional, Data and QoS semantics
Service Discovery
METEOR-S Web Service Discovery
Infrastructure (MWSDI)
- uses Functional, Data and QoS semantics
Service Selection
The problem in discovery..
Registry is universal and
provides non-semantic search
Keyword match,
taxonomy
UBR
• Which service to select ?
• How to select?
Search retrieves lot of
services (irrelevant
results included)
Scalable Solution..
Registries are categorized
Select relevant registries
(semantic filtering)
Ontology
Domain
Registry
Select service(s) of
interest
Registry is domain
specific and supports
semantic search
Search for services to book an air ticket
(using categories)*
• unspsc-org: unspsc:3-1
– Travel, Food, Lodging and Entertainment Services
• Travel facilitation
– Travel agents
» Travel agencies
• Services: 3 records found.
–
–
–
AirFares
Returns air fares from netviagens.com travel agent
Hotel reservations
Reservations for hotels in Asia, Australia and New Zealand
Your Vacation Specialists
Web enabled vacation information
• Providers: 2 records found.
* Search carried out in one of the Universal Business Registries
Search for services to book an air ticket
(using keywords)*
•
air ticket
– 1 record with name air tickets booking
•
airticket, ticketbooking, airtravel, air travel, travel agent, airticketbooking, air
ticket booking, travel agency, travelagency
– 0 records were returned
•
travelagent
– 1 record with name travelagent test
• 4 services: BookFlight, cancelFlightBooking etc.
• Descriptions say that both these services are “XML based Web services”
• No URL for WSDL
•
Travel
– 15 records. Purpose/functionality understood from descriptions
•
•
•
•
•
•
2 services : TravelBooks
4 services : TravelInformation
2 services : Reservation and cancallation of travel tickets
1 service : Emergency Services for travellers
1 service : Travel documentation and itinerary
5 services : Description is ambiguous/not present
* Search carried out in one of the
Universal Business Registries
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
subClassOf
WSDL
subClassOf
Class
Class
Data
Operations
subClassOf
subClassOf
subClassOf
Use of ontologies enables
shared understanding
between the service provider
and service requestor
subClassOf
Class
Class
Class
Class
Ticket
Information
Confirmation
Message
Ticket
Booking
Ticket
Cancellation
Operation:
buyTicket
Input1:
<Operation>
TravelDetails
Output1:
Confirmation
<Input1>
UDDI
Operation:
Search
cancelTicket
<Output1>
Input1:
TravelDetails
Output1:
Service Template
Publish
Confirmation
Annotations
For simplicity of depicting, the ontology is shown with classes for both operation and data
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 of
each operation
– Preconditions and effects 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
Annotation Syntax*
• Each Operation in WSDL is annotated using an fully
qualified attribute name-value pair in the operation
element under portType element. The attribute name is
operation-concept
• Each Message part is annotated using a fully qualified
attribute name-value pair in the part element under
message element. The attribute name is onto-concept
• Preconditions and effects are respectively represented
using fully qualified additional tags with the names
precondition and effect. These elements have two attributes
name (optional) and precondition-concept (or effectconcept). Each operation can have multiple precondition
and effect elements.
* conforms to extensibility support in WSDL version 1.2
WSDL Annotation Example
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
xmlns:TravelOnto=lsdis.cs.uga.edu//METEORS/TravelServiceOntology.daml ….. >
<wsdl:message name="OperationRequest">
<wsdl:part name="in0"
type="tns:TravelDetails" LSDISExt:ontoconcept= “TravelOnto:TicketInformation"/>
</wsdl:message>
<wsdl:portType name="TravelArragement">
<wsdl:operation name="buyTicket" parameterOrder="in0"
LSDISExt:operation-concept=“TravelOnto:TicketBooking">
<wsdl:input message="intf:OperationRequest" name="buyTicketRequest"/>
<wsdl:output message="intf:OperationResponse" name="buyTicketResponse"/>
<LSDISExt:precondition name="ValidCreditCard"
LSDISExt:precondition-concept=“TravelOnto:ValidCreditCard"/>
</wsdl:operation>
</wsdl:definitions>
Semantics in UDDI
• tModels are used to categorize and characterize
service entries in UDDI (limited form of
semantics)
• Our approach categorizes* (using metadata
constructs tModels and CategoryBags) the
services in UDDI based on the semantic
annotations
* similar to [Paolucci et al.]
Semantic Categorization of
Services in UDDI*
For the example discussed earlier: Travel Arrangement Service with
two operations buyTicket and cancelTicket
Service
CategoryBag
KeyedReferenceGroup
TmodelKey:OperationalTModelKey, Value:TicketBooking, Name:buyTicket
TmodelKey:InputTModelKey, Value:TicketInformation
(SemanticGroupTModelKey)
KeyedReferenceGroup
TmodelKey:OutputTModel, Value:ConfirmationMessage
(SemanticGroupTModelKey)
TmodelKey:OperationalTModelKey, Value:TicketCancellation,
Name:cancelTicket
TmodelKey:InputTModelKey, Value:TicketInformation
TmodelKey:OutputTModel, Value:ConfirmationMessage
* conforming to UDDI Version 3 spec [UDDI-v3]
Semantic Categorization of
Services in UDDI*
Functional/Operational Semantics: Operation-ontology mapping in WSDL for buyTicket operation
<operation name=“buyTicket” operation-concept=“TravelOnto:TicketBooking”>
Service
CategoryBag
KeyedReferenceGroup
TmodelKey:OperationalTModelKey, Value:TravelOnto:TicketBooking, Name:buyTicket
TmodelKey:InputTModelKey, Value:TravelOnto:TicketInformation
(SemanticGroupTModelKey)
KeyedReferenceGroup
TmodelKey:OutputTModelKey, Value:GeneralTradeOnto:ConfirmationMessage
(SemanticGroupTModelKey)
TmodelKey:OperationalTModelKey, Value: TravelOnto:TicketCancellation,
Name:cancelTicket
TmodelKey:InputTModelKey, Value: TravelOnto:TicketInformation
TmodelKey:OutputTModelKey, Value: GeneralTradeOnto: ConfirmationMessage
* conforming to UDDI Version 3 spec [UDDI-v3]
Semantic Categorization of
Services in UDDI*
Data/Information Semantics: Input Message part-ontology mapping in WSDL for buyTicket operation
<part name=“input1” type=“tns:TravelDetails” onto-concept=“TravelOnto:TicketInformation”>
Service
CategoryBag
KeyedReferenceGroup
TmodelKey:OperationalTModelKey, Value:TicketBooking, Name:buyTicket
TmodelKey:InputTModelKey, Value:TravelOnto:TicketInformation
(SemanticGroupTModelKey)
KeyedReferenceGroup
TmodelKey:OutputTModelKey, Value: GeneralTradeOnto:ConfirmationMessage
(SemanticGroupTModelKey)
TmodelKey:OperationalTModelKey, Value:TravelOnto:TicketCancellation,
Name:cancelTicket
TmodelKey:InputTModelKey, Value: GeneralTradeOnto:TicketInformation
TmodelKey:OutputTModel, Value: GeneralTradeOnto:ConfirmationMessage
* conforming to UDDI Version 3 spec [UDDI-v3]
Semantic Categorization of
Services in UDDI*
Data/Information Semantics: Output Message part-ontology mapping in WSDL for buyTicket operation
<part name=“output” type=“xsd:String” onto-concept=“GeneralTradeOnto:ConfirmationMessage”>
Service
CategoryBag
KeyedReferenceGroup
TmodelKey:OperationalTModelKey, Value:TicketBooking, Name:buyTicket
TmodelKey:InputTModelKey, Value:TravelOnto:TicketInformation
(SemanticGroupTModelKey)
KeyedReferenceGroup
TmodelKey:OutputTModelKey, Value: GeneralTradeOnto:ConfirmationMessage
(SemanticGroupTModelKey)
TmodelKey:OperationalTModelKey, Value:TravelOnto:TicketCancellation,
Name:cancelTicket
TmodelKey:InputTModelKey, Value: GeneralTradeOnto:TicketInformation
TmodelKey:OutputTModel, Value: GeneralTradeOnto:ConfirmationMessage
* conforming to UDDI Version 3 spec [UDDI-v3]
Discovery using UDDI V1 API
• Our implementation used UDDI Version 1 API
– KeyedReferenceGroups are not supported
– Each operation is grouped with its operation-concept, input and output ontoconcepts each as a keyedReference in the keyedReferenceVector as
tModelKey = “OpTModel” KeyValue = “operation-concept” KeyName = “OpName”
tModelKey = “InTModel” KeyValue = “onto-concept”
KeyName = “OpName”
tModelKey = “OutTModel” KeyValue = “onto-concept”
KeyName = “OpName”
OpTModel: Key for the tModel representing functional semantics of the operation named “OpName” in a
WSDL file linked to the UDDI entry
InTModel: Key for the tModel representing semantics of the inputs of the operation named “OpName” in
the WSDL
OutTModel: Key for the tModel representing semantics of the outputs of the operation named “OpName”
in the WSDL
operation-concept: Fully qualified Id of a class in a functional ontology represented by OpTModel
onto-concept: Fully qualfied Id of a class in a ontology that is used to annotate inputs (or outputs)
represented by InTModel (or OutTModel)
Summary of Steps in Discovery
1.
Services selection based on the functional
requirements
•
2.
Using operation-ontology mapping
Ranking based on semantic similarity based on
input/output semantics of candidate services and
requirement template
•
3.
Using message part-ontology mapping
Optional step includes semantic similarity based on
semantics of preconditions/effects of the candidate
services and requirement template
•
Using precondition and effect tags
METEOR-S Web Service
Composition Framework (MWSCF)
- needed for the world where business processes never stop changing.
UDDI
MWSCF Architecture
UDDI
Process Execution
1. Validation and deployment
2. Executing the process using a client
UDDI
UDDI
UDDI
Execution
Engine
UDDI
Discovery Infrastructure
(MWSDI)
Process Designer
1. Template Construction
- interfaces
- services
Template
Builder
Process
Generator
- semantic activity templates
Process Designer
- other details
2. Process Generation
- Service discovery and selection
- Data flow
Repositories are used to store
Activity
Interfaces
Process
Templates
Ontologies
1. Web Service Interfaces
2. Ontologies
3. Process Templates
XML Repositories
Web Process Life-Cycle
Design
Create Process WSDL
Discovery
Find Matches
Create Process Template
and Add Activities
Find Ontologies &
Annotate Activity
Requirements
Add Control Flow
Rank Services
Select a Service
Composition
Execution
Add to Process
Generate Process
Data Transformation
Validate Syntax
Data Flow
Execute
Template Construction
• Process Template can be constructed with 3 types
of activities
Discovery not
needed
– Concrete Web Service Implementation
• activity is bound to Web service by linking it to a WSDL file and an
operation in it
– Web Service Interface
• activity is bound to a Web service interface by linking it to a interface
identifier (which is linked to a WSDL file ) and an operation in it
– Semantic Activity Template
• activity is semantically enriched by linking it to semantic
specifications of its inputs/outputs/functionality/precondition and
effects
Template Construction
• Process Template can be constructed with 3 types
of activities
– Concrete Web Service Implementation
• activity is bound to Web service by linking it to a WSDL file and an
operation in it
– Web Service Interface
QoS requirements
are specified too
• activity is bound to a Web service interface by linking it to a interface
identifier (which is linked to a WSDL file ) and an operation in it
– Semantic Activity Template
• activity is semantically enriched by linking it to semantic
specifications of its inputs/outputs/functionality/precondition and
effects
Template Construction (contd)
• Activities are linked by a control flow constructs
• Template can have protocol variables that do not
have any assignment
– These protocol variables are assigned a value (output of a WS)
during process generation
– Process generator will handle replacing the protocol variable with
a relevant container and message details
–
Example:
<case condition= “ (inventory-availability, '=', 'no') " >
will be converted into
<case condition = “ bpws:getContainerData('inventoryResponse', 'avail') = 'no' ”>
During process generation inventory-availability is manually assigned to output of
activity whose output container name is inventoryResponse and the output message
part name is avail
Activity as Concrete Web Service
Implementation
<invoke-activity name=“RoomReservation”
type=“ServiceImpl”
wsdl-URL=“http://lsdis.cs.uga.edu/proj/meteors/wsdl/Hotel.wsdl”
operation-name=“reserveRoom” />
Input, output messages, portType (of reserveRoom operation)
and targetNamespace details are extracted from the given
WSDL
Activity as Web Service Interface
<invoke-activity name=“RoomReservation”
type=“WSInterface”
tModel-id=“uuid:f4a6574b-49f4-a657-f908-45fa62354d84”
operation-name=“reserveRoom”
qos-spec=“qos-2” ranking-weight=“ranking-2”
discovery-URL=“http://westpoint.cs.uga.edu:8080/registryserver/RegistryServerServlet” />
Activity as Web Service Interface
<invoke-activity name=“RoomReservation”
type=“WSInterface”
tModel-id=“uuid:f4a6574b-49f4-a657-f908-45fa62354d84”
operation-name=“reserveRoom”
qos-spec=“qos-2” ranking-weight=“ranking-2”
discovery-URL=“http://westpoint.cs.uga.edu:8080/registryserver/RegistryServerServlet” />
All the services that implement the interface (a WSDL without service/binding/
port details identified by a tModel-id) are bound to the given tModel (using
binding template construct in UDDI). Discovery is based on this binding.
Activity as Web Service Interface
<invoke-activity name=“RoomReservation”
type=“WSInterface”
tModel-id=“uuid:f4a6574b-49f4-a657-f908-45fa62354d84”
operation-name=“reserveRoom”
qos-spec=“qos-2” ranking-weight=“ranking-2”
discovery-URL=“http://westpoint.cs.uga.edu:8080/registryserver/RegistryServerServlet” />
An interface may have multiple operations. The input, output messages,
portType details (of reserveRoom operation) and targetNamespace details
are extracted from the WSDL of the selected service during process generation.
Activity as Web Service Interface
<invoke-activity name=“RoomReservation”
type=“WSInterface”
tModel-id=“uuid:f4a6574b-49f4-a657-f908-45fa62354d84”
operation-name=“reserveRoom”
qos-spec=“qos-2” ranking-weight=“ranking-2”
discovery-URL=“http://westpoint.cs.uga.edu:8080/registryserver/RegistryServerServlet” />
Ranking of the discovered services are based on the QoS criteria expanded as
<qos name=“qos-2”> under <criteria> element in the process template
Activity as Web Service Interface
<invoke-activity name=“RoomResercation”
type=“WSInterface”
tModel-id=“uuid:f4a6574b-49f4-a657-f908-45fa62354d84”
operation-name=“reserveRoom”
qos-spec=“qos-2” ranking-weight=“ranking-2”
discovery-URL=“http://westpoint.cs.uga.edu:8080/registryserver/RegistryServerServlet” />
Ranking-weight will be expanded as <ranking-weights name=“ranking-2”>
under <criteria> in the template. It will have weights for different QoS critria.
Activity as Web Service Interface
<invoke-activity name=“RoomReservation”
type=“WSInterface”
tModel-id=“uuid:f4a6574b-49f4-a657-f908-45fa62354d84”
operation-name=“reserveRoom”
qos-spec=“qos-2” ranking-weight=“ranking-2”
discovery-URL=“http://westpoint.cs.uga.edu:8080/registryserver/RegistryServerServlet” />
Access URL of the UDDI registry may be given in the attribute
discovery-URL.
future work will aim to use a concept from Registries Ontology instead of discovery-URL
Activity as Web Service Interface
<invoke-activity name=“RoomReservation”
type=“WSInterface”
tModel-id=“uuid:f4a6574b-49f4-a657-f908-45fa62354d84”
operation-name=“reserveRoom”
qos-spec=“qos-2” ranking-weight=“ranking-2”
discovery-URL=“http://westpoint.cs.uga.edu:8080/registryserver/RegistryServerServlet” />
qos-spec, ranking-weight and discovery-URL attributes are optional
Discovery will be any of the UBRs by default
Weight for qos will be considered 0 if the qos-spec attribute is missing
Weight is distributed equally among different QoS criteria if ranking-weight is missing
Activity as Semantic Activity
Template
<invoke-activity name=“RoomReservation”
type=“SemanticTemplate”
semantic-spec=“RoomReservationServiceSemantics”
qos-spec=“qos-1”
ranking-weights=“ranking-1”
discovery-URL=“http://westpoint.cs.uga.edu:8080/registryserver/RegistryServerServlet” />
Activity as Semantic Activity
Template
<invoke-activity name=“RoomReservation”
type=“SemanticTemplate”
semantic-spec=“RoomReservationServiceSemantics”
qos-spec=“qos-1”
ranking-weights=“ranking-1”
discovery-URL=“http://westpoint.cs.uga.edu:8080/registryserver/RegistryServerServlet” />
Services that match the RoomReservationServiceSemantics are discovered
and ranked based on the Semantic Matching and QoS Matching
Semantic Specifications (Example)
<semantic-spec name=“RoomReservationServiceSemantics”>
<operation name=“reserve” operation-concept=“TravelOntology:LodgingReservation”/>
<input name=“Id” onto-concept=“LodgingOntology:LodgingTypeIdentifier”/>
<input name=“guest”onto-concept=“LodgingOntology:GuestDetails”/>
<input name=“indate” onto-concept=“LodgingOntology:CheckInDate”/>
<input name=“outdate” onto-concept=“LodgingOntology:CheckOutDate”/>
<input name=“payment” onto-concept=“FinanceOntology:PayType”/>
<input name=“details” onto-concept=“FinanceOntology:PaymentDetails”/>
<output name=“confirmation” onto-concept=“ShoppingAndServicesOntology:Confirmation”/>
</semantic-spec>
Functional/Operational Semantics
Semantic Specifications (Example)
<semantic-spec name=“RoomReservationServiceSemantics”>
<operation name=“reserve” operation-concept=“TravelOntology:LodgingReservation”/>
<input name=“Id” onto-concept=“LodgingOntology:LodgingTypeIdentifier”/>
<input name=“guest”onto-concept=“LodgingOntology:GuestDetails”/>
<input name=“indate” onto-concept=“LodgingOntology:CheckInDate”/>
<input name=“outdate” onto-concept=“LodgingOntology:CheckOutDate”/>
<input name=“payment” onto-concept=“FinanceOntology:PayType”/>
<input name=“details” onto-concept=“FinanceOntology:PaymentDetails”/>
<output name=“confirmation” onto-concept=“ShoppingAndServicesOntology:Confirmation”/>
</semantic-spec>
Input Semantics: Data/Information Semantics
Semantic Specifications (Example)
<semantic-spec name=“RoomReservationServiceSemantics”>
<operation name=“reserve” operation-concept=“TravelOntology:LodgingReservation”/>
<input name=“Id” onto-concept=“LodgingOntology:LodgingTypeIdentifier”/>
<input name=“guest”onto-concept=“LodgingOntology:GuestDetails”/>
<input name=“indate” onto-concept=“LodgingOntology:CheckInDate”/>
<input name=“outdate” onto-concept=“LodgingOntology:CheckOutDate”/>
<input name=“payment” onto-concept=“FinanceOntology:PayType”/>
<input name=“details” onto-concept=“FinanceOntology:PaymentDetails”/>
<output name=“confirmation” onto-concept=“ShoppingAndServicesOntology:Confirmation”/>
</semantic-spec>
Output Semantics: Data/Information Semantics
Sample Ontology
<daml:Class rdf:ID="AirTravel">
<daml:label>Air Travel</daml:label>
<daml:comment>Air Travel Ontology</daml:comment>
</daml:Class>
<daml:Class rdf:ID="Airport">
<daml:label>Airport</daml:label>
<daml:comment>Airport Class</daml:comment>
<daml:subClassOf rdf:resource="#AirTravel"/>
</daml:Class>
………………….
<daml:Class rdf:ID="Tickets">
<daml:label>Tickets</daml:label>
<daml:comment>Tickets Ontology</daml:comment>
</daml:Class>
<daml:Class rdf:ID="TravelType">
<daml:label>Travel type</daml:label>
<daml:comment>Travel type for the trip</daml:comment>
<daml:subClassOf rdf:resource="#Itinerary"/>
</daml:Class>
Ranking Scheme
• Helps in Service selection
• Discovery mechanism is supplemented with a
ranking model and scheme
• Activity types
– WSInterface
• Uses QoS requirements for ranking
– SemanticTemplate
• Uses Semantic and QoS requirements for ranking
• Overall ranking value is the Weighted arithmetic
mean of Semantic and QoS Criteria Matching
values
Semantic Matching
i = 1  Functionality of the services
i = 2  Inputs of the services
i = 3  Outputs of the services
i = 4  Preconditions of the services
i = 5  Effects of the services
Wi  Weights assigned for each of i
Mi  Semantic Matching value of i th
criterion between activity requirements
and service description
QoS criteria matching
i = 1 Task Delay Time of the services
Wi  Weights assigned for each of i
i = 2  Task Process Time of the services
Mi  QoS criteria matching value of i th
criterion between activity requirements
and service description
i = 3  Task Realization Cost of the services
i = 4  Task Reliability of the services
Reference: [Cardoso et. al]
Using the framework
Template
Repository
Template
Executable
BPEL
Process
Customized
Template
Process
Generator
BPEL Execution
Engine
Manual service selection & data flow
Template Construction
Process Generation
Advantages of SPT in the framework
• Flexible and rapid approach to process composition
– Configuration and re-use of templates
– Process is not bound to any Web service interfaces or implementations.
(partners/services can be dynamically changed)
– Template/Process designer need not perform discovery of services.
Discovery can be delegated to the tool
• Well defined semantics for each activity
– Using ontologies
– Richer description of semantics of activities
• Can be generated in executable process in any standard
• Process re-design is easier
• Can be advertised/published as reference/business models
for reuse across vertical industry segments
Testing
Conclusions
• Present Problems in Process Composition
– Static discovery of Web Services
– Design/deployment-time binding of Web services
– Process Composition is based on interfaces of participating services
• Proposition
– Semantics is the enabler to address the problems of scalability,
heterogeneity (syntactic and semantic), machine understandability
faced by Web services
• Semantics for Web Services
– Semantics can be applied to different layers of Web Services
conceptual stack
– Semantics for Web Services can be categorized into at least 4 different
dimensions namely Data, Functional, Execution and Quality (QoS).
Conclusions
(contd)
• Semantic Web Process Composition Framework
– Utilizes Data, Functional, QoS Semantics during template
construction and service discovery
– Dynamic discovery and deployment-time binding
– Template can be agnostic of the interfaces of participating services
– Semi-automatic generation of executable processes based on
selected services
• Results from preliminary testing
– Semantic discovery is better in locating semantically appropriate
services in comparison with keyword/taxonomy based present
discovery mechanisms supported by UDDI
– Semantic Process Template (SPT) is helpful to capture the
semantics of activities in a process and can be generated into an
executable process preserving the semantics specified in the
template
Future Work
• Specifying collaboration/conversation needed for or
expected from an activity in the SPT
• Mapping the template to concurrency formalisms (State
Machines/Petri nets) to specify Execution Semantics in the
template
• Using a SPT in conjunction with an activity in another SPT
• Incorporating e-business aspects like SLAs, negotiation
and contracts in the process template and service discovery
• Specifying goal definition (using UML) as a part of the
template and developing an user interface for this purpose
References
•
•
•
•
•
[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
•
•
•
Questions and Comments
Thank You !