a new model for web services timed business protocols · 2006-06-06 · a new model for timed...

A New Model For Web Services TimedBusiness Protocols

Julien Ponge

Laboratoire LIMOSUniversité Blaise Pascal – Clermont-Ferrand 2ISIMA - Campus des Cézeaux63173 Aubière cedex, [email protected]

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

ABSTRACT. Web services technology is emerging as the main pillar of service-oriented archi-tectures (SOAs). This technology facilitates application integration by enabling programmaticaccess to applications through standard, XML-based languages and protocols. While muchprogress has been made toward providing basic interoperability among applications, there arestill many needs and unexploited opportunities in this area. In particular, services in SOAsrequire richer description models than object or component interfaces since services are devel-oped independently of clients. Hence, service descriptions need to include all the informationneeded by clients to understand if they can interact with a service and how. This paper dis-cusses our new results on modeling and analyzing web services business protocols augmentedwith timing constraints. We discuss these notions informally through examples, and expose thebenefits of connecting our new model with the theory of timed automata.

KEYWORDS:web services, timed business protocols, applications integration, timed automata

Atelier Systèmes d’Information et Services Web, INFORSID 2006

2 Atelier SISW, INFORSID 2006

1. Introduction

Web services are increasingly gaining acceptance as a framework for facilitatingapplication-to-application interactions within and across enterprises. Application in-teroperability has been and still is a difficult issue due to difficulties created by hetero-geneous and autonomous systems. Web services provide abstractions and technolo-gies for exposing enterprise applications as services and make them accessible pro-grammatically through standardized interfaces. Indeed, the main benefit they bring toapplication integration is that of standardization, in terms of description languages, co-ordination, and interaction protocols. Standardization at interface definition language(WSDL) and transport protocol (SOAP) has enabled basic interoperability at messag-ing layer. While much progress has been made toward providing basic interoperability,there is still a lot to be done to simplify service development and interaction. In partic-ular, an important aspect of Web services that affects interoperability is that servicesare loosely-coupled, that is, are not developed only to interact with specific clients butare meant to serve the needs of many different clients, possibly developed by differentteams or even different companies. Hence, developers of client applications need to beaware of all functional and non-functional aspects of a service to be able to understandif they can/need interoperate with a service and how to develop clients that can inter-act correctly with the service. For this reason, service descriptions are richer thanjustdescriptions of interfaces as in conventional middleware. Specifically, it is commonlyaccepted that a service description should include not only the interface, but also thebusiness protocolsupported by the service, i.e., the specification of possible messageexchange sequences (conversations) that are supported by the service.

When developing our framework for service protocols modeling, analysis, andmanagement (Boualem Benatallahet al., 2004b), we identified the need for repre-senting temporal abstractions in protocol descriptions. In particular, our analysisof the characteristics and requirements of service protocols in terms of descriptionlanguages, we found that, in addition to message choreography constraints, protocolspecification languages need to cater for time-sensitive conversations (i.e., conversa-tions that are characterized by timing constraints on when an operation must or canbe invoked). For example, a protocol may specify that apurchase order message isaccepted only if it is received within 24 hours after aquotation has been received.

The work presented in this paper is the maturation of our earlier work that wefirst briefly recall. We then illustrate how it can be used to model a real-world webservice. After that, we present compatibility and replace-ability analysis as well as ourtimed protocol operators that can be used to characterize the various compatibility andreplace-ability classes. Then, we focus on the link between our model and the widelystudied formal verification framework of timed automata. This allows us to define 3different classes of timed protocols that exhibit interesting computationnal properties.Finally, we provide perspectives for future work.

A New Model For Timed Protocols 3

2. Toward an expressive model

2.1. Previous work

