the metoer-s framework for semantic web process composition kaarthik sivashanmugam large scale...
TRANSCRIPT
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
• 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
• 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
Web Service Conceptual Stack1
Description
Messaging
Network
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
Messaging:(SOAP)– XML based messaging protocol
Network:(HTTP)– Network protocol
1 [Kreger]
Web Service Conceptual Stack1
Publication:(UDDI)– To make service descriptions available for search
Discovery:(UDDI)
– To locate service descriptions Publication
Discovery
Description
Messaging
Network
Flow
Flow:(BPEL4WS, WSCI etc.)– To compose web services to form a composite web service / process
1 [Kreger]
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
Workflows
GlobalEnterprise Inter-Enterprise
Web Processes
E-Services
Globalization of Processes
DistributedWorkflows
B2B
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
Publication
Discovery
Description
Messaging
Network
Flow
Description Layer: 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
Discovery
Description
Messaging
Network
Flow
Publication and Discovery Layers: 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 the1. properties of each registry2. 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..)
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 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
Publication
Discovery
Description
Messaging
Network
Flow
MWSDI: Scalable Infrastructure of Registries for Semantic publication and discovery of Web Services
MWSDI: Semantic Annotation of WSDL (WSDL-S)
MWSCF: Semantic Web Process Composition Framework
Semantics for Web Services
• Data/Information 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
• 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– 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
Data/ Information
Semantics
Development/ Description/ Annotation WSDL, WSEL
DAML-S
Meteor-S (WSDL Annotation)
Publication/ Discovery
UDDI
WSIL, DAML-S
METEOR-S (P2P model of registries)
Composition
BPEL, BPML, WSCI, WSCL,
DAML-S, METEOR-S
(SCET,SPTB)
Execution
BPWS4J, Commercial BPEL Execution Engines,
Intalio n3, HP eFlow
Semantics for Web Service Life-Cycle
Data/ Information
Semantics
Publication/ Discovery
WSDL, WSEL
DAML-S
Meteor-S (WSDL Annotation)
UDDI
WSIL, DAML-S
METEOR-S (P2P model of registries)
BPWS4J, Commercial BPEL Execution Engines,
Intalio n3, HP eFlow
Development/ Description/ Annotation
Composition
Execution
BPEL, BPML, WSCI, WSCL,
DAML-S, METEOR-S
(SCET,SPTB)
Semantics for Web Service Life-Cycle
Functional/ Operational
Semantics
Publication/ Discovery
WSDL, WSEL
DAML-S
Meteor-S (WSDL Annotation)
UDDI
WSIL, DAML-S
METEOR-S (P2P model of registries)
BPWS4J, Commercial BPEL Execution Engines,
Intalio n3, HP eFlow
Development/ Description/ Annotation
Composition
Execution
BPEL, BPML, WSCI, WSCL,
DAML-S, METEOR-S
(SCET,SPTB)
Semantics for Web Service Life-Cycle
QoSSemantics
Publication/ Discovery
WSDL, WSEL
DAML-S
Meteor-S (WSDL Annotation)
UDDI
WSIL, DAML-S
METEOR-S (P2P model of registries)
BPWS4J, Commercial BPEL Execution Engines,
Intalio n3, HP eFlow
Development/ Description/ Annotation
Composition
Execution
BPEL, BPML, WSCI, WSCL,
DAML-S, METEOR-S
(SCET,SPTB)
Semantics for Web Service Life-Cycle
ExecutionSemantics
Publication/ Discovery
WSDL, WSEL
DAML-S
Meteor-S (WSDL Annotation)
UDDI
WSIL, DAML-S
METEOR-S (P2P model of registries)
BPWS4J, Commercial BPEL Execution Engines,
Intalio n3, HP eFlow
Development/ Description/ Annotation
Composition
Execution
BPEL, BPML, WSCI, WSCL,
DAML-S, METEOR-S
(SCET,SPTB)
Semantics for Web Service Life-Cycle
Publication/ Discovery
WSDL, WSEL
DAML-S
Meteor-S (WSDL Annotation)
UDDI
WSIL, DAML-S
METEOR-S (P2P model of registries)
BPWS4J, Commercial BPEL Execution Engines,
Intalio n3, HP eFlow
Semantics Required for Web Processes
ExecutionSemantics
QoSSemantics
Functional/ Operational
Semantics
Data/ Information
Semantics
Development/ Description/ Annotation
Composition
Execution
BPEL, BPML, WSCI, WSCL,
DAML-S, METEOR-S
(SCET, SPTB)
Semantics for Web Service Life-Cycle
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.]
Service Discovery
METEOR-S Web Service Discovery Infrastructure (MWSDI)
- uses Functional, Data and QoS semantics
Service Selection
METEOR-S Web Service Discovery Infrastructure (MWSDI)
- uses Functional, Data and QoS semantics
Search retrieves lot of services (irrelevant results included)
• Which service to select ?
• How to select?
UBR
Registry is universal and provides non-semantic search
Keyword match, taxonomy
The problem in discovery..
Registries are categorizedSelect relevant registries
(semantic filtering)
Select service(s) of interest
DomainRegistry
Registry is domain specific and supports semantic search
Ontology
Scalable Solution..
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 reservationsReservations for hotels in Asia, Australia and New Zealand
– Your Vacation SpecialistsWeb 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
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 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 effect-concept). 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*
Service
KeyedReferenceGroup(SemanticGroupTModelKey)
KeyedReferenceGroup(SemanticGroupTModelKey)
CategoryBag TmodelKey:OperationalTModelKey, Value:TicketBooking, Name:buyTicket
TmodelKey:InputTModelKey, Value:TicketInformation
TmodelKey:OutputTModel, Value:ConfirmationMessage
* conforming to UDDI Version 3 spec [UDDI-v3]
TmodelKey:OperationalTModelKey, Value:TicketCancellation, Name:cancelTicket
TmodelKey:InputTModelKey, Value:TicketInformation
TmodelKey:OutputTModel, Value:ConfirmationMessage
For the example discussed earlier: Travel Arrangement Service with two operations buyTicket and cancelTicket
Semantic Categorization of Services in UDDI*
Service
KeyedReferenceGroup(SemanticGroupTModelKey)
KeyedReferenceGroup(SemanticGroupTModelKey)
CategoryBag TmodelKey:OperationalTModelKey, Value:TravelOnto:TicketBooking, Name:buyTicket
TmodelKey:InputTModelKey, Value:TravelOnto:TicketInformation
TmodelKey:OutputTModelKey, Value:GeneralTradeOnto:ConfirmationMessage
TmodelKey:OperationalTModelKey, Value: TravelOnto:TicketCancellation, Name:cancelTicket
TmodelKey:InputTModelKey, Value: TravelOnto:TicketInformation
TmodelKey:OutputTModelKey, Value: GeneralTradeOnto: ConfirmationMessage
Functional/Operational Semantics: Operation-ontology mapping in WSDL for buyTicket operation
<operation name=“buyTicket” operation-concept=“TravelOnto:TicketBooking”>
* conforming to UDDI Version 3 spec [UDDI-v3]
Semantic Categorization of Services in UDDI*
Service
KeyedReferenceGroup(SemanticGroupTModelKey)
KeyedReferenceGroup(SemanticGroupTModelKey)
CategoryBag TmodelKey:OperationalTModelKey, Value:TicketBooking, Name:buyTicket
TmodelKey:InputTModelKey, Value:TravelOnto:TicketInformation
TmodelKey:OutputTModelKey, Value: GeneralTradeOnto:ConfirmationMessage
TmodelKey:OperationalTModelKey, Value:TravelOnto:TicketCancellation, Name:cancelTicket
TmodelKey:InputTModelKey, Value: GeneralTradeOnto:TicketInformation
TmodelKey:OutputTModel, Value: GeneralTradeOnto:ConfirmationMessage
Data/Information Semantics: Input Message part-ontology mapping in WSDL for buyTicket operation
<part name=“input1” type=“tns:TravelDetails” onto-concept=“TravelOnto:TicketInformation”>
* conforming to UDDI Version 3 spec [UDDI-v3]
Semantic Categorization of Services in UDDI*
Service
KeyedReferenceGroup(SemanticGroupTModelKey)
KeyedReferenceGroup(SemanticGroupTModelKey)
CategoryBag TmodelKey:OperationalTModelKey, Value:TicketBooking, Name:buyTicket
TmodelKey:InputTModelKey, Value:TravelOnto:TicketInformation
TmodelKey:OutputTModelKey, Value: GeneralTradeOnto:ConfirmationMessage
TmodelKey:OperationalTModelKey, Value:TravelOnto:TicketCancellation, Name:cancelTicket
TmodelKey:InputTModelKey, Value: GeneralTradeOnto:TicketInformation
TmodelKey:OutputTModel, Value: GeneralTradeOnto:ConfirmationMessage
Data/Information Semantics: Output Message part-ontology mapping in WSDL for buyTicket operation
<part name=“output” type=“xsd:String” onto-concept=“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 onto-
concepts 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• Using operation-ontology mapping
2. Ranking based on semantic similarity based on input/output semantics of candidate services and requirement template
• Using message part-ontology mapping
3. 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.
ActivityInterfaces
ProcessTemplates
Ontologies
XML Repositories
Repositories are used to store
1. Web Service Interfaces
2. Ontologies
3. Process Templates
TemplateBuilder
ProcessGenerator
Process Designer
Process Designer
1. Template Construction
- interfaces
- services
- semantic activity templates
- other details
2. Process Generation
- Service discovery and selection
- Data flow
MWSCF ArchitectureUDDI
UDDI
UDDI
UDDIUDDI UDDI Execution
EngineDiscovery Infrastructure
(MWSDI)
Process Execution
1. Validation and deployment
2. Executing the process using a client
Web Process Life-Cycle
Find Matches
Rank Services
Select a Service
Discovery
Add to Process
Data Transformation
Data Flow
Composition
Generate Process
Validate Syntax
Execute
Execution
Design
Create Process WSDL
Create Process Templateand Add Activities
Add Control Flow
Find Ontologies &Annotate Activity
Requirements
Template Construction
Discovery not needed
• 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• 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
QoS requirementsare specified too
• 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• 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
Input, output messages, portType (of reserveRoom operation) and targetNamespace details are extracted from the given WSDL
<invoke-activity name=“RoomReservation”
type=“ServiceImpl”
wsdl-URL=“http://lsdis.cs.uga.edu/proj/meteors/wsdl/Hotel.wsdl”
operation-name=“reserveRoom” />
Activity as Concrete Web Service Implementation
<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/registry- server/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/registry- server/RegistryServerServlet” />
Activity as Web Service Interface
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.
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.
<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/registry- server/RegistryServerServlet” />
Activity as Web Service Interface
Ranking of the discovered services are based on the QoS criteria expanded as <qos name=“qos-2”> under <criteria> element in the process template
<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/registry- server/RegistryServerServlet” />
Activity as Web Service Interface
Ranking-weight will be expanded as <ranking-weights name=“ranking-2”> under <criteria> in the template. It will have weights for different QoS critria.
<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/registry- server/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/registry- server/RegistryServerServlet” />
Activity as Web Service Interface
Access URL of the UDDI registry may be given in the attributediscovery-URL.
future work will aim to use a concept from Registries Ontology instead of discovery-URL
<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/registry- server/RegistryServerServlet” />
Activity as Web Service Interface
qos-spec, ranking-weight and discovery-URL attributes are optional
Discovery will be any of the UBRs by defaultWeight for qos will be considered 0 if the qos-spec attribute is missingWeight 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/registry- server/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/registry- server/RegistryServerServlet” />
Services that match the RoomReservationServiceSemantics are discovered and ranked based on the Semantic Matching and QoS Matching
Functional/Operational Semantics
<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>
Semantic Specifications (Example)
Input Semantics: Data/Information Semantics
<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>
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
Semantic Specifications (Example)
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
i = 2 Task Process Time of the services
i = 3 Task Realization Cost of the services
i = 4 Task Reliability of the services
Wi Weights assigned for each of i
Mi QoS criteria matching value of i th criterion between activity requirements and service description
Reference: [Cardoso et. al]
Using the framework
TemplateRepository
ProcessGenerator
TemplateCustomized
Template
ExecutableBPEL
Process
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 !