METEOR-S: investigations on
semantics empowerment of processes
Amit Sheth
LSDIS Lab,
Dept of Computer Science,
University of Georgia
with the METEOR-S team; special thanks: Kunal Verma, Meena Nagarajan
Motivation
• Evolution of business needs drives IT innovation
• Initial focus on automation led to workflow
technology
• The current and future needs include:
–
–
–
–
Aligning business goals and IT processes
Streamlining business processes
Having ability to quickly work with new partners
Creating adaptive process that react to changing
conditions
• Three of the enablers for realizing these goals:
– Interoperability (with Semantic Annotation)
– Dynamic process configuration
– Process Adaptation
Research RoadMap
Semantic and Autonomic Web Processes
The Future
Self
Configuration
Our Current Focus:
METEOR-S:
Applying Semantics
to Complete Web
Annotation/
Process Lifecycle Representation
Standards in WS and
Semantic Web
Self
Healing
Self
Optimization
Self
Protection
Semantic Web Processes
Discovery
Semantic Web
Technologies
(OWL, SWRL, RDF)
Composition
Execution/
Adaptation
Web Services
Standards
(WSDL, UDDI, BPEL)
Outline
• Interoperability and WSDL-S
– Work by Meena Nagarajan, Kunal Verma, with IBM
• Dynamic Process Configuration
– Work by Kunal, Karthik Gomadam
• Process Adaptation
– Work by Kunal, Prashant Doshi
• Some Results
• Conclusions
Interoperability and WSDL-S
Interoperability in Web services
• Impediments beyond semantic
composition of Web services
– Message level heterogeneities between
communicating Web services
INPUT TO
WEB SERVICE 2
DATA MEDIATION
REQUIRED
Listing Name
First Name
Last Name
OUTPUT FROM
Address
WEB SERVICE 1
City
State
Postal Code
Phone Number
Published
Web service 2
Geocode
Enhancer
OUTPUT FROM
WEB SERVICE 2
Web service 1
Address
Lookup
Address line 1
Address line 2
City_State_zip
Census Track
State Number
County Number
Block Number
Block Group
Telephone Number
INPUT TO
WEB SERVICE 1
Message level Heterogeneities
• Syntactic - differences in the language used for
representing the elements
Resolved by the XML
based environment
• Model/Representational - differences in the underlying
models (database, ontologies) or their representations
(relational, object-oriented, RDF, OWL)
• Structural - differences in the types, structures of the
elements
WSDL-S; Semi-automatic solution
• Semantic - where the same real world entity is represented
using different terms (or structures) or vice versa
Heterogeneities / Conflicts
Examples - conflicted elements shown in color
Suggestions / Issues in Resolving Heterogeneities
Domain Incompatibilities – attribute level differences that arise because of using different descriptions for semantically similar attributes
Naming conflicts
Two attributes that are semantically alike might
have different names (synonyms)
Two attributes that are semantically unrelated
might have the same names (homonyms)
Web service 1
Student(Id#, Name)
Web service 2
Student(SSN, Name)
Web service 1
Student(Id#, Name)
Web service 2
Book (Id#, Name)
Data representation conflicts
Web service 1
Two attributes that are semantically similar might Student(Id#, Name)
have different data types or representations
Id# defined as a 4
digit number
A semantic annotation on the entities and attributes
(provided by WSDL-S:modelReference) will indicate their
semantic similarities.
Web service 2
* Mapping WS2 Id# to WS1 Id# is easy with some
Student(Id#, Name)
additional context information while mapping in the
Id# defined as a 9
reverse direction is most likely not possible.
digit number
Data scaling conflicts
Web service 1
Two attributes that are semantically similar might Marks 1-100
be represented using different precisions
Web service 2 * Mapping WS1 Marks to WS1 Grades is easy with
some additional context information while mapping in
Grades A-F
the reverse direction is most likely not possible.
•Matching
•Mapping
•A lot of early work on heterogeneous database
integration is still quite useful
Entity Definition – entity level differences that arise because of using different descriptions for semantically similar entities
Naming conflicts
Semantically alike entities might have different
names (synonyms)
Web service 1
EMPLOYEE (Id#, Name)
Semantically unrelated entities might have the
same names (homonyms)
Web service 1
TICKET (TicketNo,
MovieName)
Schema Isomorphism conflicts
Semantically similar entities may have different
number of attributes
Web service 2
WORKER (Id#,
Name)
Web service 2
TICKET(FlightNo,
Arr. Airport, Dep. Airport)
Web service 1
PERSON (Name, Address,
HomePhone, WorkPhone)
A semantic annotation on the entities and attributes
(provided by WSDL-S:modelReference) will indicate their
semantic similarities.
Web service 2
* Mapping in both directions will require some additional
PERSON (Name,
context information.
Address, Phone)
Abstraction Level Incompatibility – Entity and attribute level differences that arise because two semantically similar entities or attributes are
represented at different levels of abstraction
* WS2 defines the student entity at a much general level.
Web service 2
STUDENT(ID, Name, A mapping from WS1 to WS2 requires adding a Type
element with a default ‘Graduate’ value, while mapping in
Major, Type)
the other direction is a partial function.
Generalization conflicts
Semantically similar entities are represented at
different levels of generalization in two Web
services
Web service 1
GRAD-STUDENT (ID,
Name, Major)
Aggregation conflicts
Semantically similar entities are represented at
different levels of generalization in two Web
services
Web service 1
PROFESSOR (ID, Name,
Dept)
Attribute Entity conflicts
Semantically similar entity modeled as an
attribute in one service and as an entity in the
other
Web service 1
Web service 2
COURSE (ID, Name, Semester) DEPT( Course,
Sem, .., ..)
Web service 2 * A set-of Professor entities is a Faculty entity. When the
FACULTY (ID, output of WS1 is a Professor entity, it is possible to
ProfID, Dept) identify the Faculty group it belongs to, but generating a
mapping in the other direction is not possible.
* Course modeled as an entity by WS1 is modeled as an
attribute by WS2. With definition contexts, mappings can
be specified in both directions.
* Interoperation between services needs transformation rules (mapping) in addition to annotation of the entities and/or attributes indicating their
semantic similarity (matching).
WSDL-S
• Offer an evolutionary and compatible upgrade of
existing Web services standards
• Externalize the semantic domain models
– agnostic to ontology representation languages
– reuse of existing domain models
– allows annotation using multiple ontologies (same or
different domain)
• updating tools around WSDL is relatively easier
Semantic annotations on WSDL
elements
Extension Element /
Attribute
Description
modelReference
(Element: Input and
Output Message types)
Semantic annotation of WSDL input
and output message types with
concepts in a semantic model.
schemaMapping
(Element: Input and
Output Message types)
Association of structural and syntactic
mappings between WSDL message
types and concepts in a semantic
model.
modelReference
(Element:
Operation)
Captures the semantics of the
functional capabilities of an operation.
pre-conditions
(Parent Element:
Operation)
Set of semantic statements (or
expressions represented using the
concepts in a semantic model) that are
required to be true before an operation
can be successfully invoked
effects
(Parent Element:
Operation)
Set of semantic statements (or
expressions represented using the
concepts in a semantic model) that
must be true after an operation
completes execution.
category
(Parent Element:
Operation)
Service categorization information that
could be used when publishing a
service in a Web Services registry
such as UDDI.
Using WSDL-S to interoperate
semantic match
<wsdl:types>
(...)
<complexType name=“Address">
<sequence>
<element name=“StreetAd1“ type="xsd:string"/>
<element name=“StreetAd2" type="xsd:string"/>
...........
</sequence>
</complexType>
(...)
</wsdl:types>
Address
hasStreetAddress
StreetAddress
hasCity
xsd:string
hasZip
xsd:string
WSDL complex type element
OWL ontology
1. modelReference to establish a semantic
association
2. schemaMapping to resolve structural
heterogeneities beyond a semantic match
Using WSDL-S to interoperate
• Associate mappings using the
'schemaMapping' attribute on Web service
message (input and output) elements.
• Use mappings as follows
Implementation using AXIS2
• Data mediation implemented as
module+handler in Axis2
– Validation of our philosophical choice (reusing
existing WS infrastructure)
• Heterogeneous Web service messages
intercepted at AXIS and transformed to
facilitate interoperation
Nagrajan et al: Semantic Interoperability in Web services - Challenges and Experiences
WSDL-S - Use Cases and Standardization
Activity
• International Bank Use Case
• Agriculture Produce Market Committee (APMC India
Use Case)
• Bioinformatics Use Case
International Bank Use Case
• This bank is considering moving to SOA based architecture
• They feel WSDL has following shortcomings
– Schema level
• Unable to define well known restrictions: email, credit card
number
• Unable to define detail description for enumerations: SPD for
Summary Plan Description
• WSDL operation level
• pre-conditions and post-conditions of a service operation
• restrictions on elements / complexTypes that are operation specific
(e.g. customerId in CustomerType must be null for AddCustomer;
but it's mandatory for GetCustomer)
Use Case Details
• A search service is
defined to search by
either personal name or
commercial name.
• The search engine would
return at least one
element of names, or a
SOAP fault
Adding Contracts to WSDL
• In the use case, it’s expressed as the
following:
– A name has to be provided.
– If it’s a personal name, either last name or
personal name must exist.
– If it’s a commercial name, either corporate
name or stock ticker must exist.
– Either at least one or no more than 100 names
would be returned, or an error “not found” will
occur.
Some of the Preconditions
These conditions can be represented as preconditions in WSDL-S
Current Agri-Marketing scenario in
Buyers
India
Agriculture Produce
Market Committee
Seller: Farmer
Brokers associated
With APMC
Current Agri-Marketing scenario in
India
• A farmer can sell his produce to either
Agriculture Produce Market Committees or
Brokers associated with APMC’s.
• APMC’s sell the produce either by retail or
in open markets.
• Research is underway in creating SOA
based architectures to realize the buyer
seller interactions as services.
Current Agri-Marketing scenario in
India
• Farmers use kiosks to interact with the buyer
services
• Farmers need to locate the right APMC for their
products
– Some APMC’s may not have refrigeration making them
unsuitable for fresh vegetables, diary products etc.
– Farmers might want to get paid in cash the same day
whilst some APMC’s may not be willing to do so.
• Farmers use the web based interface to then sell
their produce to the APMC.
Why WSDL-S?
• Uses semantics to provide richer descriptions of
the services offered by APMC’s.
– An APMC buys wheat, potatoes, fresh meat and dairy
products. The APMC can use WSDL-S to represent this
information in his service description.
– Allows for capturing policies such as “Refrigeration is
free for 2 business days” or “Same day payment will be
issued in cash”
• Various APMC’s have varying data definitions. It
is hard to create a client that can interoperate,
due to heterogeneities that are present. WSDL-S
help address them by mediation.
Using WSDL-S in Bioinformatics
• ProPreO - Experimental Proteomics
Process Ontology (CCRC / LSDIS)
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:ngp"
……
xmlns:wssem="http://www.ibm.com/xmlns/WebServices/WSSemantics"
xmlns:ProPreO="http://lsdis.cs.uga.edu/ontologies/ProPreO.owl" >
<wsdl:types>
<schema targetNamespace="urn:ngp"
xmlns="http://www.w3.org/2001/XMLSchema">
……
</schema>
</wsdl:types>
<wsdl:message name="replaceCharacterRequest"
wssem:modelReference="ProPreO#peptide_sequence">
<wsdl:part name="in0" type="soapenc:string"/>
<wsdl:part name="in1" type="soapenc:string"/>
<wsdl:part name="in2" type="soapenc:string"/>
</wsdl:message>
......
Excerpt: Bio-informatics Web service WSDLS
data
sequence
peptide_sequence
Excerpt: ProPreO – process ontology
CCRC – Complex Carbohydrate Research Center www.ccrc.uga.edu
ProPreO - http://lsdis.cs.uga.edu/projects/glycomics/propreo/
Dynamic Process Configuration
Sample Supply Chain Scenario
• Consider a simplified supply chain process
of a computer manufacturer
– Most parts are multiple sourced
• Overseas goods cheaper but greater lead times than
internal/local suppliers
– Need to deal with 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 configuration Problem
Receive
Find optimal partners for the process based on process
constraints @ run time– cost, supply time, etc.
Configure: Discover
VP1:
getMBQuote
VP2:
getProcQuote
Configure: Analyze
VP1: orderMB
Reply
VP2:orderProc
Conceptual
ProposedApproach
Solution
1.
framework to
to represent
capture &domain
represent
domain
1. Create
Use of ontologies
knowledge
knowledge
2. Use semantic knowledge captured in ontologies
2. Represent
constraints
on the domain knowledge
across the process
lifecycle
3.
to reason on
the constraints
configure
3. Ability
A multi-paradigm
constraint
analysisand
based
the
process
approach
to handle quantitative and logical
constraints
Dynamic Process Configuration
• Dynamic Process Configuration
– Finding optimal partners for a process based on service
and process constraints
• 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 non-functional
requirements (Constraint Analysis)
Abstract Process Specification
Receive
•
Specify process
control flow by
using virtual
partners
•
Capture Functional
Requirements of
Services using
Semantic
Templates
•
Specify Process
Constraints
Configure: Discover
VP1:
getMBQuote
VP2:
getProcQuote
Configure: Analyze
VP1: orderMB
Reply
VP2:orderProc
Abstract Process Specification
Receive
Configure: Discover
VP1:
getMBQuote
VP2:
getProcQuote
Configure: Analyze
VP1: orderMB
Reply
VP2:orderProc
• Semantic Templates capture
the functionality of a Web
service with the
of process
1. help
Specify
ontologies/other domain
control flow by
models
using virtual
• Find a service thatpartners
sells RAM
in Athens, GA. It must allow
the user to return and cancel,
2. Capture Functional
if needed
of
• The template can Requirements
also have
Services using
non-functional (QoS)
Semantic
requirements such
as
Templates
response time, security,
etc.
3. Specify Process
Constraints
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.
Sample Semantic Template
Service Level MetaData
IndustryCategory = NAICS:Electronics
ProductCategory = DUNS:RAM
Location = Athens, GA
Semantically Defined Operations
Operation1 =
Rosetta#requestPurchaseOrder
Input = Rosetta#PurchaseOrderDetails
Output = Rosetta#PurchaseConfirmation
ResponseTime < 5s
Operation2 = Rosetta#CancelOrder
…
Operation3 = Rosetta#ReturnProduct
Part of Rosetta
Net Ontology
PIP
RequestPurchase
Order (3A4)
QueryOrderStatus
(3A5)
CancelOrder (3A9)
hasInput
hasOutput
PurchaseOrderDetails
PurchaseOrderConfir
mation
ReturnProduct
(3C1)
Data Semantics
Functional Semantics
Non-Functional Semantics
*WSDL-S is used to capture semantic templates
Abstract Process Specification
Receive
Configure: Discover
VP1:
getMBQuote
VP2:
getProcQuote
Configure: Analyze
VP1: orderMB
Reply
VP2:orderProc
1. Specify process
control flow by
using virtual
partners
2. Capture Functional
Requirements of
Services using
Semantic
Templates
3. Specify Process
Constraints
Process Constraints
• Constraints can be specified at an
appropriate level: an activity (operation of
a partner), a partner, 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
<1000
Dollars
Σ
Partner 1
Satisfy
True
Process
Satisfy
True
Constraint Analysis
• Multi-paradigm approach used
– ILP for quantitative constraints
– SWRL for logical 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
Verma et al: Semantics-enabled Configuration of Web Processes
Configuration Architecture
CANDIDATE SERVICES WITH
CONSTRAINTS
DISCOVERY
ENGINE
RAM Candidate Service 1 (R1)
Q: Cost = $800
Q: SupplyTime < 5 Days
RAM Candidate Service 4 (R4)
Q: Cost = $720
Q: SupplyTime < 7 Days
RAM Candidate Service 5 (R5)
Q: Cost = $850
Q: SupplyTime < 7 Days
UDDI
MB Candidate Service 1 (M1)
Q: Cost = $850
Q: SupplyTime < 7 Days .
MB Candidate Service 2 (M2)
Q: Cost = $800
Q: SupplyTime < 5 Days .
.
MB Candidate Service (M3)
Q: Cost = $900
Q: SupplyTime <6 Days
PROCESS CONSTRAINTS
Q: Cost <= $2000
Q: SupplyTime < 7 Days
L: Compat (P1, P2)= True
L: preferredSupplier(P1) = True
Min: Cost
CONSTRAINT
ANALYZER
ILP Solver
SWRL
Reasoner
SERVICE SETS IN INCREASING
COST ORDER
1. R1, M2
Cost = $1600
2. R4, M3
Cost = $1620
3. R5, M1
Cost = $1700
COMPATIBLE
SERVICE SETS IN
INCREASING COST
ORDER
1. R1, M2
Cost = $1600
2. R5, M1
Cost = $1700
(REJECTED SET 2
as R4 not compatible
wit M3)
Semantic Discovery
• Finds actual services matching semantic templates
• Implemented as a layer over UDDI
• 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 [1] to consider operations and
service level metadata
– Extends the approach presented “WSDL to UDDI Mapping” [2]
to support operation level discovery
[1] M. Paolucci, T. Kawamura, T. Payne and K. Sycara, Semantic Matching of Web Services Capabilities, ISWC 2002.
[2] 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
Quantitative Constraint Analysis
• A service is used (1) or not used (0)
–
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 such that one service
is 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  2000
• 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
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
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
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)
Configuration Example
CANDIDATE SERVICES WITH
CONSTRAINTS
DISCOVERY
ENGINE
RAM Candidate Service 1 (R1)
Q: Cost = $800
Q: SupplyTime < 5 Days
RAM Candidate Service 4 (R4)
Q: Cost = $720
Q: SupplyTime < 7 Days
RAM Candidate Service 5 (R5)
Q: Cost = $850
Q: SupplyTime < 7 Days
UDDI
MB Candidate Service 1 (M1)
Q: Cost = $850
Q: SupplyTime < 7 Days .
MB Candidate Service 2 (M2)
Q: Cost = $800
Q: SupplyTime < 5 Days .
.
MB Candidate Service (M3)
Q: Cost = $900
Q: SupplyTime <6 Days
Discovery
Results
PROCESS CONSTRAINTS
Q: Cost <= $2000
Q: SupplyTime < 7 Days
L: Compat (P1, P2)= True
L: preferredSupplier(P1) = True
Min: Cost
CONSTRAINT
ANALYZER
ILP Solver
SWRL
Reasoner
SERVICE SETS IN INCREASING
COST ORDER
After
ILP
1. R1, M2
Cost = $1600
2. R4, M3
Cost = $1620
3. R5, M1
Cost = $1700
COMPATIBLE
SERVICE SETS IN
INCREASING COST
ORDER
1. R1, M2
Cost = $1600
2. R5, M1
Cost = $1700
(REJECTED SET 2
as R4 not compatible
wit M3)
After
SWRL
Implementation Details
• Entities
– 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
• Infrastructure
– Implemented as modules in Axis 2.0
• Phases
– Pre-binding
• Number of services bound to same service manager. Used for information
gathering for constraint analysis
– Binding
• Constraint Analysis and binding optimal partner to each SM
– Post-binding
• Normal process execution with optimal partner
Runtime Configuration Example
Pre-Binding phase
M1
SM1
M2
Receive
M3
Configure: Discover
P1
P2
SM2
VP1:
getMBQuote
VP2:
getProcQuote
P3
Binding phase
Configure: Analyze
Post-Binding phase
VP1: orderMB
Discover partners and
Get quote from all
partners
VP2:orderProc
Analyze process
constraints and create
a set of optimal
partners
Process execution with
set of optimal partners
SM1
M2
SM3
P1
Reply
Incorporating Configuration support in
Axis 2.0
Actual
WS (s)
EPR
Resolution
Module
Invoke service(s)
using physical EPR
Invocation
WS
Apache Axis
2.0 Inflow
Dispatch
phase
Create entry in
Logical to
Physical EPR
Map
Web
Service
response
Apache
Axis 2.0
Outflow
Pre-Dispatch
phase
Configuration
Module
Transport
phase
Configure
Process if
needed
METEOR-S
phase
METEOR-S
MIDDLEWARE
Service Invocation/
Configuration
Message
Workflow Engine
(IBM BPWS4J)
Web Service
response
Process Adaptation
Process Adaptation
Adaptation Problem
Receive
Optimally react to events like delays in ordered
goods
Configure: Discover
VP1:
getMBQuote
VP2:
getProcQuote
Configure: Analyze
VP1: orderMB
ProposedApproach
Solution
Conceptual
1. Maintain
Use of stochastic
decision
making framework to
state of the
process
deduce optimal actions
2. Capture costs while transitioning from abnormal
states to goal state(s)
3. Ability to decide optimal actions on the basis of
state
VP2:orderProc
Order
Wait for
Delivery
Reply
Order
received
Received
Optimal to
change
supplier
Order
delayed
Order
received Delayed
Optim
al to
wait
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
Revisiting the Supply Chain Scenario
• After order for the parts are placed, they
may get delayed
• The manufacturer may have severe costs
(losses) 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
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
• Proposed Solution
– Use a stochastic decision making framework to deal with
such failures
• Currently we use Markov Decision Processes
State Based Representation (costs not
shown)
Order
Order
W
Order
si 1
Cancel
si
S1 - Ordered = True (All other flags false)
S4 - Ordered = True and Received = false
S5 - Ordered = True and Delayed = false
---Transition due to action
- - Exogenous events
(example probabilities of occurrences of events
si6
conditioned on the states)
Order
8
Del
0.45
si
Cancel
si 3
Rec
2
Rec
0.35
0.85
Return
W
si5
W
si7
Return
si 4
W
Generating States using preconditions
and effects
Actions
Pre: Ordered = False
Events
Operation: Order
Post: Ordered = True
Pre: Ordered = True &
Received = false
Event: Delayed
Pre: Ordered = True &
Received = false
Flags
Ordered
Post: Delayed=True &
Ordered = True
Operation: Cancel
Received
Post: Canceled=True &
Ordered = false
Pre: Ordered = True &
Received = false
Delayed
Pre: Ordered = True &
Received = True
Event: Received
Post: Received = True
Operation: Return
Post :Returned = True &
Ordered = false and
Received = false
Cancelled
Returned
Use an algorithm similar to reachability analysis to generate states
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
K. Verma, P. Doshi, K. Gomadam, J. Miller, A. Sheth, Optimal Adaptation in Autonomic Web Processes
with Inter-Service Dependencies, LSDIS Lab, Technical Report, November 2005
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
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
Variations in Chinese and Taiwanese
Currency
Source for graphs and data: www.x-rates.com
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 (DB-ILP) Always the lowest cost, logical
constraints not guaranteed
– With ILP and SWRL (DB-ILP+SWRL) Lowest cost for
partners satisfying all constraints
Results – Process Configuration
Process cost per unit (in $)
Static Binding
DB - ILP
DB - ILP + SWRL
250
240
230
220
210
200
190
180
170
160
150
1
2
3
4
5
6
Day Number
7
8
9
10
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
M-MDP: Centralized
Hyb. MDP
Average Cost
KEY
MDP-CoM
1700
Random: Random process (changes
suppliers for 50% of delays)
Hyb. Com: Hybrid
1300
900
MDP-Com: Decentralized
0.1
0.6
0.7
0.6
0.7
2500
2500
M-MDP
M-MDP
Random
Random
Average Cost
2100
Hyb. MDP
Average Cost
0.3
0.4
0.5
Probability of delay
Cost of Waiting = 400
Cost of Waiting = 300
2100
0.2
MDP-CoM
1700
Hyb. MDP
MDP-CoM
1700
1300
1300
900
900
0.1
0.2
0.3
0.4
0.5
Probability of delay
0.6
0.7
0.1
0.2
0.3
0.4
0.5
Probability of delay
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
Conclusions, Related Work and
Future Agenda
Summary - Dynamic Process
Configuration
• Allows optimal selection of partners for a process
– The optimal process is not always the cheapest process
as the domain constraints must also be respected
• Processes can be configured to handle the
following cases:
– In volatile environments where changes may render
older configurations sub-optimal (e.g. changes in
currency exchange rates, new discounts by suppliers)
– When the constraints change
– Can replace services in case of physical failures by
caching results from configuration module
Summary - Adaptation
• 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
• Intelligent decision making can reduce
costs for 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
• We extend previous work in this area
– Cost based adaptation
– Coordination Constraints
[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.
Conclusions
•
Provided a framework for configuration and adaptation of Semantic Web
Processes
•
Contributions
– Proposed WSDL-S
• which is now an important input to two W3C charters for Semantic Web Services
Specifications
– Handled process configuration with both quantitative and logical constraints
using a multi-paradigm approach
• Typical real world use cases require handling both
– Studied the utility of Markov Decision Processes for optimal adaptation of Web
processes
•
Future Directions
– Autonomic Web Processes
– Applying Semantics to Service Sciences
– Semantics and Lightweight services – AJAX, REST
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, LSDIS Lab Technical Report, 2005.
– 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
Publications
• Semantic Web Service Discovery
– 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
• Semantic Annotation/Representation
– 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 Web Composition
– 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
Resources
METEOR-S (also tools and downloads):
http://lsdis.cs.uga.edu/projects/meteor-s/
WSDL-S:
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/
Publications/Resources:
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/