Theweb services business protocolmodel (Boualem Benatallahet al.,2004a) (pro-tocol in short) is based on deterministic automata, and allows to capture the set ofcom-plete conversationsbetween a service and its requester, where a conversation material-izes the message exchanges. In this model, a conversation is said to be complete whenending in a final state of a protocol. In (Boualem Benatallahet al.,2005b, BoualemBenatallahet al.,2005a), we have definedtimed web service business protocols(timedprotocolsin short) by addingimplicit transitions. While such transitions do not matchmessage exchanges, they correspond to a change of state in the protocol once a delay(expressed as a constant on the transition) has expired. This allows to both expressthese internal changes (yet they have an obvious external impact) and define temporalavailabilities for the explicit transitions. We have also extended theprotocol opera-torsdefined in the basic model to cater for timing constraints. In turn, these operatorscan be combined to characterize several flexible classes of protocol compatibility andreplace-ability. This can be useful to assist software architects, for example to checkfor conformance toward specifications such as RosettaNet1. However, the timed pro-tocol model that we have defined in (Boualem Benatallahet al.,2005b, Boualem Be-natallahet al., 2005a) suffers a notable expressiveness limitation in the sense thattiming constraints are always expressed against the last received or sent message. Forexample, this makes it impossible to refer to a message exchanged many explicit tran-sitions before. Also, the sole use of implicit transitions to specify timing constraintscan arguably make the model less friendly for developers. This why we present in thispaper a more expressive model and the impact on the operators that are used for per-forming analysis. Briefly, this new model removes the previous limitations and allowsto define richer timing constraints by making use of boolean operators instead ofjustdefining constants as timing constraints.

2.2. Modeling timed web services protocols

We give here an informal presentation of our model. To do that, we chose to derivea timed protocol from a real-world PKI2 provider service whose WSDL interface isavailable fromhttp://soapclient.com/xml/certService.wsdl. We have man-ually deduced the possible conversations between this service and its requesters byusing the protocols modeling tool which is part of our project named ServiceMosaic3

which is described in (Boualem Benatallahet al.,n.d.). The resulting timed protocolis depicted in Figure 1. Let us first have an overview of the model components beforeexplaining how this particular protocol operates. Each transition has an identifier of

1. http://www.rosettanet.org/2. Public Key Infrastructure.3. http://servicemosaic.isima.fr/


start enrolling

generatingRequest

signingCSR

ok

requestGenerated

simpleExchange

T 1 :enroll

T 2 :enrollResponse−

T 14 : generateRequest

T 15 : generateRequestResponse −

T 18:signCSR T 19: signCSRResponse −

T 4 : search ,T 5 : revoke ,T 6 :generateCLR , T 7: validate ,T 8: issue

T 9 : searchResponse − , T 10 :revokeResponse− ,T 11: generateCLRResponse− ,T 12: validateResponse− , T 13: issueResponse −

rejected

T 3 : rejection

T 17 : timeout

M−Invoke T1 =48h


M−Invoke T14 =24h

C−Invoke T 14 1h∨T 16 1h

C−Invoke T 14 ≤1h∨T 16 ≤1h

Figure 1. A timed protocolPs of a PKI provider service.

the formTi (i ∈ N). When a transition is explicit, we associate a message (which cor-responds to a message defined in the service WSDL document) that also has a polarity:(+) if the service receives the message, and(−) if it emits it. In turn, implicit tran-sitions (drawn with dashes on the figure) carry a convenient implicit message name.Timing constraints can be defined on transitions. In the case of an explicit transition,we can define C-Invoke (forcan invoke) constraints that specify the conditions to besatisfied in order to accept the transition. Conversely, we must define M-Invoke (formust invoke) constraints on implicit transitions that define when it has to be fired ifno explicit transition is fired from the same source state. The constraints are madefrom temporal constants, comparison operators and references to transition identi-fiers. For instance, the constraint defined with the transitionT3 on Figure 1 specifiesthat this transition will be automatically fired by the service provider 48 hours afterhaving received theenroll message. A conversation begins from the initial state of theprotocol (herestart). Finally, normal states correspond to intermediary states in theconversation, while final states (drawn with a double-border) correspond to completeconversations between the service provider and its requester.

Let us now explain how the service works. First of all, any operation provided bythe service requires a valid account. One can be obtained by providing the necessaryinformations in aenroll message (transitionT1 in our protocol). The enrollment canbe either validated by the service provider (T2) or silently rejected (T3). From there,most operations correspond to simple request / response message exchanges that wegrouped on the branch that goes through thesimpleExchange state. The rest of thetimed protocol is more interesting. Indeed, issuing a signed certificated can be done intwo steps by the service requester. To do that, the certificate needs to be first generated


