Configuration and Adaptation of
Semantic Web Processes
Kunal Verma
Ph.D. Thesis Defense (6/13/2006)
LSDIS Lab, Dept of Computer Science, University of Georgia
Advisors: John A. Miller and Amit P. Sheth
Advisory Committee: Budak Arpinar, Robert Bostrom,
Ling Liu
Outline
• Motivation
• Dynamic Process Configuration
• Process Adaptation
• Empirical Evaluation
• Conclusions, Related Work and Future Agenda
Motivation
• Evolution of business needs drives IT innovation
• Initial focus on automation led to workflow technology
• In order to facilitate efficient inter-organizational processes
distributed computing paradigms were developed
– CORBA, JMS, Web Services
• The current and future needs include:
– Creating highly adaptive process that react to changing
conditions
• Focus on real time events and data – RFID and ubiquitous devices
– Have the ability to quickly collaborate with new partners
– Aligning business goals and IT processes
Motivation
“Each enterprise will measure and aspire to its own unique level of
• dynamism
Current based
Toolson
focus
on allowing
businesses
to have
its individual
purpose.
It is about being
nimblegreater
and
dynamism
and
agilitybusiness platform can respond faster, and
adaptable.
A fully
integrated
completely,
to change.
Whether
it involves
fulfilling
a new mandate
or
– Microsoft
Dynamics,
IBM
Websphere
Business
Integration,
SAP
Netweaver
embracing
a new market opportunity. Some organizations will push the
• All
of these Current
focus on dynamic
andfor
agility
through
human
envelope,
automating
event-triggered
responses
highly
integrated
interaction
using
GUIs
closed-loop
processes,
setting
the stage for self-optimizing systems.”
• All of them list SOA (WS) as a technology for realization
Sandra Rogers, White Paper: Business Forces Driving Adoption of Service Oriented
Sponsored by: SAP AG
• Architecture,
The future
– Move focus to greater automation
• Capture domain knowledge and declaratively specify criteria for
process configuration (Dynamic process configuration)
• Add decision making support to process execution tools for
process adaptation (Process Adaptation)
Web Services and Semantics
• Web services deployment increasing in industry
– Standards based interoperability
– Loosely coupled systems
– Still based on manual integration
• Adding semantics can take us to the next level of
automation
– Use ontologies for shared understanding
– Move towards semi-automated integration
Configuration and Adaptation –
Roadmap
Semantic Web
Services and
Processes
Existing WS
Standards/
Infrastructure
WSDL
UDDI
BPEL
WS-Policy,
WS-Agreement
BPEL Engines
(BPWS4J,
ActiveBPEL)
Semantic Web Enablers
Ontologies:
Specification of
conceptualization. Mode of
capturing concepts and
their relationships, etc.
OWL: Ontology Web
Language
SWRL: Semantic Web Rule
Language
Annotation/
Representation
WSDL-S/SAWSDL (02-06)
Discovery
Mapping WSDL-S into UDDI (02-04)
Dynamic Process
Configuration
Composition
Creating abstract
BPEL Process (03-06)
Process Adaptation
Constraint Analysis
Semantic Policies (04-06) and
Agreements (05-06)
Dynamic Execution
Service Manager
based
Runtime Binding (03-06)
Configuration and Adaptation
Receive
Configure: Discover
VP1:
getMBQuote
2. Process Configuration:
-Service discovery
-Constraint analysis
VP2:
getRAMQuote
Configure: Analyze
VP1: orderMB
VP2:orderRAM
Reply
1. Process Creation:
Abstract process with
virtual partner services
and process constraints
Receive
Configure: Discover
VP1:
getMBQuote
3a. Executable Process:
Virtual partners replaced
by actual services
VP2:
getRAMQuote
Configure: Analyze
VP1: orderMB
Reply
VP2:orderRAM
3b. Process Execution:
Monitoring of process
states during execution
Receive
Configure: Discover
VP1:
getMBQuote
3c. Adaptation:
- Event based adaptation
- Find a path from error
state to goal state
VP2:
getRAMQuote
Configure: Analyze
VP1: orderMB
Reply
VP2:orderRAM
High Level Architecture
Event from service
Web Services
Adaptation
Module
Service
invocation
METEOR-S
MIDDLEWARE
Process
and
Service
Managers
MDP
Configuration/Invocation
Response Message
Entities
Configuration
Module
Discovery
Constraint
Analysis
Configuration/Invocation
Request Message
Workflow Engine
(IBM BPWS4J)
Process Manager (PM):
Responsible for global process
configuration
Service Manager (SM):
Responsible for interaction of
process with service
Configuration Module (CM):
Discovery and constraint
analysis
Adaptation Module (AM):
Process adaptation from
exceptions/events
Deployed Web Process
Motivating Scenario
• Consider a simplified supply chain process of a
computer manufacturer
– Most parts are multiple sourced (overseas and internal
suppliers)
• Overseas goods cheaper but greater lead times
– There often exist part compatibility constraints
• Choosing a certain motherboard restricts choices of RAMs,
processors
– Must respect relationship with preferred suppliers
• Suppliers characterized as preferred or secondary
– Sometimes important to maintain production schedule in
the presence of delayed orders
Dynamic Process Configuration
Dynamic Process Configuration
Dynamic configuration Problem
Find optimal partners for the process based on
process constraints – cost, supply time, etc.
Conceptual Approach
1. Create framework to capture represent domain
knowledge
2. Represent constraints on the domain knowledge
3. Ability to reason on the constraints and configure
the process
Dynamic Process Configuration
Research Challenges
– Capturing functional and non-functional
requirements of the Web process (Abstract
process specification)
– Discovering service partners based on
functional requirements (Semantic Web service
discovery)
– Choosing optimal partners that satisfy nonfunctional requirements (Constraint Analysis)
K. Verma, R. Akkiraju, R. Goodwin, P. Doshi, J. Lee, On Accommodating Inter Service Dependencies in Web Process Flow,
AAAI Spring Symposium on Semantic Web Services, 2004
R. Aggarwal, K. Verma, J. A. Miller, Constraint Driven Composition in METEOR-S, SCC 2004.
K. Verma, K.Gomadam, J. Miller and A. Sheth, Configuration and Execution of Dynamic Web Processes, LSDIS Lab Technical Report, 2005.
Abstract Process Specification
1. Specify process
control flow by
using virtual
partners
2. Specify Process
Constraints
3. Capture Functional
Requirements of
Services using
Semantic
Templates
Process Constraints
• Constraints can be specified on a partner,
an activity or the process as a whole.
• An objective function can also be specified
e.g., minimize cost and supply-time, etc.
• Two types of constraints:
– Quantitative (Q) (Time < 5 sec)
– Logical (L) (preferredPartner, Security, etc.)
Process Constraints
Feature
Scope
Goal
Cost (Quantitative)
Process
Minimize
Supplytime (Quantitative)
Process
Satisfy
Cost (Quantitative)
Activity
PreferredSupplier(P1)
(Logical)
Compatible (P1, P2)
(Logical)
Value
Unit
Aggregation
Dollars
Σ
<7
Days
MAX
Satisfy
<200000
Dollars
Σ
Partner 1
Satisfy
True
Process
Satisfy
True
Semantic Templates
•
•
•
Semantic Templates capture the
functionality of a Web service with the
help of ontologies/other domain
models
Find a service that sells RAM in
Athens, GA. It must allow the user to
return and cancel, if needed
The template can also have nonfunctional (QoS) requirements such as
response time, security, etc.
Part of Rosetta
Net Ontology
PIP
QueryOrderStatus
(3A5)
RequestPurchase
Order (3A4)
hasInput
CancelOrder (3A9)
hasOutput
PurchaseOrderDetails
PurchaseOrderConfir
mation
ReturnProduct
(3C1)
SEMANTIC TEMPLATE
Service Level Metadata (SLM)
IndustryCategory = NAICS:Electronics
ProductCategory = DUNS:RAM
Location = Athens, GA
Operation 1
Action = Rosetta#RequestPurchaseOrder
Input = Rosetta#PurchaseOrderRequest
Output = Rosetta#PurchaseConfirmation
Policy = {Encryption = RSA, ResponseTime < 5 sec}
Operation 2
Action = Rosetta#CancelOrder
…………..
WSDL-S is used to capture semantic templates
Data Semantics
Functional Semantics
Non-Functional Semantics
WSDL-S Example
…………
<xs:element name= "processPurchaseOrderResponse" type="xs:string
wssem:modelReference="POOntology#OrderConfirmation"/>
</xs:schema>
</types>
<interface name="PurchaseOrder">
<wssem:category name= “Electronics” taxonomyURI=http://www.naics.com/
taxonomyCode=”443112” />
<operation name=“order” pattern=wsdl:in-out
modelReference = "rosetta:#RequestPurchaseOrder" >
<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>
Rama Akkiraju, Joel Farrell, John Miller, Meenakshi Nagarajan, Amit Sheth, and Kunal Verma, Web Service Semantics, WSDL-S
W3C Member Submission
K. Sivashanmugam, Kunal Verma, Amit Sheth, John A. Miller, Adding Semantic to Web Service Standards, ICWS 2003
.
Semantic Discovery
• Finds actual services matching semantic templates
• Implemented as a layer over UDDI [1]
• Current implementation based on ontological representation
of operations, inputs and outputs.
• Returns ranked of services for each semantic template
• Builds upon following previous discovery implementations
– Extends matching presented in [2] to consider operations and
service level metadata
– Extends the approach presented “WSDL to UDDI Mapping” [3]
to support operation level discovery
[1] K. Verma, K. Sivashanmugam, A. Sheth, A. Patil, S. Oundhakar and John Miller, METEOR-S WSDI: A Scalable
Infrastructure of Registries for Semantic Publication and Discovery of Web Services, JITM
[2] M. Paolucci, T. Kawamura, T. Payne and K. Sycara, Semantic Matching of Web Services Capabilities, ISWC 2002.2
[3] Using WSDL in a UDDI Registry, Version 2.0.2 - Technical Note, http://www.oasis-open.org/committees/uddispec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.pdf
Semantic Discovery
SEMANTIC TEMPLATES
(ST1, ST2 and ST3) from
Abstract Process Specification
UDDI Registry
with Semantic
Layer
DISCOVERY RESULTS – List of candidate service for each template
MB Candidate Service 1
(M1)
Q: Cost = $110000
Q: Supply Time < 7 Days
MB Candidate Service 2
(M2)
Q: Cost = $145000
Q: Supply Time < 7 Days.
.
.
MB Candidate Service 4
(M4)
Q: Cost = $185000
Q: Supply Time <6 Days
CONSTRAINT ANALYSIS
MODULE
ILP Solver
ILP SOLVER RESULTS –
Service Sets that satisfy all quantitative
constraints in increasing Cost order
1. R1, M2, P1
Cost = $400000
2. R4, M1, P3
Cost = $410000
3. R4, M2,P3
Cost = $441000
RAM Candidate Service 1
(R1)
Q: Cost = $45000
Q: SupplyTime < 5 Days
.
.
RAM Candidate Service 3
(R3)
Q: Cost = $40000
Q: SupplyTime < 8 Days
RAM Candidate
Service 4 (R4)
Q: Cost = $41000
Q: Supply Time < 8 Days
Processor Candidate Service
1 (P1)
Q: Cost = $210000
Q: Supply Time < 5 Days
.
.
Processor Candidate Service
3 (P3)
Q: Cost = $255000
Q: Supply Time < 8 Days
Processor Candidate
Service 4 (P4)
Q: Cost = $228000
Q: Supply Time < 5 Days
PROCESS CONSTRAINTS
Q: Cost <= $600000
Q: SupplyTime < 7 Days
L: Compat (RAM, MB)= True
L: Compat (PROC, MB)= True
L: preferredSupplier(S1) = True
Min: Cost
SWRL REASONER
RESULTS Service sets that satisfy
both quantitative and non-quantitative
constraints
1. R1, M2,P1
Cost = $400000
2. R4, M1,P3
Cost = $410000
SWRL
Reasoner
(REJECTED SET 3 as R4 not
compatible with M2 and P3 not
compatible with M2)
Constraint Analysis
• Operations Research has been used in industry for business
process optimization
• For process configuration our approach seeks to combine domain
knowledge in ontologies with a standard optimization technique
• Multi-paradigm proposed:
– Integer Linear Programming for quantitative constraints
– Semantic Web Rule Language and OWL for domain constraints
• Discovered Services first given to ILP solver
– It returns ranked sets of services
• Then each set is checked for logical constraints using a SWRL
reasoner
– Sets not satisfying the criteria are rejected
Quantitative Constraint Analysis
• Create a binary variable xij for each
candidate service.
xij 
{
1, if candidate service j is chosen for activity i
0, otherwise
• Set up constraints for the number of
services chosen for each activity.
– N(i) is the number of candidate services of
activity ‘i’ and M is the number of activities.
N( i )
( i )1i  M  xij  1
j 1
Quantitative Constraint Analysis
• Set the cost constraint on activity1

N( 1 )
j 1 cos t( x1 j
)  x1 j  200000
• Set the supply time constraint
( i )1iM ( j )1 j  N( i ) SupplyTime( xij )  xij  7
• Set up the objective function
Minimize : 
M
i 1
N( i )
j 1 cost( xij
)  xij
Configuration – Quantitative Constraint
Analysis
SEMANTIC TEMPLATES
(ST1, ST2 and ST3) from
Abstract Process Specification
UDDI Registry
with Semantic
Layer
DISCOVERY RESULTS – List of candidate service for each template
MB Candidate Service 1
(M1)
Q: Cost = $110000
Q: Supply Time < 7 Days
MB Candidate Service 2
(M2)
Q: Cost = $145000
Q: Supply Time < 7 Days.
.
.
MB Candidate Service 4
(M4)
Q: Cost = $185000
Q: Supply Time <6 Days
CONSTRAINT ANALYSIS
MODULE
ILP Solver
ILP SOLVER RESULTS –
Service Sets that satisfy all quantitative
constraints in increasing Cost order
1. R1, M2, P1
Cost = $400000
2. R4, M1, P3
Cost = $410000
3. R4, M2,P3
Cost = $441000
RAM Candidate Service 1
(R1)
Q: Cost = $45000
Q: SupplyTime < 5 Days
.
.
RAM Candidate Service 3
(R3)
Q: Cost = $40000
Q: SupplyTime < 8 Days
RAM Candidate
Service 4 (R4)
Q: Cost = $41000
Q: Supply Time < 8 Days
Processor Candidate Service
1 (P1)
Q: Cost = $210000
Q: Supply Time < 5 Days
.
.
Processor Candidate Service
3 (P3)
Q: Cost = $255000
Q: Supply Time < 8 Days
Processor Candidate
Service 4 (P4)
Q: Cost = $228000
Q: Supply Time < 5 Days
PROCESS CONSTRAINTS
Q: Cost <= $600000
Q: SupplyTime < 7 Days
L: Compat (RAM, MB)= True
L: Compat (PROC, MB)= True
L: preferredSupplier(S1) = True
Min: Cost
SWRL REASONER
RESULTS Service sets that satisfy
both quantitative and non-quantitative
constraints
1. R1, M2,P1
Cost = $400000
2. R4, M1,P3
Cost = $410000
SWRL
Reasoner
(REJECTED SET 3 as R4 not
compatible with M2 and P3 not
compatible with M2)
Logical Constraint Analysis
• Use a SWRL reasoner to perform logical constraint analysis
• Domain knowledge is captured as ontologies
• Rules are created with the help of the knowledge in the
ontology
• Implemented using IBM’s ABLE and SNOBASE
– SNOBASE stores OWL ontologies using ABLE Rule Language
(ARL)
– Our implementation is based on SWRL rules written in ARL
K. Verma, R. Akkiraju, R. Goodwin, Semantic Matching of Web Service Policies SDWP 2005 & Filed Patent
N. Oldham, K. Verma, A. Sheth, Semantic WS-Agreement Based Partner Selection, WWW 2006
Domain Ontology
SCHEMA
worksWith
partnerStatus
Supplier
Part
Supplies
MotherBoard
RAM
INSTANCES
RAM2
RAM1
Supplies
R1
Supplies
R5
Supplies
worksWith
MB1
R4
Supplies
M1
M2
M3
Domain Ontology – Detailed View
Works_with
ISA
Part
Works_withCPU
Supplies
ISA
Supplier
ISA
Works_withMB
RAM
Works_withCPU
Motherboard
Processor
ISA
ISA
DDR2 RAM
RDRAM
Model: KVR533D2S4/256
Memory_speed: 400 MHz
Voltage:1.8 V
Requires: dual_channel_motherboard
Uses: DIMMS
Storage:512MB
R1
R3
M1
Model: MR16Q162GDB0-CA2
Memory_speed: 800 MHz
Voltage: 2.5V
Requires: dual_channel_motherboard
Uses: DIMMS
Storage:512MB
R4
M2
M4
Model: MR16R162GDF0-CM8
Memory_speed: 800 MHz
Voltage: 2.5V
Requires: dual_channel_motherboard
Uses: RIMMS
Storage:512MB
supplies
P1
Model: Athlon ADA3800BVBOX
Type: Athlon64FX2
Clock_speed: 3.80 Ghz
Core_type: Dual
Adressing_size: 64 Bit
Cache:1MB
FSB: 800 MHz
P4
Model: D875PBZ
CPU_Type: IntelPentium4
FSB: 800 MHz
Type: dual_channel_motherboard
RAM_Modules: DIMMS
RAM_Speed:800/533/400
Model: A8N-SLI
CPU_Type: Athlon64FX/Athlon64X2
FSB: 1066/800/533MHz
Type: dual_channel_motherboard
RAM_Modules: DIMMS
Supports_RAM_Speed:800/533/400
Model: D865PERL
CPU_Type: IntelPentium4
FSB: 800 MHz
Type: dual_channel_motherboard
RAM_Modules: RIMMS
Supports_RAM_Speed:800/533/400
Model: Pentium 4 672
Type: Pentium4
Clock_speed: 3.80 Ghz
Core_Type: Single
Adressing_size: 32 Bit
Cache:2MB
FSB: 1200 MHz
Rules
•
Supplier 1 should be a preferred supplier.
–
“if S1 is a supplier and its supplier status is preferred then the S1 is a
preferred supplier”.
Supplier (?S1) and partnerStatus (?S1, “preferred”) => preferredSupplier
(?S1)
•
Supplier 1 and supplier 2 should be compatible.
–
if S1 and S2 are suppliers and they supply parts P1 and P2, respectively, and
the parts work with each other, then suppliers S1 and S2 are compatible for
parts P1 and P2.
Supplier (?S1) and supplies (?S1, ?P1) and Supplier (?S2) and supplies
(?S2, ?P2) and worksWith (?P1, ?P2) => compatible (?S1, ?S2, ?P1,
?P2)
RAM (?P1) and MB (?P2) and worksWithMB (?P1, ?P2) =>worksWith
(?P1, ?P2)
Using Rules to resolve Heterogeneities
Manufacturer Process Constraint:
Availability is greater than 95%
Supplier Policy:
Mean Time to Recover equals 5 minutes
Mean Time between failures equals 15 hours
Rule: Availability = Mean Time Between
Failures/(Mean Time Between Failures +
Mean Time To Recover)
Availability equals 99.4%.
K. Verma, R. Akkiraju, R. Goodwin, Semantic Matching of Web Service Policies SDWP 2005 & Filed Patent
N. Oldham, K. Verma, A. Sheth, Semantic WS-Agreement Based Partner Selection, WWW 2006
Configuration – Logical Constraint
Analysis
SEMANTIC TEMPLATES
(ST1, ST2 and ST3) from
Abstract Process Specification
UDDI Registry
with Semantic
Layer
DISCOVERY RESULTS – List of candidate service for each template
MB Candidate Service 1
(M1)
Q: Cost = $110000
Q: Supply Time < 7 Days
MB Candidate Service 2
(M2)
Q: Cost = $145000
Q: Supply Time < 7 Days.
.
.
MB Candidate Service 4
(M4)
Q: Cost = $185000
Q: Supply Time <6 Days
CONSTRAINT ANALYSIS
MODULE
ILP Solver
ILP SOLVER RESULTS –
Service Sets that satisfy all quantitative
constraints in increasing Cost order
1. R1, M2, P1
Cost = $400000
2. R4, M1, P3
Cost = $410000
3. R4, M2,P3
Cost = $441000
RAM Candidate Service 1
(R1)
Q: Cost = $45000
Q: SupplyTime < 5 Days
.
.
RAM Candidate Service 3
(R3)
Q: Cost = $40000
Q: SupplyTime < 8 Days
RAM Candidate
Service 4 (R4)
Q: Cost = $41000
Q: Supply Time < 8 Days
Processor Candidate Service
1 (P1)
Q: Cost = $210000
Q: Supply Time < 5 Days
.
.
Processor Candidate Service
3 (P3)
Q: Cost = $255000
Q: Supply Time < 8 Days
Processor Candidate
Service 4 (P4)
Q: Cost = $228000
Q: Supply Time < 5 Days
PROCESS CONSTRAINTS
Q: Cost <= $600000
Q: SupplyTime < 7 Days
L: Compat (RAM, MB)= True
L: Compat (PROC, MB)= True
L: preferredSupplier(S1) = True
Min: Cost
SWRL REASONER
RESULTS Service sets that satisfy
both quantitative and non-quantitative
constraints
1. R1, M2,P1
Cost = $400000
2. R4, M1,P3
Cost = $410000
SWRL
Reasoner
(REJECTED SET 3 as R4 not
compatible with M2 and P3 not
compatible with M2)
Runtime Configuration Support
One to Many Binding
phase
M1
SM1
M3
Configure: Discover
P1
P2
SM2
VP2:
getRAMQuote
P3
Binding phase
Configure: Analyze
VP1: orderMB
VP2:orderRAM
One to One Binding
phase
Phases
One to Many binding(
Information gathering
phase): Number of
services bound to same
service manager. Used
for information gathering
for constraint analysis
M2
Receive
VP1:
getMBQuote
Discover partners and
Get quote from all
partners
Analyze process
constraints and create
a set of optimal
partners
Process execution with
set of optimal partners
SM1
M2
SM3
P1
Reply
Binding (Constraint
Analysis Phase):
Constraint Analysis and
binding optimal partner
to each SM
One to One binding
(Execution and
adaptation phase):
Normal process
execution with optimal
partner
Process Adaptation
Process Adaptation
• Ability to adapt the processes from failures,
unexpected events
• Two kinds of failures
– Failures of physical components like services, processes,
network
• Can replace services using dynamic configuration
– Logical failures like violation of SLA
constraints/Agreements such as Delay in delivery, partial
fulfillment of order
• Need additional decision making capabilities
K. Verma, A. Sheth, Autonomic Web Processes, ICSOC 2005
K. Verma, P. Doshi, K. Gomadam, A. Sheth, J. Miller, Optimal Adaptation of Web Processes with Coordination Constraints, ICWS 2006.
Process Adaptation
Adaptation Problem
Optimally react to events like delays in ordered
goods
Conceptual Approach
1. Maintain states of the process – normal states,
error states, goal states
2. Capture costs while transitioning from anomalous
states to goal state
3. Ability to decide optimal actions on the basis of
state
Order
Wait for
Delivery
Order
received
Received
Optimal to
change
supplier
Order
delayed
Order
received Delayed
Optim
al to
wait
K. Verma, A. Sheth, Autonomic Web Processes, ICSOC 2005
K. Verma, P. Doshi, K. Gomadam, A. Sheth, J. Miller, Optimal Adaptation of Web Processes with Coordination Constraints, ICWS 2006.
Process Adaptation
• Research Challenges
– Creating a model to recover from failures and handle future events
– Model must deal with two important factors
• Uncertainty about when a failure occurs
• Cost based recovery
• Scenario
– After order for MB and RAM are placed, they may get delayed
– The manufacturer may have severe costs if assembly is halted.
– It must evaluate whether it is cheaper to cancel/return and reorder or
take the penalty of delay
– Caveat: possible that reordered goods may be delayed too
• Proposed Solution
– Modeling decision making capabilities of Service Managers as Markov
Decision Processes (MDPs)
Modeling Decision Making Process of
Service Managers using MDPs
Each Service Manager is controlled by a MDP
SM-MDP = <S, A, PA, T, C, OC> , where
•
S is the set of local states of the service manager.
•
A is the set of actions of the service manager. The actions include invoking Web
service operations and calling the configuration manager.
•
PA : S → A is a function that gives the permissible actions of the service manager
from a particular state.
•
T : S × A × S → [0, 1] is the local Markovian transition function. The transition
function gives the probability of ending in a state j by performing action a in state i.
•
C : S × A → R is the function that gives the cost of performing an action from some
state of the service manager.
•
OC is the optimality criterion. We minimize the expected cost over a finite number of
steps, N, also called the horizon.
Policy Computation
• The optimal action at each state is represented using a
policy.
• In order to compute the policy, a value is associated to
each state.
– The value represents long term expected cost of performing
the optimal action from that state and is calculated the
following dynamic programming equation.
Vn ( s )  min Qn ( s,a )
aPA( s )
Qn ( s,a )  C( s,a )    T( s' | s,a )Vn1( s')
s'
The policy pi : S × N → R is then computed as:
pin ( s )  arg min Qn ( s,a )
aPA( s )
N is the number of steps to go and Gamma is the discount factor
Algorithm developed by Bellman in 57
Generating States using preconditions
and effects
Actions
Events
Flags
Pre: Ordered = False
Operation: Order
Pre: Ordered = True &
Received = false
Post: Ordered = True
Ordered
Event: Delayed
Received
Pre: Ordered = True &
Received = false
Post: Delayed=True &
Ordered = True
Operation: Cancel
Delayed
Post: Canceled=True &
Ordered = false
Pre: Ordered = True &
Received = True
Pre: Ordered = True &
Received = false
Event: Received
Post: Received = True
Operation: Return
Cancelled
Returned
Post :Returned = True &
Ordered = false and
Received = false
Use an algorithm similar to reachability analysis to generate states
Not possible to generate without preconditions and effects
Generated State Transition Diagram
DFA = { S, s1, F, T, A}
State
No.
Values of Boolean
variables
Explanation
O
O
1
2
3
<O C R Del Rec 
Ordered
<O C R Del Rec 
Ordered and Canceled
<O C R Del Rec 
W
O
s1
C
s2
Ordered and Delayed
4
<O C R Del Rec 
Ordered, Received and
Returned
5
<O C R Del Rec 
Ordered, Delayed and
Cancelled
6
<O C R Del Rec 
Ordered, Delayed, Received
and Returned
7
<O C R Del Rec 
Ordered, Delayed and
Received
8
<O C R Del Rec 
Ordered and Received
O
Del
s3
C
s5
s6
R
W
Rec
s4
Rec
R
s8
s7
W
W
Costs and Probabilities
• Costs of ordering taken from configuration
module
– From first two service sets
• Optimal supplier and alternate supplier
• Probability of delay and cost of returning
and canceling taken from supplier policy
– Can be represented using WS-Policy or WSAgreement
Supplier Policy
– The supplier gives a probability of 55% for delivering the
goods on time.
– The manufacturer can cancel or return goods at any
time based on the terms given below.
• If the order is delayed because of the supplier, the order
can be cancelled with a 5% penalty to the manufacturer.
• If the order has not been delayed, but it has not been
delivered yet, it can be cancelled with a penalty of 15% to
the manufacturer.
• If the order has been received after a delay, it can be
returned with a penalty of 10% to the manufacturer.
• If the order has been received without a delay, it can be
returned with a penalty of 20% to the manufacturer.
Costs and Probabilities
Current State
<O C R Del Rec 
Action
NOP
Next State
<O C R Del Rec 
Cost
0
<O C R Del Rec 
CANCEL
<O C R Del Rec 
150
<O C R Del Rec 
DEL
<O C R Del Rec 
0
<O C R Del Rec 
RECEIVE
<O C R Del Rec 
0
<O C R Del Rec 
ORDER
<O C R Del Rec 
100
<O C R Del Rec 
NOP
<O C R Del Rec 
<O C R Del Rec 
CANCEL
<O C R Del Rec 
DelayCost =
{200, 300, 400}
50
<O C R Del Rec 
RECEIVE
<O C R Del Rec 
0
<O C R Del Rec 
ORDER
<O C R Del Rec 
100
<O C R Del Rec 
ORDER
<O C R Del Rec 
100
<O C R Del Rec 
ORDER
<O C R Del Rec 
100
<O C R Del Rec 
CANCEL
<O C R Del Rec 
150
<O C R Del Rec 
NOP
<O C R Del Rec 
0
<O C R Del Rec 
RETURN
<O C R Del Rec 
200
<O C R Del Rec 
NOP
<O C R Del Rec 
0
O
O
W
O
s1
C
0.45
Rec
R
Rec
s4
0.35
0.85
s6
W
s3
C
s5
O
Del
s2
s7
W
R
s8
W
Handling Inter-Service dependencies
• Since the RAM and Motherboard must be
compatible, the actions of service managers
(SMs) must be coordinated
• For example, if MB delivery is delayed, and MB
SM wants to cancel order and change supplier,
the RAM SM must do the same
• Hence, coordination must be introduced in SMMDPs
Centralized Approach
• State space created by Cartesian product of transition
diagrams
• Joint actions from each state
• Transition probability created by multiplying states
• Costs created by adding cost per action from each state
– Compatible actions given rewards
– Incompatible actions given penalties
• Optimal but exponential with number of manager
Decentralized Approach
• Simple coordination mechanism
• If one service manager changes suppliers
– All dependent managers must change suppliers
• Low complexity but sub-optimal
Hybrid Approach
• If the policy of some SM dictates it to change suppliers, the
following actions happen:
–
–
it sends a coordinate request to PM
PM gets the current cost of changing suppliers or current
optimal action by polling all SMs
• It takes the cheapest action (change supplier or continue)
• A bit like decentralized voting- will change suppliers if
majority are delayed
• It mirrors performance of centralized approach and has
complexity like the decentralized approach
Dynamic and Adaptive Processes in
Healthcare
AM
Relevant Event Type
Figure and Table from a joint
Amit Sheth, Prashant Doshi publication
Effects on the Pathway
1.Adverse drug reaction
Stop drug therapy or reduce dosage
1.Sudden worsening of symptoms
Increase dosage or modify pathway by initiating new
therapy
1.New drug alert
Prescribe the drug for the appropriate activity
1. Newly discovered drug-drug
interaction
Add new dependency in the pathway
1.New co-morbidity
Possibly modify the pathway or drug prescriptions
Empirical Evaluation
Evaluating Dynamic Configuration
• Evaluation with help of the supply chain
scenario
• Use the variations in currency exchange
rates of China and Taiwan as the primary
factor affecting supplier prices
• Assume that process is dynamically
configured every fortnight
Observations
• Static binding
– Configured at the first run and same partners are
persisted with for all subsequent runs
– Cost changes due to variations in currency
• Dynamic binding
– Dynamically configured with latest prices for all runs
– With just ILP (Dynamic1) Always the lowest cost, logical
constraints not guaranteed
– With ILP and SWRL (Dynamic2) Lowest cost for partners
satisfying all constraints
Static Process
1100
Dynamic1 Process only ILP
1000
Dynamic2 Process both ILP and SWRL
7.1%
15.2%
900
2.73%
Ju
l
Au
g
Se
p
O
ct
800
Ja
n
Fe
b
M
ar
Ap
r
M
ay
Ju
n
Process cost per unit (in $)
Results – Process Configuration
Month of configuring process
Average Cost
Difference: 9.32%
Evaluating Process Adaptation
• Evaluation with the help of the supply chain
scenario
• Two main parameters used for the evaluation
– Probability of Delay – (probability that an item ordered
from a supplier will be delayed)
– Penalty of Delay – (cost for the manufacturer for not
reacting to delay)
• Total process cost = $1000 and cost of changing
suppliers (CS) =$200
Evaluating Adaptation
Cost of Waiting = 200
2500
M-MDP
Random
2100
Average Cost
Hyb. MDP
MDP-CoM
1700
KEY
M-MDP: Centralized
Random: Random process
(changes suppliers for 50% of
delays)
1300
Hyb. Com: Hybrid
MDP-Com: Decentralized
900
0.1
0.2
0.3
0.4
0.5
Probability of delay
0.6
0.7
Evaluating Adaptation
Cost of Waiting = 300
2500
M-MDP
Random
2100
Average Cost
Hyb. MDP
MDP-CoM
1700
1300
900
0.1
0.2
0.3
0.4
0.5
Probability of delay
0.6
0.7
Evaluating Adaptation
Cost of Waiting = 400
2500
M-MDP
Random
Average Cost
2100
Hyb. MDP
MDP-CoM
1700
1300
900
0.1
0.2
0.3
0.4
0.5
Probability of delay
0.6
0.7
Observations
• Results
– For Penalty = 200 (cost of CS = cost of delay), MDP always
waits
– For Penalty = 300, 400 (cost of CS < cost of delay), MDP
changes at lower prob., waits at higher prob.
• Conclusions
– Thus MDP makes intelligent decisions and outperforms random
process that changes suppliers 50% of the time it is delayed
– Centralized MDP performs the best, followed by Hybrid MDP
Evaluating Adaptation with Extended
Scenario
• In previous model length of delay was not
considered
• Three delay events instead of 1
– Del1 (0-7 days)
– Del2 (7-21 days)
– Del3 (21 days and more)
• Adaptation graph exhibits exactly the
same behavior
Evaluating Adaptation with Extended
Scenario
Delay Penalty = 300 Dollars (Extended Scenario)
1700
Centralized MDP
Average Cost
1600
Random
1500
Hybrid MDP
1400
Dentralized MDP
1300
1200
1100
1000
1
2
3
4
5
Probability of delay
6
7
Testing Adaptation with Configuration
• Process executed in two modes
– Configuration with random adaptation
– Configuration with Hybrid MDP based
adaptation
• Tested across different probabilities
• MDP based adaptation outperforms
random adaptation
Testing Adaptation with Configuration
Configuration with Adaptation
Dynamic Process
Average Cost
1000
Cost ($)
800
Random Adaptation
600
MDP based adaptation
400
Static Process Cost
200
0
0.1
0.2
0.3
0.4
0.5
Delay Probability
0.6
0.7
Static Process with
Random adaptation
Static Process with MDP
based adaptation
Architecture
METEOR-S Middleware
Axis 2.0 Based Architecture
Configuration Architecture
Adaptation Architecture
Conclusions, Related Work and
Future Agenda
Summary - Dynamic Process
Configuration
• Showed how domain knowledge in ontologies can
be used with ILP for configuration
• Multi-paradigm approach for constraint analysis
to handle broader set of constraints
• In business and scientific processes, configuration
is an important problem
– Especially in WS based systems where businesses are
seeking to create dynamic processes
– This thesis is the first comprehensive work in this area.
Summary - Adaptation
• Showed the utility of Markov Decision Processes for optimal
adaptation of Web processes
– Adaptation is need to handle logical failures and events
– Whether to adapt or not depends on the cost of the failure
• For this evaluation it was the cost of the delay
• In the real world things often go wrong or not as expected
– Earlier processes were static or real time events were not
available as easily
– Many researchers/industry vendors seeking to create adaptive
business process frameworks
– This is one of the first works that provides cost based
adaptation
Related Work
•
Semantic Web Services
•
Quality driven composition [1]
•
Support in Websphere [2] and Oracle BPEL Engine for runtime binding.
•
Automated workflow composition
– OWL-S, WSMO, FLOWS
– Uses ILP for optimizing processes
– Our work uses a multi-paradigm approach to considering a broader set of
constraints
– Based on replacing services with same interfaces. Service selection is not the
focus
– Our focus is on finding optimal services based on process constraints
– Plethora of work based on automatically generating processes based on high
level goals. [3]
– Our focus is on configuring pre-existing processes.
[1] L. Zeng, B. Benatallah, M. Dumas, J. Kalagnanam, Q. Sheng: Quality driven Web services composition, WWW 2003
[2] Dynamic service binding with WebSphere Process Choreographer, http://www128.ibm.com/developerworks/webservices/library/ws-dbind/
[3] J. Rao and X. Su. "A Survey of Automated Web Service Composition Methods". SWSWPC 2004.
Related work
• Focus on correctness of changes to control flow structure
– Adept[1], Workflow inheritance [2], METEOR
• Use of ECA rules [3] to automatically make changes
• Change of service providers based on migration rules in EFlow [4]
• We extend previous work in this area by using:
– Cost based adaptation
– Coordination Constraints across services
[1] M. Reichert and P. Dadam. Adeptflex-supporting dynamic changes of workflows without losing control.
Journal of Intelligent Information Systems, 10(2):93–129, 1998
[2] W. van der Aalst and T. Basten. Inheritance of workflows: an approach to tackling problems related to
change. Theoretical Computer Science, 270(1-2):125–203, 2002.
[3] R. Muller, U. Greiner, and E. Rahm. Agentwork: a workflow system supporting rule-based workflow
adaptation. Journal of Data and Knowledge Engineering, 51(2):223–256, 2004.
[4] Fabio Casati, Ski Ilnicki, Li-jie Jin, Vasudev Krishnamoorthy, Ming-Chien Shan: Adaptive and Dynamic
Service Composition in eFlow. CAiSE 2000: 13-31
Future Work
• To apply this framework to more business
and scientific problems
• Study impact of ubiquitous computing
(especially event generation) on dynamic
process configuration
• Move towards autonomic Web
processes
Publications
•
Dynamic Process Configuration
•
Adaptation
•
Semantic Policy/SLA Representation and Matching
– K. Verma, R. Akkiraju, R. Goodwin, P. Doshi, J. Lee, On Accommodating Inter
Service Dependencies in Web Process Flow Composition, Proceedings of the AAAI
Spring Symposium on Semantic Web Services, March, 2004, pp. 37-43
– R. Aggarwal, K. Verma, J. A. Miller, Constraint Driven Composition in METEOR-S,
SCC 2004.
– K. Verma, K.Gomadam, J. Miller and A. Sheth, Configuration and Execution of
Dynamic Web Processes, LSDIS Lab Technical Report, 2005.
– K. Verma, A. Sheth, Autonomic Web Processes, ICSOC 2005
– K. Verma, P. Doshi, K. Gomadam, A. Sheth, J. Miller, Optimal Adaptation of Web
Processes with Co-ordination Constraints, ICWS 2006.
– K. Verma, R. Akkiraju, R. Goodwin, Semantic Matching of Web Service Policies
SDWP 2005 & Filed Patent
– N. Oldham, K. Verma, A. Sheth, Semantic WS-Agreement Based Partner
Selection, WWW 2006 (nominated for best student paper)
Publications
•
Semantic Web Service Discovery
•
Semantic Annotation/Representation
•
Semantic Web Composition
– K. Verma, K. Sivashanmugam, A. Sheth, A. Patil, S. Oundhakar and John Miller,
METEOR-S WSDI: A Scalable Infrastructure of Registries for Semantic Publication
and Discovery of Web Services, JITM
– K. Sivashanmugam, K. Verma, A. Sheth, Discovery of Web Services in a
Federated Registry Environment, ICWS04
– Rama Akkiraju, Joel Farrell, John Miller, Meenakshi Nagarajan, Amit Sheth, and
Kunal Verma, Web Service Semantics, WSDL-S W3C Member Submission
– K. Sivashanmugam, Kunal Verma, Amit Sheth, John A. Miller, Adding Semantic
to Web Service Standards, ICWS 2003.
– K. Sivashanmugam, J. Miller, A. Sheth, and K. Verma, Framework for Semantic
Web Process Composition, International Journal of Electronic Commerce, Winter
2004-5, Vol. 9(2) pp. 71-106
Backup Slides
Semantics for Web Services and
Processes
•
Functional and Data Semantics
•
Non-Functional Semantics
–
–
Service (WSDL-S)[1]
Policies (Define tags to capture semantic
information 2])
•
–
Business Level Policies, Process Level Policies,
Instance Level Policies Individual Component
Level Policy
Agreements (SWAPS) [3]
•
Execution Semantics
•
Ontologies
–
–
–
–
State Transitions based on exceptions/failures
Process (BPEL + Semantic Templates) [4]
Domain Specific Ontologies – RosettaNet,
SUMO Finance
Domain Independent/Upper Ontologies
[1] Web Service Semantics – WSDL-S, W3C Member Submission., http://www.w3.org/Submission/WSDL-S/
[2] K. Verma, R. Akkiraju, R. Goodwin, Semantic matching of Web service policies, SDWP, 2005
[3] N. Oldham, K. Verma, A. Sheth, Semantic WS-Agreement Partner, WWW 2006
[4] K. Sivashanmugam, J. Miller, A. Sheth, and K. Verma, Framework for Semantic Web Process Composition, IJEC, 2004
Timing Overheads
Process Execution Time
Discovery
Constraint Analysis
1000
• Static Binding: BPEL
process with pre-defined
partners run on BPWS4J
engine
800
Time (ms)
• Comparison of overheads
due to dynamic process
configuration
600
400
200
0
No Configuration. Static Binding
Configuration w ith Discovery
•Dynamic Binding: Run
using Axis 2.0 based
architecture and BPWS4J
engine
Convergence of Value Function
Marginalizing events
Hybrid Approach
State Generation Algorithm
Algorithm: Generate States (s0)
Start with initial state s0
// e.g. (ordered=false)
Add s0 to a set S
While s( s  S ) and s is unmarked
//states
While a( a  A )& s satisfies pre( a ) //actions
create ns by applying effect(a) to s
if ( ns  S )
Add ns to set S
Create edge from s to ns
end if
end while
//actions
While e( e  E )& s satisfies pre( e ) //effects
create ns by applying effect(e) to s
if ( ns  S )
Add ns to set S
Create edge from s to ns
end if
end while
//effects
mark s as visited
End while
//states
Semantic Publication and Template
Based 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
Adding Semantics to Web Services Standards
Syntactic, QoS, and Semantic
(Functional & Data) Similarity
Syntactic
Similarity
Similarity ?
Name,
Description,
…
A
B
C
Name,
X
Description,
Y
….
Web Service
Web Service
Discovery
SynSimilar ty( ST , SO) 
1SynNS ( ST .sn, SO.sn )   2 SynDS ( ST .sd , SO.sd )
 [0..1],
