Post on 28-Jun-2020
Introduction Framework Conclusion
Modeling and Analyzing Timed Web
Services Protocols
Julien Ponge1,2 – ponge@isima.fr
http://www.isima.fr/ponge/
1Laboratoire LIMOS, ISIMA, Clermont-Ferrand, France
2Computer School of Engineering, The University of New South Wales, Sydney,Australia
ICSOC’05 PhD Symposium
1 / 35
Introduction Framework Conclusion
Agenda
IntroductionWeb services todayOutline of approach
FrameworkTimed business protocolsTemporal compatibility and replace-ability analysisServiceMozaic
ConclusionConclusionPerspectives and future work
2 / 35
Introduction Framework Conclusion
Agenda
IntroductionWeb services todayOutline of approach
FrameworkTimed business protocolsTemporal compatibility and replace-ability analysisServiceMozaic
ConclusionConclusionPerspectives and future work
3 / 35
Introduction Framework Conclusion
Web services?
• Middlewares evolution (RPC / MOM) [Alonso, Casati,Kuno, Machiraju].
• Extensive use of standards (XML, SOAP, HTTP(S),SMTP, ...).
• Loose-coupling, easier integration.
4 / 35
Introduction Framework Conclusion
On the developer’s side...
• SOAP / WSDL are wellaccepted.
• Static / Dynamic binding.
• Rich services (ex: Amazon AWS)provide many messages.
• ”Understanding” a service canbe tedious.
• Low-level standards, lots ofmanual processes.
5 / 35
Introduction Framework Conclusion
Agenda
IntroductionWeb services todayOutline of approach
FrameworkTimed business protocolsTemporal compatibility and replace-ability analysisServiceMozaic
ConclusionConclusionPerspectives and future work
6 / 35
Introduction Framework Conclusion
Capturing conversations
• Business protocols that describe the externalbehavior [Benatallah, Casati, Toumani].
• Based on deterministic automata.
• A conversation is a complete interaction.
• Easy to understand, well-suited and has formalsemantics.
• Expressiveness / complexity trade-off.
• Extensible (ex: time, transactions, policies, ...).
7 / 35
Introduction Framework Conclusion
A business protocol (subset of Amazon AWS)
searchIn
cartRequestOutstart
searchOut shopping
cartRequestIn
keywordSearchRequest(+)
keywordSearchResponse(-)
addShoppingCartItemsRequest(+)
modifyShoppingCartItemsRequest(+)
removeShoppingCartItemsRequest(+)
keywordSearchRequest(+)getShoppingCartRequest(+)
shoppingCartResponse(-)
modifyShoppingCartItemsRequest(+)
addShoppingCartItemsRequest(+)
removeShoppingCartItemsRequest(+)
getShoppingCartRequest(+)8 / 35
Introduction Framework Conclusion
A need for temporal abstractions
• Business protocols only specify the allowed messagesorderings.
• There are countless examples (deadlines, soft-locks, ...).
• This abstraction is essential to better ”understand” theexternal behavior of a service.
9 / 35
Introduction Framework Conclusion
Research problem and applications
SummaryTake temporal abstractions into account and perform flexiblecompatibility and replace-ability analysis by using a protocoloperators based algebra.
Why?
• Help in making a compliant implementation (ex: againstspecifications such as RosettaNet).
• Generate adapters in case of mismatches [HamidMotahari].
• Support evolution.
• Enhanced discovery and dynamic binding.
10 / 35
Introduction Framework Conclusion
Research problem and applications
SummaryTake temporal abstractions into account and perform flexiblecompatibility and replace-ability analysis by using a protocoloperators based algebra.
Why?
• Help in making a compliant implementation (ex: againstspecifications such as RosettaNet).
• Generate adapters in case of mismatches [HamidMotahari].
• Support evolution.
• Enhanced discovery and dynamic binding.
10 / 35
Introduction Framework Conclusion
Agenda
IntroductionWeb services todayOutline of approach
FrameworkTimed business protocolsTemporal compatibility and replace-ability analysisServiceMozaic
ConclusionConclusionPerspectives and future work
11 / 35
Introduction Framework Conclusion
Extended model
• A user-oriented model.
• Introduction of implicittransitions.
• Models temporalavailability windows anddeadlines.
s0
s1
s2
a(+)
b(+)
P
s3i1: 60s
s4
b(+) c(+)
12 / 35
Introduction Framework Conclusion
Formalization
Web services business protocolP = (S, s0,F , M,R)
Timed web services business protocol [BDA’05,CAiSE’05 Forum]
• M = Me ∪ Mi
• For R(s, s′, m), m ∈ Mi, we defineTime(s, m) → t ∈ Q≥0.
13 / 35
Introduction Framework Conclusion
Formalization
Web services business protocolP = (S, s0,F , M,R)
Timed web services business protocol [BDA’05,CAiSE’05 Forum]
• M = Me ∪ Mi
• For R(s, s′, m), m ∈ Mi, we defineTime(s, m) → t ∈ Q≥0.
13 / 35
Introduction Framework Conclusion
Formalization – cont.
• Deterministic.
• At most 1 implicit outgoing transition per state.
• Deadlocks-free.
• Assumptions:• instantaneous transitions• time relative to the entrance in a state s• every state is reachable• no implicit circuits• messages semantics is another issue.
14 / 35
Introduction Framework Conclusion
Semantics
2 kind of constraints:
• conversations – Linear time
a(+) · b(−) · c(+)
• temporal – timed traces
(a(+), 0) · (b(−), 3) · (c(+), 20)
We focus on observable traces.
15 / 35
Introduction Framework Conclusion
A few lessons from timed automata [Alur, Dill]
Facts
• TA are more expressive and less user-friendly.
• Many decision problems are undecidable, unless youchoose adequate subclasses and pay attention to theconstraints grammar.
• ε-transitions are a problem, but can sometimes beremoved, under certain conditions.
−→ We have mappings and use TA to identify properties onour model.−→ Interestingly, implicit transitions are not a problem in ourcase.
16 / 35
Introduction Framework Conclusion
A few lessons from timed automata [Alur, Dill]
Facts
• TA are more expressive and less user-friendly.
• Many decision problems are undecidable, unless youchoose adequate subclasses and pay attention to theconstraints grammar.
• ε-transitions are a problem, but can sometimes beremoved, under certain conditions.
−→ We have mappings and use TA to identify properties onour model.−→ Interestingly, implicit transitions are not a problem in ourcase.
16 / 35
Introduction Framework Conclusion
Agenda
IntroductionWeb services todayOutline of approach
FrameworkTimed business protocolsTemporal compatibility and replace-ability analysisServiceMozaic
ConclusionConclusionPerspectives and future work
17 / 35
Introduction Framework Conclusion
Compatibility
s0 s1 s2a(+) b(+)
s0' s1' s2'a(-) b(-)
P1
P2
2 services can talk to each other
18 / 35
Introduction Framework Conclusion
Replaceability
s0 s1 s2a(+) b(+)
s0' s1' s3'a(+) b(+)
P1
P2
s2'c(+)
1 service can replace another one
19 / 35
Introduction Framework Conclusion
Classes
• Partial or full compatibility.
• Replace-ability:• equivalence, subsumption, partial replace-ability• w.r.t. client protocol• w.r.t. interaction role.
−→ the flexibility introduced by these classes is original andneeded by the versatility induced by the web.
20 / 35
Example: replace-ability w.r.t. a client protocol
creditExpired
start logged
vehicleSelection
preApprovalApplication
creditApproved
applicationRejected
cancelled
paymentEstimation
creditApplication
creditAccepted
login(+)
accountManagement(+)
preApproval(+)
reject(-)
approved(-)
30 days
selectVehicle(+)
selectVehicle(+)
budgetPlanner(+)
leaseOrBuyTest(+)
modifySelection(+)
cancel(+)
estimatePayment(+)
reApplication(+)
30 hours
fullCredit(+)
accept(-)
reject(-)
Example: replace-ability w.r.t. a client protocol
start
applicationRejected
logged
vehicleSelection
paymentEstimation
creditApplication
creditAccepted
cancelled
login(+)
changeLoginInfo(+)
selectVehicle(+)
estimatePayment(+)
fullCredit(+)
reject(-) accept(-) 15 hours
Example: replace-ability w.r.t. a client protocol
start
applicationRejected
logged
vehicleSelection
paymentEstimation
creditApplication
creditAccepted
cancelled
login(+)
changeLoginInfo(+)
selectVehicle(+)
estimatePayment(+)
fullCredit(+)
reject(-) accept(-) 15 hours
Example: replace-ability w.r.t. a client protocol
creditExpired
start logged
vehicleSelection
preApprovalApplication
creditApproved
applicationRejected
cancelled
paymentEstimation
creditApplication
creditAccepted
login(+)
accountManagement(+)
preApproval(+)
reject(-)
approved(-)
30 days
selectVehicle(+)
selectVehicle(+)
budgetPlanner(+)
leaseOrBuyTest(+)
modifySelection(+)
cancel(+)
estimatePayment(+)
reApplication(+)
30 hours
fullCredit(+)
accept(-)
reject(-)
Introduction Framework Conclusion
Timed business protocols operators
• Timed compatible composition: ‖TC
• Timed intersection: ‖TI
• Timed difference: ‖TD
• Projection: [P1 ‖TC P2]P1
22 / 35
Introduction Framework Conclusion
Example: timed difference
s0
s3
s1 s2
s4
i: 3min
a(-) b(+)
c(+)
s0 s1 s2 s3a(-) b(+) c(+)
s0 s1 s2
s4
a(-) b(+) s2i: 3min
c(+)
P3 = P2 !TD P1
P1
P2
P3
23 / 35
Introduction Framework Conclusion
Characterization
• We can characterize the compatibility and replace-abilityclasses with these operators.
• Ex: TReplPC(P1,P2)
PC ‖TC (P2 ‖TD P1) = ∅
• Polynomial-time complexity algorithms.
24 / 35
Introduction Framework Conclusion
Agenda
IntroductionWeb services todayOutline of approach
FrameworkTimed business protocolsTemporal compatibility and replace-ability analysisServiceMozaic
ConclusionConclusionPerspectives and future work
25 / 35
Introduction Framework Conclusion
Goals
• A model-driven conceptual framework and a CASEtoolset.
• Support for design, development and management of webservices.
• Technologies: Eclipse + J2EE.
26 / 35
Analysis & management interface
Trust negotiation protocol editor
Business protocol editor
Composition editor
Mismatch pattern editor
Development environment
Adapter generator
Model generator
Protocol analysis & manipulation operators
Analysis & managementcomponents
Models representation, storage and manipulation components
Mismatch patterns
templates
Service descriptions
& models
Repositories
Calls from externalclients via SOAP
interface
Introduction Framework Conclusion
Specificities
• Techniques for analyzing and managing servicesinteractions at the protocol and traces level.
• Re-engineering (ex: protocols mining).
• Scalable development.
• Protocols evolution.
• Execution monitoring support.
28 / 35
Introduction Framework Conclusion
Agenda
IntroductionWeb services todayOutline of approach
FrameworkTimed business protocolsTemporal compatibility and replace-ability analysisServiceMozaic
ConclusionConclusionPerspectives and future work
29 / 35
Introduction Framework Conclusion
Related work
• Timed automata [Alur, Dill].
• The (many) ”standardization” efforts.
• Temporal logics and their extensions.
• Work on components in software engineering.
30 / 35
Introduction Framework Conclusion
What has been done
Flexible context-oriented model and analysis:
• Temporal extension of the business protocol model[BDA’05, CAiSE’05 Forum].
• Timed operators to characterize the compatibility /replace-ability classes.
• Polynomial-time timed operator algorithms.
• Protocols library (untimed) and editor for theServiceMozaic platform.
31 / 35
Introduction Framework Conclusion
Agenda
IntroductionWeb services todayOutline of approach
FrameworkTimed business protocolsTemporal compatibility and replace-ability analysisServiceMozaic
ConclusionConclusionPerspectives and future work
33 / 35
Introduction Framework Conclusion
Perspectives and future work
• A more expressive temporal constraints framework.
• Multi-protocols analysis (open issues).
• Protocol changes management.
• Timed implementations for the ServiceMozaic platform.
• Other abstractions investigations (transactions).
34 / 35
Thanks!