start enrolling

oksimple

Exchange

T 1 :enroll − T 2 :enrollResponse

T 4 :revoke − , T−5 : issue −

T 6 :revokeResponse ,T 7: issueResponse

rejected

T 3 : rejection

M−Invoke T1 =48h

C−Invoke T 1 96d

Figure 2. A PKI service client protocolPc.

(generateRequest message) and then signed (signCSR message). Certificates areuseful only if they have been signed. A PKI provider is certainly not going to storesuch unsigned certificates for too long. Hence, a freshly generated certificate must besigned during the following hour (T18), else a new one has to be asked again (T16).Finally, a succession of failures to sign certificates is put to an end after 24 hours (T17).

3. Timed web services protocols analysis

3.1. Compatibility analysis

The timed protocol model is suitable for describing the set of conversations thata service supports. Let us now see how it can be used for analysis purposes. Morespecifically, we are interested incompatibilityandreplace-abilityanalysis. The for-mer aims at characterizing the possible conversations that can occur between a serviceprovider and its requesters, while the latter aims at characterizing when a service canact as a replacement for another one. We first give an example of compatibility byconsidering again the service provider protocolPs depicted on Figure 1 and the pro-tocolPc depicted on Figure 2 of a client that wants to use it. This client only uses asubset of the operations provided by the PKI service. After enrolling, it will only lookto issue and revoke certificates during the 96 days after having enrolled. One can seethis client as being defined in the context of a larger demonstration product that needsto be provided with short-term certificates. It is easy to see that both protocolsPs andPc are fully compatible, i.e., each valid conversation issued byPc will also be validfor Ps. The message choreography will be valid, and the timing constraints will alsobe satisfied.

3.2. Replace-ability analysis

Let us now illustrate a replace-ability example. To do that, consider the PKI ser-vice provider protocolPr depicted on Figure 3. While being similar toPs, it con-tains some noticeable differences. Indeed, it does not support receiving (and then


start enrolling

generatingRequest

signingCSR

ok

requestGenerated

simpleExchange

T 1 :enroll

T 2 :enrollResponse−


T 15 : generateRequestResponse −

T 18:signCSR T 19: signCSRResponse −

T 4 : revoke , T 5: issue ,T 6: renewEnrollment

T 9:revokeResponse − , T 10: issueResponse − ,T 11:renewEnrollmentResponse −

rejected

T 3 : rejection

T 17 : timeout

I−Invoke T 1 =48h


M−Invoke T14 =24h

C−Invoke T 14 1h∨T 16 1h

C−Invoke T 14 ≤1h∨T 16 ≤1h

expired

T 7 :expirationM−Invoke T 6 =365d∨T 1 =365d

Figure 3. Another PKI provider service protocolPr.

responding to)search, generateCLR andvalidate messages. Moreover, the ser-vice provider allows free enrollments for a year, but then a renewal needs to be per-formed, else no more operations will be possible and the enrollment will have ex-pired. This has been modeled by the addition of a pair ofrenewEnrollment andrenewEnrollmentResponse messages on the explicit transitionsT6 andT11. Also,an implicit transitionT7 has been added to model the expiration. Clearly,Pr cannotact as a replacement for the general requesters ofPs as it does not support all of itsmessages, it has some of them that are not supported byPs, and it has a new timingrequirement with the need for a yearly renewal. However, we can observe thatPc isfully compatible withPr. Indeed, the messages that it can potentially exchange aresupported byPr, and the timing constraints will be satisfied asPc will not attemptto perform any further operation after 96 days. This example illustrates what we callthereplace-ability with respect to client protocol. Pr cannot replacePs in the generalcase, but can still be used as a sound replacement ofPs to interact with the clientprotocol described byPc.

3.3. Compatibility and replace-ability classes