1   2
and 1 ,  2  [0..1]
Web Service
Similarity ?
QoS
QoS
Similarity
OpSimilari ty( ST , SO) 
3
Buy
QoSdimD ( ST , SO, time) * QoSdimD ( ST , SO, cost ) * QoSdimD ( ST , SO, reliabilit y)
A
B
C
X
Y
Web Service
Calendar-Date
A1
…
…
Web Service
Similarity ?
Event
…
A2
QoS
Purchase
Web Service
Functional & Data
Similarity
Coordinates{x, y}
Information Function
Area {name}
Web Service
Forrest
Get Information
Get Date
METEOR-S Web Service Discovery
Infrastructure (MWSDI)
• MWSDI deals with adding semantics to
UDDI registries
• Provides transparent access to UDDI
registries based on their domain or
federation
• Implementation of UDDI Best Practices
and Semantic Discovery
1 http://lsdis.cs.uga.edu/Projects/METEOR-S
Extended Registries Ontologies (XTRO)
• Provides a multifaceted view of all
registries in MWSDI
– Federations
– Domains
– Registries
Registry
Federation
belongsTo
Federation
belongsTo
Registry
supports
Ontology
Domain
subDomainOf
consistsOf
Variations in Chinese and Taiwanese
Currency
Source for graphs and data: www.x-rates.com
Generated State Transition Diagram
DFA = { S, s1, F, T, A}
S = set of states
s1 = start state
F = set of final states
T = Transition Function T : S × A → S
A = Finite set of actions and events