Transcript Semantic Web Services and Processes

Constraint Driven Web
Service Composition in
METEOR-S
Rohit Aggarwal
LSDIS Lab, University of Georgia
Major Advisors: Dr. Amit P. Sheth
Dr. John A. Miller
Committee: Dr. Maria Hybinette
Dr. William S. York
2
Acknowledgements

Advisory Committee





Dr. Amit P. Sheth (Major Advisor)
Dr. John A. Miller (Major Advisor)
Dr. Maria Hybinette
Dr. William S. York
LSDIS Student Members

Kunal Verma, Preeda Rajasekaran, Meena
Nagarajan, Willie Milnor, Ranjit Mulye, Satya
Sahoo and others
2
3
Outline



Use Case
Semantic Web Services
METEOR-S Project @LSDIS Lab


Front-End
Back-End





Abstract Process Designer
Abstract Process Annotator
Discovery Engine
Constraint Analyzer and Optimizer
Service Binder
3
4
Use Case – Present Scenario





In supply chains, businesses have to be statically
bound to the partners
Difficult to change the existing setup to deal with a
new partner
Businesses cannot choose partners dynamically
based on the client request
There is no provision to choose partners based on
the Quality of Service (QoS) parameters.
There is no facility to select the optimal set of
partners for a specific process
4
5
Solution




Need for a system which will allow
businesses to select partners dynamically
Ability to seamlessly incorporate any new
partners in future
Ability to select partners based on client’s
constraints e.g. supply-time, cost
Ability to select the optimal set of partners
5
http://www.daml.org/services/use-cases/architecture/QosUseCase/DynamicQoSWebProc-SWSA-UseCase-v1.htm
6
This is what is required
Activity Choreography
Web Service Composition
6
7
Requirements of such a system

Different levels of dynamism require different
technologies:



The plug-and-play feature wherein services can
be selected and replaced automatically requires
Web service Semantics
To be able to select Web services that are optimal
and satisfy client’s constraints requires the use of
a Constraint Analyzer/Optimizer
To create an executable process from an abstract
process (no bindings), we need a service binder
to bind the process to concrete Web services.
7
8
Semantic Web Services


Web services were designed to be loosely
coupled and inter-operable
Traditional Web services require a huge
amount of human interaction for integration of
multiple applications


Because it requires an understanding of data and
functions of the involved entities
Semantic Web technologies add annotations
to data and functions using ontologies
8
9
Semantic Web Services

This helps create a machine processable
information which can be used for automated
service publication, service discovery, service
composition, negotiation and execution
 In other words:
Semantic Web Services = Web Services + Semantic Web Technology
9
10
Traditional Web Service
Input ( name=isbn, type=int)
Web Service
getPrice
Traditional
Input ( name=title, type=String)
Input ( name=year, type=int)
Output ( name=price, type=float)
10
11
Ontology
“An ontology is a specification of a conceptualization.”
Tom Gruber
Ontologies consists of:
- Concepts
- Relations (between concepts)
- Instances (specific, non generic concepts)
- Axioms (knowledge using logics)
Used for:
- Defining knowledge
- Communication
- Knowledge reuse
11
12
Semantic Web Service
Operation = Ont#getPrice
Functional Ontology
Web Service
getPrice
Semantic
Input(name=year,
type=Ont#PrintYear)
Domain Ontology
Location=Georgia
Category=Book Stores
Supply Time=2 days
Availability = 0.9
QoS Ontology
12
13
Semantic Web Services

SWSA and SWSL Committee



To support the development of Semantic Web Services
Architecture and Language, respectively.
To develop standardized ways of conceptualization and
organizing semantic information about services.
Semantic markup of Service definitions



Enables definitions to be machine processable
Provides clear and unambiguous meaning of service
functionality
Enhances automation in service discovery and composition
SWSA: http://www.daml.org/services/swsa/
SWSL: http://www.daml.org/services/swsl/
13
14
METEOR-S

Uses semantics in the entire life cycle of Semantic
Web Services and Processes




Semantics in Annotation, Publication, Discovery and
Constraint Driven Composition of Web Services
Comprehensive use of semantics (Data, Functional,
QoS and Execution)
Integrates and co-exists with current industry tools
E.g. Eclipse BPWS4J Editor, BPEL4WS Execution
Engine
Consistent with and builds upon current industry
standards and recommendations
14
15
Industry Standards
Industry
Standard
Standard
From
Version
Used in
Latest
Version
METEOR-S
SOAP
W3C
1.2
1.2
WSDL
W3C
1.1
1.1
UDDI
OASIS
2
3
BPEL
OASIS
1.1
1.1
15
16
METEOR-S Architecture
Front-End
Back-End
16
17
METEOR-S Back End





Abstract Process Designer
Abstract Process Annotator
Enhanced UDDI
Discovery Engine
Constraint Analyzer


Optimizer
Service Binder
17
Thanks to Kunal Verma for his novel ideas, suggestions and support throughout the project
18
METEOR-S
uses
Abstract Process
Designer
(BPWS4J Editor, IBM)
Abstract
Process
Abstract
BPEL
Process
Process/
Annotation
Repository
Process Annotation
Tool
Service
Template (s)
BPWS4J
Execution
Engine
(IBM)
Constraint
Analyzer
Discovery Engine
Request
query
Optimized
Service Set
Executable
BPEL
Process
Service
Binder
Enhanced
UDDI
Ranked Response
Advertisement
Annotated
Source Code
Legend
Non-METEOR-S
components
Semantic
Description
Generator
Annotated WSDL 1.1
WSDL-S
OWL-S
Publishing
Interface
Semantic Web
Service Designer
18
19
Abstract Process Designer

Abstract Processes is a placeholder for a set
of services matching the abstract services’
template




IBM BPWS4J editor version 2.1
Eclipse plug-in
Provides a graphical user interface to compose
abstract processes
Topology of the service process is largely
fixed, however, actual service selection may
be highly dynamic
19
20
Sample Executable 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="tns" partnerLinkType="ns2:orderPartnerSLT"/>
<partnerLink name="orderPartner2" xmlns:ns8="tns"partnerLinkType="ns8:orderPartner2SLT"/>
</partnerLinks>
<variables>
<variable name="userRequest" xmlns:ns3="tns" messageType="ns3:userRequest"/>
<variable name="userResponse" xmlns:ns4="tns" messageType="ns4:userResponse"/>
<variable name="orderInput" xmlns:ns5="http://128.192.251.239:8080/axis/services/IntelService?wsdl"
messageType="ns5:RequestPurchaseOrderRequest"/>
<variable name="orderOutput" xmlns:ns6="http://128.192.251.239:8080/axis/services/IntelService?wsdl"
messageType="ns6:RequestPurchaseOrderResponse"/>
</variables>
<flow name="start">
<receive name="receiveRequest" partnerLink="User" portType="tns:UserPT" operation="getUser" variable="userRequest" createInstance="yes"/>
<invoke name="orderPArt" partnerLink="orderPartner" xmlns:ns7="http://128.192.251.239:8080/axis/services/CiscoService?wsdl"
portType="ns7:CiscoService" operation="RequestPurchaseOrder" inputVariable="orderInput" outputVariable="orderOutput">
</invoke>
<invoke name="orderPArt2" partnerLink="orderPartner2" xmlns:ns9="http://128.192.251.239:8080/axis/services/IntelService?wsdl"
portType="ns9:IntelService" operation="RequestPurchaseOrder" inputVariable="orderInput" outputVariable="orderOutput">
</invoke>
<reply name="sendResponse" partnerLink="User" portType="tns:UserPT" operation="getUser" variable="userResponse"/>
20
</flow>
</process>
21
Sample Abstract 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>
<variables>
<variable name="userRequest" xmlns:ns3="tns" messageType="ns3:userRequest"/>
<variable name="userResponse" xmlns:ns4="tns" messageType="ns4:userResponse"/>
<variable name="orderInput" xmlns:ns5="?" messageType="ns5:?"/>
<variable name="orderOutput" xmlns:ns6="?" messageType="ns6:?"/>
</variables>
<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>
21
22
Differences
22
23
Abstract Process Annotator




Parses the abstract BPEL and extracts
information about activities
Each activity in the abstract process can be
represented by a Service Template
The process annotator can annotate each
activity or in other words, provide information
for the Service Template
The Service Templates are sent to the
discovery engine which finds matching
services from the service registry.
23
Thanks to Matt Ross for helping with this module
24
Abstract Process Annotator
24
25
Discovery Engine

Input


Output


Semantic service template built by process
annotator
List of services ranked by relevance to query
Ranking algorithm employed
-Matches operation/input/output semantic concepts
of Published Services Vs. service template.
-Checks for common properties, siblings, common
parent to find relations between ontological
concepts
25
26
Enhanced UDDI
Annotated Java Source Code
Enhanced UDDI
@interface ( domain = "naics:Computer and Electronic Product Manufacturing" ,
description = "Computer PowerSupply Battery Buy Quote Order Status ",
businessService = "Battery Outlet")
public interface BatterySupplier {
@operation (name = "placeOrder", action = "rosetta: #RequestPurchaseOrder " )
@parameters ({
@inParam ( name = "order", element = "rosetta: #PurchaseOrderRequest
@outParam( name="orderConfirmation",
element="rosetta: #PurchaseOrderConfirmation" )
})
PurchaseOrderConfirmation RequestPurchaseOrder (PurchaseOrderRequest order );
.
.
.
26
Thanks to Preeda Rajasekaran for helping with discovery and structuring of E-UDDI
27
Ordinary Discovery vs. Semantic
Discovery
Semantic Web Service Discovery
Traditional Web service discovery is based on
keyword match on description of Web services.
Setup
Test Cases








To find match based on Location
To find match based on Category
To find match against more specific concepts
To find match against more general concepts
27
Thanks to Satya Sahoo for helping with annotating Web services for testing discovery
28
Recall
{ number of ‘relevant’ services discovered/
number of ‘relevant’ services in registry}
1.00
0.90
0.80
0.70
0.60
Keyword based search
Semantic search
0.50
0.40
0.30
0.20
0.10
28
0.00
Case1
Case2
Case3
Case4
29
Precision
{number of ‘relevant’ services discovered/
number of services discovered}
1.00
0.90
0.80
0.70
0.60
Keyword based search
0.50
Semantic search
0.40
0.30
0.20
0.10
29
0.00
Case1
Case2
Case3
Case4
30
False Positives
0.40
0.35
0.30
0.25
Keyword based search
0.20
Semantic search
0.15
0.10
0.05
30
0.00
Case1
Case2
Case3
Case4
31
False Negatives
0.80
0.70
0.60
0.50
Keyword based search
0.40
Semantic search
0.30
0.20
0.10
31
0.00
Case1
Case2
Case3
Case4
32
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.
32
33
Integer Linear Programming
Constraints are converted into linear equalities/linear
inequalities over a set of discovered services.
 We have used LINDO API which helps in solving ILP
problems.
e.g. if three services match the service template with a
constraint that cost<=500 and minimum
A+B+C=1
caA + cbB + ccC <= 500
And minimize (caA + cbB + ccC) as objective function
(where A, B and C are binary)

33
Thanks to William Milnor for helping with this module
34
Working of Constraint Analyzer
Abstract Process
Process
Supply-time <= 4
Supply-time <= 3
Supply-time<=7
Cost <=200
Cost <=300
Cost<=400
Assuming equal weights on
both constraints
Constraint
Analyzer
ST=2
C=100
ST=3
C=180
Objective Function
Decreasing Optimality
ST=3
C=180
ST=3
C=200
ST=1
C=300
ST=2
ST=3
C=250
ST=3
C=250
Optimizer
ST=4
C=200
ST=4
C=200
Min (supply-time + cost)
C=100
34
35
Service Binder



The constraint analyzer and optimizer finds
the optimal service sets.
The service set chosen by the user is then
sent to the service binder which binds the
services to the process.
The service binder produces an executable
BPEL and a process WSDL required by the
BPWS4J engine for deployment.
35
36
Service Binder
Abstract Process
ST=2
C=100
Process
Supply-time <= 4
Supply-time <= 3
Supply-time<=7
Cost <=200
Cost <=300
Cost<=400
ST=3
C=250
Optimal Service Set
Service
Binder
Process
WSDL
Executable BPEL Process
Thanks to Yin Xiong and Meena Nagarajan for helping with Binding
36
37
Demo
37
38
Abstract Process/
Executable Process
Annotated Abstract Process
Response
Client
Request
Business
Concrete
Service
Service
Template
Flow
Service
Template
Executable Process
Response
Client
Request
Business
Concrete
Service
Concrete
Service
Flow
Concrete
Service
38
39
Related Work

OWL-S: OWL-based Web service ontology
Leading initiative in the area of Semantic
Web Services
http://www.daml.org/services/owl-s/1.0/

WSMO (Web Services Modeling Ontology)
http://www.wsmo.org/
39
40
OWL-S 1.1

Represents Semantic Web Services via 4 files

Each service is created as an instance of service
ontology
Language: OWL + SWRL

40
WSMO –Web Service Modeling
Ontology

Represents Semantic Web Services by F-logic

F-logic is used to




41
Describe ontologies
Describe rules and goals
Uses Mediators to enable reuse and interoperability
Does not define composition
41
42
Conclusion


METEOR-S adds the advantage of taking an abstract
process as a starting point and automatically binding
services to it
To have dynamism in process composition



METEOR-S helps to provide the plug-and-play support for
dynamically selecting Web services by enhancing discovery of
relevant Web services using Semantics.
METEOR-S reduces manual intervention during Web process
composition. It has the facility of choosing the optimal set
automatically or having the user choose the best set from a list
Constraint analysis gives a better service and choice to the
clients by making sure that the services satisfy the constraints
and also by choosing the optimal set of services automatically.
42
43
Future Work





Add SWRL into METEOR-S to increase expressivity
and provide the ability to represent more complex
constraints and rules
Add Dynamic Binding to METEOR-S using the
ActiveBPEL™ engine is a commercial-grade open
source implementation of the BPEL4WS v1.1
specification
Add the ability to use transformations to make two
incompatible services communicate with each other
Ability to have multiple categories and locations for a
service
Add compensation and recovery. Ref: Ivan Vasquez
43
44
Future Work- Dynamic Binding
OR executes the new service
and sends the result to the
destination service
Service Failed
during execution
new
Either replaces
failed service with
new
UDDI
Process
Coordinator
Discovery
Engine
Constraint
Analyzer
44
45
Future Work -Transformations
Input
Output
WS2
WS1
Person
Match?
Name
Person
Name
Age
Ontology A
Ontology B
45
46
References





[Aggarwal et al., 2004] R. Aggarwal, K. Verma, J. Miller, W.
Milnor, Constraint Driven Web Service Composition in
METEOR-S, Proceedings of the IEEE SCC (to appear), 2004.
[Rajasekaran et al., 2004] P. Rajasekaran, J. Miller, K. Verma,
A. Sheth, Enhancing Web Services Description and Discovery
to Facilitate Composition, Proceedings of SWSWPC, 2004
[METEOR-S, 2002] METEOR-S: Semantic Web Services and
Processes, http://swp.semanticweb.org , 2002.
[Ankolenkar et al., 2003] The DAML Services Coalition,
DAML-S: Web Service Description for the Semantic Web, The
First International Semantic Web Conference -ISWC, Italy
[Roman et al., 2004] D.Roman, U. Keller, H. Lausen, WSMO
– Web Service Modeling Ontology (WSMO), DERI Working
Draft 14 February 2004,
http://www.wsmo.org/2004/d2/v0.1/20040214/
46
Thank You