We have defined several flexible classes of compatibility and replace-ability(Boualem Benatallahet al.,2004a, Boualem Benatallahet al.,2005a) that we brieflyrecall. Compatibility between two protocols is eitherpartial or full. By contrast,replace-ability has more declinations. First, we have thefull replace-ability, wheretwo protocols can be interchangeably used in the general case. As in the case ofcompatibility, we also havepartial replace-ability. Next, we have theprotocol sub-


s0 s1 s2T 1: a T 2 :b

C−Invoke T 1 10 s

P1

s0 s1 s2T 1 :a − T 2 :b −

P2

s0 s1 s2T 1: a T 2 :b

P3

s3T 3:c

s0 s1 s2T 1: a T 2 :b

C−InvokeT 1 10s

P1 ||TC P2

s0 s1 s2T 1: a T 2 :b

C−Invoke T 1 10s

P1 ||TI P2

s0 s1 s2T 1: a− T 2 :b −

C−Invoke T 1 10s

[P1 ||TC P2]P2

s0 s1 s2T 1: a T 2 :b

P3 ||TD P1

s3T 3:c

C−Invoke T 1 ≥10 s

Figure 4. Examples of operators applications.

sumption, where a protocol supports at least all the conversations of another one (theopposite being not necessarly true). As we have illustrated, there is theprotocolreplace-ability w.r.t. a client protocol. Finally, there exists a variant of the former,namedprotocol replace-ability w.r.t. an interaction role, when a protocol behaves likeanother one for a given role. This replace-ability allows to identify the executions of aprotocol that can be replaced by another protocol even when they are not comparablewith respect to any of the previous classes.

3.4. Timed protocol operators

We have illustrated timed protocol compatibility and replace-ability, but it remainsto be seen how we can characterize the different classes. To do that, we have defineda set ofprotocol operatorsthat can be combined to characterize each class of compat-ibility and replace-ability (Boualem Benatallahet al.,2004a, Boualem Benatallahetal., 2005a). The operators can be applied to protocols, and return protocols as results.We recall here the timed protocol operators.

– Timed parallel composition, denoted as‖TC, captures the possible interactionsbetween two protocols.

– Projection, used to project the polarity of one protocol on the timed parallelcomposition of two protocols, denoted as[P1 ‖TC P2]P1

.

– Timed intersection, denoted as‖TI, captures the conversations that are commonto two protocols.

– Timed difference, denoted as‖TD, captures the conversations that are supportedby a service but not by another one.


To illustrate these operators, Figure 4 shows three simple timed protocolsP1, P2

andP3 as well as the results when applying operators on them.

4. Theoretical framework

In (Boualem Benatallahet al.,2005a), we have shown how timed protocol opera-tors could be used to characterize the various compatibility and replace-ability classes.With the extended timed protocol model presented in this paper, we consider below thedecision problems with timed protocol operators. More precisely, we identify 3 timedprotocol classes of different expressiveness, and provide results obtained through map-pings with the timed automata theory.

4.1. Timed protocol classes

We briefly present in degressive order of expressiveness the 3 timed protocolclasses, and illustrate them in the next paragraph.

1) Timed protocols(T P) represent the most general and expressive class. Timingconstraints can be defined to refer to both explicit and implicit transitions.

2) Restricted timed protocols(RT P) are a subclass of timed protocols. The dif-ference is that implicit transitions cannot be referenced in the timing constraints.

3) Event timed protocols(ET P) are a subclass of restricted timed protocols. Theconstraints reference messages rather than transitions in this class.

Let us illustrate some examples of timed protocols from different classes. Considerthe timed protocol depicted on Figure 5(a). It is a member of the timed protocolsclass. Indeed, transitionT4 has a C-Invoke constraint that references transitionT3

which is an implicit one. It is possible to express this timed protocol as a restrictedtimed protocol, by rewriting the constraint onT4 as C-Invoke(T1 < 13s). The classof timed protocol is however strictly more expressive than the class of restricted timedprotocols. Consider the protocol depicted on Figure 6, which is a translation of a theeventimed automaton (Beatrice Berardet al., 1999) into a timed protocol. It is notpossible to rewrite it as a restricted timed protocol. The proof is similar as in (BeatriceBerardet al.,1999): we can show by contradiction that the protocol would recognizetimed conversations with odd dates.

