Modeling and Analyzing Timed Web Services Protocolsceur-ws.org/Vol-169/presentation10.pdf · Introduction Framework Conclusion Agenda Introduction Web services today Outline of approach

Introduction Framework Conclusion

Modeling and Analyzing Timed Web

Services Protocols

Julien Ponge1,2 – [email protected]

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

[email protected]

http://www.isima.fr/ponge/


Agenda

IntroductionWeb services todayOutline of approach

FrameworkTimed business protocolsTemporal compatibility and replace-ability analysisServiceMozaic

ConclusionConclusionPerspectives and future work

2 / 35


Agenda




3 / 35


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


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


Agenda




6 / 35


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


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


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


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


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


Agenda




11 / 35


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


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


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


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


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


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


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


Agenda




17 / 35


Compatibility

s0 s1 s2a(+) b(+)

s0' s1' s2'a(-) b(-)

P1

P2

2 services can talk to each other

18 / 35


Replaceability

s0 s1 s2a(+) b(+)

s0' s1' s3'a(+) b(+)

P1

P2

s2'c(+)

1 service can replace another one

19 / 35


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(-)


start

applicationRejected

logged

vehicleSelection

paymentEstimation

creditApplication

creditAccepted

cancelled

login(+)

changeLoginInfo(+)

selectVehicle(+)

estimatePayment(+)

fullCredit(+)

reject(-) accept(-) 15 hours


start

applicationRejected

logged

vehicleSelection

paymentEstimation

creditApplication

creditAccepted

cancelled

login(+)

changeLoginInfo(+)

selectVehicle(+)

estimatePayment(+)

fullCredit(+)

reject(-) accept(-) 15 hours


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(-)


Timed business protocols operators

• Timed compatible composition: ‖TC

• Timed intersection: ‖TI

• Timed difference: ‖TD

• Projection: [P1 ‖TC P2]P1

22 / 35


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


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


Agenda




25 / 35


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


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


Agenda




29 / 35


Related work

• Timed automata [Alur, Dill].

• The (many) ”standardization” efforts.

• Temporal logics and their extensions.

• Work on components in software engineering.

30 / 35


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


Agenda




33 / 35


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!

Documents

Modeling and Analyzing Timed Web Services Protocolsceur-ws.org/Vol-169/presentation10.pdf · Introduction Framework Conclusion Agenda Introduction Web services today Outline of approach