Let us now consider the protocol depicted on Figure 1: it is a restricted timedprotocol. Indeed, the constraints defined on the transitions of this protocol alwaysreference explicit transitions. The protocol depicted on Figure 5(b) is an event-timedprotocol as the transition constraints reference messages rather than transitions. Toillustrate that the class of event-timed protocols is contained in the class of restrictedtimed protocols, Figure 5(c) gives the protocol of Figure 5(b) rewritten as a restrictedtimed protocol. The opposite is not true however: Figure 5(d) shows a restricted timedprotocol that cannot be expressed as an event-timed protocol. Indeed, bothT1 andT3


s0 s2

s1 s3

T 1 :a

T 2 :b

T 4 :d C−Invoke T 3 10s

T 5 :c

T 3 : iM−Invoke T 1 =3s

s0 s2

s1 s3

T 1 :a

T 3 :a

T 2 :b

T 4 :c C−Invoke a10s

s0 s2

s1 s3

T 1 :a T 3 :a

T 2 :b

T 4 : cC−Invoke T 1 10s∨T 3 10s

s0 s2

s1 s3

T 1 :a

T 3 :a

T 2 :b

T 4 :c C−InvokeT 1 10s

(a)

(c)

(b)

(d)

Figure 5. Examples of timed protocols from various classes.

s's

T 2 : a C−Invoke T 1 =0 ∨T 3 =0

T 1: a

T 3: resetM−Invoke T1 =2 ∨T 2 =2

Figure 6. Theeventimed automaton viewed as a timed protocol.

have the messagea(+), andT4 has a constraint which referencesT1. In an event-timed protocol, the constraint will have to reference the message (a(+)) rather thanthe transition (T1), making it impossible to distinguish betweenT1 andT3.

4.2. Decision problems

The timed automata theory was presented in (Rajeev Aluret al., 1994a). Themain contribution is a formal model for reactive systems that operates on dense time.The model is based on finite state machines and regular languages. The formalism


start enrolling

oksimple

Exchange

T 1 :enroll −XT1

:=0

T 2 :enrollResponse X T1

48

T 4 :revoke − , T−5 : issue −

T 6 :revokeResponse ,T 7: issueResponse

rejected

T 3 :rejection

XT 1=48

XT 196 ×24

Figure 7. A PKI service client protocolPc as a timed automaton.

is also viewed as a generic framework to build more specific models on top of timedautomata, thus it is generic enough to be useful in various kinds of applications (hard-ware / software static verification, distributed computing, ...). The formalism has beenone of the most studied in the model checking domain, leading to several extensions,decision problems results, algorithms and tools (Rajeev Aluret al., 1994b, Beat-rice Berardet al., 1999, Bérardet al., 2000, Christian Choffrutet al., 2000, MariaSorea, 2001, Johan Bengtssonet al.,2003, Stavros Tripakis, 2003, Rajeev Aluret al.,2004, Joel Ouaknineet al.,2004).

We have defined mappings between our timed protocols model and specific timedautomata classes, and have found some interesting results to characterize our modeland the decision problems to perform analysis. Figure 7 presents the timed proto-col Pc of Figure 2 as a timed automaton. The biggest challenge that we have foundout is that in general, silent transitions4 are a problem. Indeed, timed automata withsilent transitions are strictly more expressive than timed automata (Beatrice Berardet al.,1999), which are in turn indeterministic in the general case. Worse, timed au-tomata are closed under all boolean operations but complementation. This means thatat first sight, the timed parallel composition operator and the timed intersection op-erator would have turned out to be decidable, but not the timed difference operator.Indeed, the difference reduces to an intersection between a protocol and the comple-ment of the other one. Interestingly, we have found that the timed protocols class wasexhibiting a deterministic behavior and was complementable, hence making the timeddifference operator decidable. As a result, compatibility and replace-ability analysisis decidable, as the 3 timed protocol classes are closed under intersection, union andcomplementation.

5. Conclusion and perspectives

We have presented in this paper a new model for web services business proto-cols augmented with timing constraints. This model is more expressive than what wehave done in earlier work. We can use it to perform analysis on flexible compatibil-

4. Sometimes calledε-transitions in the literature.


Figure 8. Screenshot of the ServiceMosaic web service protocols editor.

ity and replace-ability classes, by the mean of operators. We have established a linkwith timed automata, and we have used it to characterize decision problems for ouroperators. We have also derived 3 classes of timed protocols, with different expres-siveness and different mappings to timed automata classes. Our future work includesapplying these analysis techniques to web service compositions in presence of timingconstraints. We will also extend our existing Eclipse5-based CASE toolset platform,named ServiceMosaic (Boualem Benatallahet al.,n.d.), to cater for timed protocols.For the moment, it only supports modeling and analyzing basic business protocols(Boualem Benatallahet al.,2004a) as exposed on Figure 8

Acknowledgment: the work presented here, which is part of the ServiceMosaicproject, is made in collaboration with Farouk Toumani, Boualem Benatallah and FabioCasati.

5. Seehttp://www.eclipse.org/.


6. References

Beatrice Berard, Volker Diekert, Paul Gastin, Antoine Petit, Characterization of the expressivepower of silent transitions in timed automata, Technical report, LIAFA Jussieu, 1999.

Bérard B., Dufourd C., « Timed Automata and Additive Clock Constraints »,Information Pro-cessing Letters, vol. 75, n◦ 1-2, p. 1-7, July, 2000.

Boualem Benatallah, Fabio Casati, Farouk Toumani, « Analysis and Management of Web Ser-vices Protocols »,Proceedings of ER 2004. Shanghai, China, November, 2004a.

Boualem Benatallah, Fabio Casati, Farouk Toumani, « Web services conversation modeling:The Cornerstone for E-Business Automation »,IEEE Internet Computing, January, 2004b.

Boualem Benatallah, Fabio Casati, Farouk Toumani, Hamid R. Motahari Nezhad, Julien Ponge,« ServiceMosaic: a platform for model-driven analysis and management of Web services »,IEEE Internet Computing, to appear, n.d.

Boualem Benatallah, Fabio Casati, Julien Ponge, Farouk Toumani, « Compatibility and replace-ability analysis for timed web service protocols »,Proceedings of BDA 2005, Saint-Malo,France, October, 2005a.

Boualem Benatallah, Fabio Casati, Julien Ponge, Farouk Toumani, « On Temporal Abstractionsof Web Service Protocols. »,CAiSE Short Paper Proceedings, June, 2005b.

Christian Choffrut, Massimiliano Goldwurm, « Timed automata with periodic clock con-straints »,Journal of Automata, Languages and Combinatorics, n◦ 5, p. 371-404, July,2000.

Joel Ouaknine, James Worrell, « On the Language Inclusion Problem for Timed Automata:Closing a Decidability Gap »,Proceedings of LICS 04, IEEE Computer Society Press, 2004.

Johan Bengtsson, Wang Yi, « Timed Automata: Semantics, Algorithms and Tools. »,Lectureson Concurrency and Petri Nets, p. 87-124, 2003.

Maria Sorea, Tempo: A Model Checker for Event-Recording Automata, Technical report, SRIInternational, 7 November, 2001.

Rajeev Alur, David L. Dill, « A theory of timed automata »,Theoretical Computer Science,n◦ 126, p. 183-235, 1994a.

Rajeev Alur, Limor Fix, Thomas A. Henzinger, « Event-clock automata: A determinizable classof timed automata »,Proceedings of the Sixth Conference on Computer-Aided Verification,number 818 inLNCS, 1994b.

Rajeev Alur, P. Madhusudan, « Decision problems for timed automata: A survey »,4th Intl.School on Formal Methods for Computer, Communication, and Software Systems: RealTime, 2004.

Stavros Tripakis, « Folk Theorems on the Determinization and Minimization of Timed Au-tomata. »,FORMATS, Springer, p. 182-188, 2003.

a new model for web services timed business protocols · 2006-06-06 · a new model for timed...

Documents