Web Cube: a Programming Model for Reliable Web Applications

Transcription

1 Web Cube: a Programming Moel for Reliable Web Applications I.S.W.B. Prasetya, T.E.J. Vos, S.D. Swierstra, B. Wijaja institute of information an computing sciences, utrecht university technical report UU-CS

2 Web Cube: a Programming Moel for Reliable Web Applications I.S.W.B. Prasetya (UU), T.E.J. Vos (UPV), S.D. Swierstra (UU), B. Wijaja (UI) nov UU: Institute of Information an Computing Sciences, Utrecht University. P.O.Box , 3508 TB Utrecht, the Netherlans. UI: Fakultas Ilmu Komputer, Universitas Inonesia. Kampus UI Depok, Inonesia. Supporte by RUTI-2 Grant. UPV: Instituto Tecnológico e Informática, Universia Politécnica e Valencia. s: wishnu@cs.uu.nl, tanja@iti.upv.es, oaitse@cs.uu.nl, bela@cs.ui.ac.i Abstract Web Cube is a server sie programming moel for builing interactive web applications. Compare to typical server sie approaches use nowaays, Web Cube offers better abstraction mechanism an built-in safety. It imposes a more logical organization of its components. As a irect result of this applications become inherently secure an evelopment is less error prone. Web Cube is base on Seuss, a framework for moelling istribute systems. Seuss is rather light weight, but is abstract enough to allow convenient programming. It comes with a simple but powerful logic that allows safety an other temporal properties of a Web Cube application to be specifie an verifie. Contents 1 Introuction 2 2 Seuss 3 3 Execution Moel 5 4 Semantics Preliminaries Properties Box Component an Contract Inferring properties from compose systems Application Inferring an applications properties Verification 15 6 Relate Work 15 7 Conclusion 15 1

3 <% if (Auth.isAmin(user)) { %> <b> Welcome <% if (counter>0) { %> again <% }; %> <%= user.name %>! </b> <% } else { %> Hello stranger! <% } %> 1 Introuction Figure 1: A fragment of a Java Server Page (JSP). The Internet has change the way we eal with information. In particular, Web applications have affecte our aily life in many ways, since they are being use in information management/gathering, e-commerce, e-government, banking, e-learning, entertainment, etc. This pervasive an raical growth of Web applications, an the impact this has on society, makes correctness a primary concern. The most commonly use techniques to evelop sophisticate Web applications nowaays are technologies like PHP, ASP, an servlets. These technologies, however, are still prone to errors an security abuses. This is cause by: 1. The use programming metho itself. Many low level etails explicitly have to be programme by han. It is common to write an active page by stitching program fragments into HTML pages. Although some frameworks support a quite sophisticate stitching scheme, they o not clearly efine the relation between a page an the stitche coe fragments that are responsible for its ynamic behaviour. Not only oes this make things tricky for less experience programmers, it also makes reasoning about the behaviour of the complete application ifficult. Figure 1 shows a fragment of an hello-worl variant written in JSP. The coe is not pleasant to rea (let alone to ebug). There are three languages co-existing in the coe (HTML, Java, an JSP itself). Although this in itself is not ba, the languages here are interleave quite haphazarly. The full stitching scheme of JSP is even more complicate, which makes it ifficult to write a ecent syntax analysis tool. In fact, in JSP there is no syntax an type checking one at the JSP level; syntax errors may slip through unetecte until a user bumps in to them by accessing an erroneous page for the first time. 2. Any form of verification is har ue to the absence of a formal semantic moel of the use programming languages. Java shows that simply proviing such a semantics oes not necessarily lea to a practical solution. The full semantics of Java is very complicate an verification against it may not be feasible. The contribution of this paper is a programming moel, calle Web Cube, for constructing interactive component-base web applications. Web Cube offers a simple but well efine concept of a web application an how it can be constructe from its components. Web Cube strives to be abstract, such that programmers, to some egree, are relieve from laborious low level coe plumbing. In orer to enable the specification an verification of temporal properties of a web application, we have caste Web Cube with Misra s Seuss [8]. Seuss is a formal framework for moelling istribute systems that comes with a simple an abstract logic, which can help significantly in lowering the verification cost. Web Cube logic extens Seuss logic by being component-oriente. For this, Web Cube uses an extension taken from our previous work on component-base theories [12, 11, 9] that enable abstract reasoning over potentially large an complicate resources, such as 2

4 an enterprise atabase. The work reporte here is still on-going an there is no implementation yet. This paper is organize as follows. Section 2 introuces Seuss. Section 3 explains how a Web Cube application is constructe an the associate execution moel. Section 4 escribes the semantics of a Web Cube application an Section 5 explains how properties can be verifie. Section 6 iscusses relate work, an Section 7 conclues. 2 Seuss In Seuss a program is calle a box. Each box has a state; the state of a box is given by the values of the variables of that box. A box can have a set of actions, that may be guare. These actions are execute as in a Weakly Fair Transition System: an execution is an infinite sequence of steps; at each step an action is selecte for execution. The selection process is non-eterministic an such that each action is selecte eventually. Only when the selecte action s guar evaluates to true, the action is execute, else the effect is just a skip. All actions shoul be terminating, an are atomic. A box can also have methos. Methos can be calle from within another metho or from an action 1. A metho may have parameters, which are passe by value (thus avoiing aliasing issues). Web Cube will use a more restricte calling convention than Seuss [8]: (1) all methos are unguare (total) an thus can be calle from anywhere within an action or another metho; (2) a metho passes values back to its caller through a return value. These restrictions are just for brevity an are not essential. We will also allow a metho that has no sie effect to be eclare as a function. The boy of an action or a metho can be written in any language that supports Hoare logic. However, since the Seuss logic requires actions an methos to be terminating, it is the programmer responsibility to guarantee this. Generic boxes can be efine by categories calle cats, an several boxes can be create from each cat by instantiation. Note that in this way cats an boxes are analogous notions of, respectively, classes an objects in Java. Figure 2 shows an example of a category calle VoteServer. Via the metho vote a box of this category allows an environment to sen a vote. The box has two actions. The action move moves the content of the incoming votes buffer to an internal buffer h. The action valiate valiates the votes in h (e.g. using some cryptographic technique); it stores the vali votes an a them to the total count. Note by the way that: (1) move can be implemente as an O(1) operation, an (2) valiate oes not use the variable votes, an hence can be execute concurrently with calls to vote by the environment. The environment can also call the metho info to inquire whether the voting is still open an the number of votes counte so far. In Seuss all variables of a box are private. For convenience, however, we also allow public variables. In Web Cube, by efault a variable is public, unless it is specifie as private. A public variable of a box is reaable from surrouning boxes (see below), but changing the value of a variable can only be one via a metho. Inner Box. We will also allow a box to contain inner boxes (this feature is not explicitly present in the original Seuss). We will only consier inner boxes which can be create statically. In principle an inner box can be eclare to be private, though for brevity here we assume all inner boxes to be public. Public variables an methos of an inner box are accessible from the environment of its parent box using a qualifie notation as in Java. A box P that contains inner boxes can be transforme to an equivalent flat box, enote by P, which is a box without inner boxes. Essentially this is one by applying some renaming scheme on P s inner boxes so that each has a unique name space. 1 Note that since actions are atomic, calling a long series of methos from an action may lock some variables for quite a long time. The programmer shoul take this into account. 3

5 cat VoteServer { VoteList votes = [] ; VoteList valivotes = [] ; bool open = True ; private int count = 0 ; private VoteList h = [] ; metho vote(v:vote) { if open then insert(v,votes) else skip } ; function (Int,Bool) info() { return(count,open) } ; metho stop() { open := False } ; partial action move null h /\ ~null votes -> h,votes := votes,[] ; } partial action valiate ~null h -> { Vote v ; while ~null h o { v := h.gethea() ; if v.isvali() then { insert(v,valivotes); count:=count+1 } else skip } } Figure 2: An example of a category. 4

6 Specification. Seuss logic has operators as unless an (leas-to) to express temporal properties. The logic is efine in terms of flat boxes the logic is mostly the same as its preecessor UNITY [3]. For example, if x is a box, x p unless q means that all actions a in x satisfy: {p q} a {p q}. Hence, if x enters a state satisfying p, it will remain in p or go over to q (later we will nee to alter this efinition to eal with components). We also allow methos to be use in a preicate which in turn can be use in a specification. If p is a preicate an m(e) is a call to a metho m, p; m(e) is a preicate specifying the set of states obtaine after m(e) is calle on states satisfying p. It is formally efine as follows (in terms of Hoare triple): p; m(e) = ( q :: {p} m(e) {q}) (1) For example, if insert is a metho of a box P, then P V >0; insert(v, s) V s states that after a call to insert(v, s) with a positive value V, eventually this value will be in s. Functions of a box can also be use in a specification. For example, if f is a function, then the expression let x = f(e) in x > 0 is a preicate specifying the set of states for which f(e) returns a positive value. 3 Execution Moel A Web Cube application, or simply application, is built by composing cubes an resources. Both are Seuss boxes, i.e. programs having their own states. A cube is a server sie program that interacts with a client. The client oes so by calling the cube s methos. The interaction goes via an HTTP connection. So, a user can use a web browser to sen HTTP requests to a cube, which woul be translate to metho calls. Calls from a client are hanle atomically an may alter the cube s state. The metho may also sen back HTML responses, which the user can view in his browser. We will call a metho that prouces HTML a writer metho. The role of a cube insie an application is purely for serving client s requests. It means that as a Seuss box it oes not have any actions (it only has methos). A resource on the other han, may have actions. Resources will be explaine in more etail below. The life time of a cube is one session. So, compare to typical CGI scripts, the state of a cube is more persistent. Also, access to cubes is strongly guare to provie some built-in security. We will return to this issue later. Below is a simple example of a hello-worl application. The application is mae of of a single cube calle home. application helloworl { cube home { n : Int = 0 ; } } writer metho home() { respon("hello worl! <@ ; n := n+1 } Each application, like the one above, shoul have a cube calle home that contains a metho home. The metho is always calle automatically when an instance of the application is create (upon a user s request) an so resembles the home-page of the application. In the above case, 5

7 calling home will cause the user to see the string hello worl on his browser, followe by whatever the value of n is at that moment. The variable n is increase each time the client calls the metho home (for example if the user hits the reloa button). Between the symbols <@ we can embe a Seuss expressions to be inline insie a response string. We will explain this in more etail later, but compare to for example JSP, Web Cube has a much simpler inlining scheme. The Corrior To make Web Cube work, we nee an interface program since a stanar web server woul not know how to hanle Web Cube specific HTTP requests. We will call the interface the Corrior, which is place between HTTP ports an the cubes. One of the tasks of the Corrior is to recognize cube-specific HTTP requests coming at the ports, an to reirect them to the right cube. Another important task of the Corrior is to automate user authentication, because this is too critical to be programme by han. When a user requests the creation of an instance of an application A, he shoul first authenticate himself. The Corrior takes over the task of authenticating the user, which inclues verifying that the user has sufficient access right to all resources require by the requeste application. Web Cube also allows so-calle clearance level to be specifie. In this paper we just consier two levels: Amin an orinary. Some methos of the cubes can be specifie to be accessible only to the user with an Amin clearance. It is also the task of the Corrior to verify the user s clearance. Once a user passes the authentication phase a new instance A of A will be eploye for him. A unique application instance ID or aini an will be generate to uniquely ientify communications between the user s client an A. Packages exchange uring authentication, an subsequent communication between a client an an application instance shoul be properly encrypte. Since this can be aequately an transparently taken care of by for example SSL, we will abstract away from encryption in our programming moel. To call a metho, the Corrior requires the client to also specify the metho s aress. The aress of a metho is a unique URI string that will allow the Corrior to uniquely ientify the metho within the set of application instances that it has access to. It will typically inclue the metho s name an its aini. How an aress is constructe is not essential here. Cube Integrity In aition to the safe access guaring provie by the Corrior, Web Cube also has a number of other safety measures. We have sai that a client interacts with a Web Cube application by calling its methos. Each metho call (but not a series of them) will be hanle atomically. Furthermore, HTML responses are generate without further sie effect. As a consequence, to analyze the safety of an application it is sufficient to consier its methos, with all respon commans stripe out. With the exception of resources, applications an application instances o not share any ata, an thus interference between ifferent parts of an application (which is the typical source of errors in istribute systems) can be containe. Web Cube oes not encourage coe stitching like in PHP or JSP because this is too error prone. However, for convenience some stitching is still allowe through the notation to o response inlining (we have seen it in the previous example). This inlining scheme is safe as long as it is sie effect free. Resources In Web Cube a resource represents a evice, such as an enterprise atabase, which is typically share across application instances or even across applications. The life time of a resource can be thought to be permanent. Essentially, a resource is just a reactive program that has its own state an may provie methos. It may also perform some computation in the backgroun that 6

8 application webvote { resource :MyVoteDB ; cube home { writer metho home() { respon( "<form metho=post action=<@aress..vote@>> Enter your vote: <input type=text name=v> <input type="submit" value="submit"> </form> <p><a href=<@aress..info@>>click here to get vote info</a> <p><a href=<@aress.logout@>>logout</a> <p><a href=<@aress..close@>>close the vote (Amin only)</a> ") } } } writer metho info() { n:int ; b:bool ; (n,b) := status() ; respon("<p>total votes = <@n@>") ; if b then respon("<p>voting is still open.") else respon("<p>voting is close.") } Figure 3: A simple Web Cube application for electronic voting. regularly upates its state. Because a resource such as a atabase is a large an complicate system, most likely it will not be written in Seuss. Consequently, we will represent resources as black box programs, that in [14] are also calle components. All resources shoul have implicit connect methos. When a user request an instance of A to be create, the Corrior will use these methos to try to connect to all resources require by A. For this to be successful, the user must have access right to all resources neee by A. Only when all connects are successful an application instance will be create. Figure 3 shows a simple application to o electronic voting. It uses a single resource, that represents a back-en atabase where the votes are store. The resource supports three methos (not shown in the Figure): vote that is use to enter a new vote, info that is use to query the status of the voting, an close that is use to close the voting. The last is only accessible to users with an Amin clearance. The first time an instance of webvote is create, the Corrior will connect to the atabase resource an the metho home will be calle. The HTML coe generate by respon will be sent to the user s browser an he will see a simple form where he can type in his vote, a submit button, a link to get the voting status, an few other things. Disengaging an Application Each application always has a pre-generate logout metho use to isengage the corresponing application instance. It will also isconnect the application instance from its associate resources. The metho can be calle by the user, or by the Corrior which can ecie to o so for some security 7

9 reason. When an application instance is isengage it will be isengage entirely. Disengage cubes can be garbage collecte, but since this may not happen immeiately, the Corrior must make sure that no HTTP request can reach isengage cubes. HTML Responses HTML responses are generate by the respon metho. It expects a string, which will just be sent as is to the client. Seuss expressions can be inserte within the string argument of respon by putting them between <@ as in: respon{"hello <@name@>!"} As respon encounters an embee expression <@e@>, it will evaluate e an put the result in the place where e stans. This is calle response inlining. In aition to orinary Seuss expression, we also allow the following special form. Let m be a metho name. An expression of the form aress.m will be substitute by m s URI aress. For example: respon("<a href=<@aress.home@>>back home</a>") will cause a href-e string back home to be isplaye in the user s browser. Clicking on the link will cause the metho home to be calle (with no parameter). Any expression can be inline as long as it oes not have sie effects (forbien; see Cube Integrity). Nesting respon calls via inlining is therefore not allowe (which is also a ba style). It also implies that the orer in which inline expressions within the same respon are evaluate is inconsequential. If it is convenient, an implementation may also allow an inclue metho for reaing static HTML content of a file an sening it to the client. Potentially, someone can still write coe like this: respon{"<b"}; x:=x+1; respon{"> hello </b>"} which can be avoie by writing it like this: x:=x+1; respon{"<b> hello </b>"} Mangling can be prevente at the parser level. This oes require aitional work in writing the parser, but it is not much because of the simple inlining scheme aopte here. Specifying Safety Since cubes an applications are, in principle, just Seuss boxes, their properties can be expresse formally using the Seuss specification language. For example, the following property can be require for the webvote application (Figure 3): let (n, ) =.info() in n N unless false (2) If info returns a pair, whose first element tells us how many vali votes have been counte so far, the above property essentially implies that the application will not silently cancel an alreay counte vote. The Seuss logic can be use to verify a specification such as the one above. However first we nee to efine the semantics of cubes in terms of boxes. This is explaine in the next section. 4 Semantics Now that we have etaile the execution moel of Web Cube applications, we can now look at their semantics an see how we can specify an verify properties about them. In the sequel a, b, c are actions, i an j are preicates intene to be invariants, p, q, r are preicates, P, Q, R are action systems (explaine later), x, y, z are boxes. Since a box can be transforme to a semantically equivalent flat box, we will only consier the latter sort. 8

10 4.1 Preliminaries Preicate Confinement. Preicates specify a set of program states. A preicate p is confine by a set of variables V (written p conf V ) if p oes not constrain the value of any variable outsie V. As a rule of thumb, an expression e is confine by its own set of free variables. We write p, q conf V to abbreviate p conf V an q conf V. Actions. An action is an atomic, terminating, an non-eterministic state transition. An action can be moelle by a function from the universe of states, enote by State, to P(State). Actions can be (multiple) assignments or guare actions. If V is a set of variables, skip V is an action that oes not change the variables in V. Guare actions are enote by g --> a, meaning that a will be execute if g is true, otherwise the action behaves as a skip. If a an b are actions, a b is an action that either behaves as a or as b. So, (a b) s = a s b s. If Σ is a set of actions then Σ is a shorthan for ( a : a Σ : a). Notation. We will use tuples to represent composite structures, an selectors to select the various parts. For example, Box = (main :: ActionSys, meths :: {Metho}) efines a type Box consisting of two-elements tuples. If (P, M) is a value of this type, then x.main = P an x.meths = M. Action System. The action system part of a Seuss (flat) box is the set of actions of the box. It is the part of the box that autonomously an constantly upates the box state. Formally we represent an action system by the following structure: ActionSys = (acts :: {Action}, init :: P re, pub :: {V ar}, pri :: {V ar}) (3) P.init is a preicate specifying P s possible initial states, P.pub is the set of P s public (share) variables, an P.pri is the set of P s private (local) variables. We write P.var to refer to P.pub P.pri. Implicitly, P.init has to be confine by P.var; P.pub an P.pri are isjoint; an for every action a P.acts, it hols that for every state s, a s is non-empty. An action system is the same as what in [3] is calle a UNITY program. Composing two action systems means running them in parallel. The behaviour of the parallel composition of P an Q is moelle by the P []Q which is efine as follows: P []Q = (P.acts Q.acts, P.init Q.init, P.pub Q.pub, P.pri Q.pri) (4) In the above efinition, we assume that the private variables of P an Q have been rename so that their names will not clash after the composition. Invariant. A preicate i is a strong invariant of an action system P, enote by P sinv i, if it hols initially, an it is maintaine by every action of P. P sinv i = P.init i ( a : a P.acts : {i} a {i}) (5) A preicate j is an invariant if there exists a strong invariant i implying j. Refinement. We efine the following notion of refinement over actions it is a variant of the stanar one, e.g. as in [2]. Let V be a set of variables, an let i be a preicate (i is intene to be an invariant). Action b weakly refines action a (or a is an abstraction of b) with respect to V an i, if b can either simulate whatever a can o on the variables in V, assuming i hols initially, or it skips. Formally: V, i a b = ( p, q : p, q conf V : {i p} a skip V {q} {i p} b {q}) (6) We will use the following simple notion of refinement for action systems: 9

11 Definition 4.1 : Refinement/Abstraction i P Q = P.pub Q.pub P.pri Q.pri Q.init P.init b : b Q.acts : P.var, i P.acts b So, uner the invariance of i, i P Q means that every action of Q either oes not touch the variables of P, or if it oes it will not behave worse than some action of P. When i P Q, we call Q a refinement of P, or equivalently, say that P is an abstraction of Q. This refinement relation is a weak one. For example, unlike [15] it oes not preserve progress. However, it is still useful. It still preserves safety [11], an as we will see later, it can be mae to preserve progress. Moreover, to compensate for its weak expressiveness, it is relatively easier to verify. 4.2 Properties Properties of a box can be expresse in terms of the properties of its action system. This section iscusses how these properties can be specifie an what the semantics of these specifications are. Recall that an application can refer to resources that we represent as black box components. When composing an application with such a component, we shoul take into account that the components complete coe may not be known. The stanar Seuss operators unless an ensures for specifying one-step temporal progress properties are not expressive enough for reasoning uner these circumstances. Below we introuce our efinitions of these operators that, as we have proven in [11], are sufficient to to eal with black box components. Definition 4.2 : Basic Operators 1. P, i p unless q = P sinv i p, q conf P.var ( a : a P.acts : {i p q} a {p q}) 2. P, i p ensures q = P, i p unless q ( a : a P.acts : {i p q} a {q}) The general progress operator is efine as the least transitive an isjunctive closure on the relation (λ p q. P, i p ensures q). Progress efine in this way is still ifficult to preserve when subjecte to parallel composition. Essentially, this is because we o not put any constraint on the environment. Obviously no non-trivial progress property can withstan an environment that can o anything. Consier an action system P that is compose with an environment B. Consier the progress p q in the composition P []B. Suppose we know that this progress is riven solely by P. Now, if B is an abstraction of a concrete environment Q, then we can expect that the same property will be preserve in P []Q. To express this kin of reasoning, we introuce a new set of extene operators, with which the notion of progress is riven solely by P can be specifie. Definition 4.3 : Extene Progress Operators Let P an B be action systems. We efine: 1. P []B, i p ensures q = P []B, i p unless q ( a : a P.acts : {i p q} a {q}) 2. P []Q, i p q is efine such that (λp, q. P []Q, i p q) is the smallest transitive an isjunctive closure of (λp, q. P []Q, i p ensures q). Now we can introuce the following important theorem whose proof can be foun in [11]. It states that every progress property from p q mae by P, when specifie in terms of P []B, will be preserve when P is compose with any program Q that refines B. 10

12 Theorem 4.4 : Preservation of P []B, i p q j B Q i j P []Q, i p q Notice that the rule s premise assumes that i is a strong invariant of P. However, if P is the action system of a black box, its contract may not reveal what i is, for example because it woul expose too much internal state of the box. Fortunately, the theorem says that it is sufficient if the contract exposes a weaker invariant j, since we can infer the conclusion above by showing the refinement B Q base on the weaker j. Notice also that the theorem above implies that the simplistic notion of refinement that we have chosen, while it oes not preserve progress in general, it oes preserve progress in terms of P []B. 4.3 Box A (flat) box can be represente by an action system plus a set of methos. For brevity we will only consier public methos: Box = (main :: ActionSys, meths :: {Metho}) We will also overloa the selectors use on action systems so that they also work on boxes, e.g. if x is a box, x.pub is equal to x.main.pub. We also overloa [] an [], e.g., x[]q means x.main[]q. The (public) methos of a box x can be calle by a surrouning box y. An action in y can even call multiple methos of x. The Seuss Virtual Machine (SVM) on which x runs is responsible for scheuling the actions in such a way that each is execute atomically. We may want to expose a box x so that its methos can be calle by an external program y, also calle an external environment, which may be a non-seuss program running on a ifferent machine. In particular, y may be beyon the control of x s SVM. We will therefore assume weaker synchronization with such a y. Each metho call from y to x is guarantee to be execute atomically. Atomicity over a series of calls is not guarantee. The worst possible external environment of x can be characterize by the following action system: x.env = (Σ, x.init, x.pub, ø) where Σ is a set of actions moelling all possible calls to the methos in x.meths. We will leave out the formal efinition of Σ. See for example [12]. By efinition, any real or proper external environment Q of x is a refinement of x.env. Formally: Q is a proper external environment of x = ( i :: x.pub, i x.env Q) Any unless an properties proven with respect to x[]x.env an x []x.env respectively, will be preserve when x is compose with any proper external environment. 4.4 Component an Contract Recall that a web application may have access to resources, which are assume to be available as black box components. Rather than revealing full information about itself, a component only reveals partial information in the form of a contract. A contract is bining: a component is oblige to realize anything it commits in its contract. Obviously the more information a contract contains, the more properties we can infer from it. On the other han, more information makes verification harer an the component itself less reusable. When writing a contract a eveloper will have to consier a reasonable balance. A contract is essentially an abstraction of the component it bins. We alreay have a simple refinement relation (Definition 4.1) that preserves safety an a useful class of progress properties. 11

13 Moreover, our refinement relation gives consierable freeom in eciing how much of a box s action system we want to hie. So we are going to use this relation to be the base of componentcontract relation. We will represent the actual programs behin components with boxes. This oes not mean that components have to be written in Seuss. It is sufficient if they can be moelle in Seuss. contract MyVoteDB { VoteList votes = [] ; VoteList valivotes = [] ; bool open = True ; } metho vote(v:vote) { if open then insert(v,votes) else skip } ; function (Int,Bool) info() { return(valivotes.length(),open) } ; amin metho stop() { open := False } ; smoel partial action fetch ~null votes -> votes := [] ; action count { VoteList vs = ANY ; if vs.allisvali then valivotes.appen(vs) else skip } inv!v: v in valivotes : isvali(v) progress isvali(v) /\ (N,True)=info(); vote(v) --> let (N,-)=info() in N =N+1 Figure 4: Above is an example of a contract. For example any box of category VoteServer (Figure 2) can be shown to meet the above contract. Figure 4 shows an example of the type of contracts we use here. If c is a contract, we will say that a box is boun by c when the box correctly implements c. For a contract c, c.impl enotes any box (component) boun by c. We will represent a contract c with a tuple of the following type: Contract = (smoel :: Box, inv :: P re, progress :: {P rogressspec}) where c.smoel (safety moel of c) is a box that is an abstraction of c.impl; c.inv is a preicate specifying an invariant, an c.progress is a set of specifications in form p q specifying progress mae by c.impl. We will overloa the meaning of the selectors use on boxes so that they also work on contracts. For example, if c is a contract, c.pub enotes the set of all c s public variables, which is just equal to c.smoel.pub. Another important point is that a component is a continuously running program which is well encapsulate, in such a way that programs interacting with it are treate as external environments (in the sense as in the previous subsection). The nice thing about this is that we can preict the behavior of a component s environment: it is just c.env = c.smoel.env, if c is the component s contract. We impose that c.smoel has no private variables (so c.smoel.pri = ø). Moreover, c.inv specifies a strong invariant of c.smoel, an of any proper (external) environment of c.smoel. Furthermore, 12

14 c.inv has to be confine by c.pub. Formally: c.smoel[]c.env sinv c.inv c.inv conf c.pub Below, we efine the relation between a contract an the box that is boun by it: Definition 4.5 : Box-Contract Relation Let c be a contract an x = c.impl. The relation between x an c is as follows: 1. x an c.smoel have the same interface. That is, x.pub = c.pub an x.meths = c.meths. 2. There exists a preicate i such that: (a) i is a strong invariant of x[]x.env an it implies c.inv. (b) c.smoel is a consistent abstraction of x. More precisely: i c.smoel x (c) For every specification p q in c.progress: x []x.env, i p q The invariant i mentione above is calle the concrete invariant of x, an will be enote by x.concreteinv. Note that since x an c have the same set of operations, then x.env = c.env. So, any proper (external) environment of c.smoel is also a proper environment of x. Also note that c.inv is an invariant of x[]x.env because the box-contract relation implies the existence of a invariant i of x[]x.env implying c.inv. However, c.inv is not a strong invariant of x[]x.env. 4.5 Inferring properties from compose systems This section shows two important theorems that allow us to infer the properties of a compose system from the properties of its components. The proofs are omitte an can be foun in [11]. From the box-contract relation an from Theorem 4.4, it follows that the composition of a component x with any proper environment Q will maintain all progress properties specifie in R: Theorem 4.6 : Progress Commitment Let c be a contract an x = c.impl. Let Q be a proper environment of x. p q c.progress x []Q, x.concreteinv p q Any unless property proven with respect to the safety moel in the contract is also a property of the actual box: Theorem 4.7 : Safety Commitment Let c be a contract an x = c.impl. Let Q be a proper environment of x. c.smoel[]c.env, c.inv p unless q x[]q, x.concreteinv p unless q 4.6 Application Strictly speaking, an application is ifferent from its instance. Like a class in Java, an application has to be instantiate first to create a running program. For the semantics escribe here, such a etail is not essential; so, for convenience we will just use both terms interchangeably here. We will also abstract away from clearance level. Clearance level is a static aspect. In the Web Cube setup, resources actually live in a special name space which is globally available to all cubes. In effect, we can actually pull them out from a web cube application, an treat them as root level entities. After pulling out the resources, an application is basically just a cube, which in turns is just a Seuss box. 13

15 Web applications are compose of cubes an resources. As inicate the resources are represente by contracts. Cubes are just boxes with no actions. The entire cube structure of an application can be equivalently represente by single flat box, which in turn can be represente by a contract of which the smoel.main.acts, inv, an progress sections will remain empty. Aitionally, we change the cube s private variables to public (because a contract, as is now, cannot have private variables). So, we will represent a Web application by a set of contracts: App = {Contract} The concrete program inuce by an application A is just the parallel composition of all its components (which are Seuss boxes): A.impl = ([]c : c A : c.impl) The worst environment of a Web application can be moelle by a client that tries all possible calls to the public methos: Definition 4.8 : Application s Abstract Environment A.env = ([]c : c A : c.env) The abstract moel of the whole application, enote by A.smoel, is the composition of the safety moels expose by the contracts of its components an the client: Definition 4.9 : Abstract Moel of Application A.smoel = ([]c : c A : c.smoel) [] A.env The notation A.inv refers to the conjunction of the invariants specifie by the contracts in A. Similarly, we efine A.concreteInv: Definition 4.10 : Application s Invariants A.inv A.concreteInv = ( x : x A : x.contract.inv) = ( x : x A : x.concreteinv) 4.7 Inferring an applications properties The theorems from Subsection 4.5 can now be lifte to the application level to infer the properties of an application from the contracts of its components. The theorems are aapte from [12], for the proofs the reaer is referre to [11]. The first theorem says that a safety property proven with respect to the abstract moel of an application will exten to the concrete application itself, uner any behaviour of the client. Theorem 4.11 : Safety by Abstract Moel A.smoel, A.inv p unless q A.impl[]A.env, A.concreteInv p unless q Any progress property committe in the contract of any component (in particular, by a resource) in an application will be preserve by the application an the client: Theorem 4.12 : Progress by Contract Let c be a contract in A. p q c.progress A.impl []A.env, A.concreteInv p q 14

16 5 Verification To prove safety an progress properties we use Seuss logic [8], which is not shown here. Although we have change the efinitions of Seuss temporal operators, it will be easy to verify that they maintain all basic Seuss laws using our our general proof theory in [10]. The theorems mentione in sections 4.5 an 4.7 are important aitions to the Seuss logic since they enable componentoriente reasoning on web cube applications. For example, recall property (2) of the webvote application from Figure 3: let (n, ) =.info() in n N unless false (7) It is an important safety property, since it states that the application will not silently cancel an alreay counte vote. In orer to verify its correctness, Theorem 4.11 inicates that it is sufficient to o so against the abstract moel of the application. This significantly reuces the effort of verification. The amount of information reveale by a contract etermines which properties can be verifie. For example, the contract MyVoteDB as in Figure 4 implies, by Theorem 4.12, that a vali vote submitte while open is true will eventually be counte. However, we cannot verify that no fake votes will be inserte into the atabase since the resource oes not commit to this in its contract. 6 Relate Work In this section we escribe some of the work relate to ours. In [13] a petrinet-base framework is propose to evelop web applications. The approach is refinement base an can prouce a final moel which can be implemente in Java. [5] proposes a small language cl to specify a conversation between two web applications. States cannot be specifie in cl. Its purpose is specifically to specify conversation protocols. Our approach is complementary to the two approaches escribe above. Like [13] we also use refinement, but its role is to bin contracts. We o not use refinement in the evelopment. In our framework, the cubes are immeiately executable; the evelopment time is thus shorter, but post-verification is neee. The work in [13, 5] is more suitable to treat tightly synchronize istribute applications which are somehow eploye over HTTP connections. In the case of [13] applets are use, an [5] eals with coorination between multiple applications. In contrast, our framework tens more towars a client/server scheme. [6] uses communicating finite automata to moel web applications. Temporal properties can be specifie an verifie using stanar temporal logics. It is however a verification approach, not a evelopment approach. Moels are incrementally an automatically constructe from intercepte HTTP packages an then subsequently subjecte to verification against some pre-specifie properties. There oes also exist work seeking to apply formal methos on other aspects of web applications. We only mention some of them: [7] offers a formal moel for web queries; [4] offers a client-sie logic programming moel for web pages; [1] escribes a rewriting base framework for the automate verification of Web sites which can be use to specify integrity conitions for a given Web site, an then automatically check whether these conitions are fulfille. The Semantics Web is an approach that nowaays raws a lot of attention. It proposes stanars to specify relations between ifferent fractions of a ocument so that they can be subjecte to analysis or transformation by tools. 7 Conclusion We have escribe an alternative programming moel to construct interactive web applications. It is a moest moel, in particular if compare to popular approaches such as servlets an ASP. But in return it offers better security an a logic to specify an verify critical temporal properties of an application. The logic is simple. It allows abstract reasoning over potentially complicate 15

17 resources. It also allows the presentation aspect (the HTML parts) to be ignore uring the verification. The logic is not well suite to reason about the presentation part. For such a purpose, it shoul be complemente with approaches such as Semantic Web. The Web Cube project is still on-going. There is no implementation yet, so we cannot at the moment say much about practical experience. References [1] M. Alpuente, D. Ballis, an M. Falaschi. A rewriting-base framework for web sites verification. In 5th Int l Workshop on Rule-base Programming RULE. Elsevier Science, [2] R.J.R. Back an J. Von Wright. Refinement calculus, part I: Sequential non-eterministic programs. Lecture Notes of Computer Science, 430:42 66, [3] K.M. Chany an J. Misra. Parallel Program Design A Founation. Aison-Wesley Publishing Company, Inc., [4] A. Davison an S. Loke. Logicweb: Enhancing the web with logic programming, available at [5] Sven Frolun an Kannan Govinarajan. cl: A language for formally efining web services interactions. Technical Report HPL , Hewlett Packar Laboratories, October [6] May Hayar. Formal framework for automate analysis an verification of web-base applications. In 19th IEEE International Conference on Automate Software Engineering (ASE), pages IEEE Computer Society, [7] Alberto O. Menelzon an Tova Milo. Formal moels of Web queries. In ACM, eitor, PODS 97. Proceeings of the Sixteenth ACM SIG-SIGMOD-SIGART Symposium on Principles of Database Systems, May 12 14, 1997, Tucson, Arizona, pages , New York, NY 10036, USA, ACM Press. [8] J. Misra. A Discipline of Multiprogramming. Springer-Verlag, [9] I.S.W.B. Prasetya, S.D. Swierstra, an B. Wijaja. Component-wise formal approach to esign istribute systems. Technical Report UU-CS , Inst. of Information an Comp. Science, Utrecht Univ., Downloa: [10] I.S.W.B Prasetya, T.E.J. Vos, A. Azurat, an S.D. Swierstra.!UNITY: A HOL theory of general UNITY. In D. Basin an B. Wolff, eitors, Emerging Trens Proceeings of 16th International Conference, Theorem Proving in Higher Orer Logics (TPHOL), pages , Also available as tech. report No. 187 of Inst. fur Inf., Albert-Luwig-Univ. Freiburg. Available on-line at [11] I.S.W.B Prasetya, T.E.J. Vos, A. Azurat, an S.D. Swierstra. A unity-base framework towars component base systems. Technical Report UU-CS , Inst. of Information an Comp. Science, Utrecht Univ., Downloa: [12] I.S.W.B Prasetya, T.E.J. Vos, A. Azurat, an S.D. Swierstra. A unity-base framework towars component base systems. Proceeing of OPODIS 2004: 8th International Conference on Principles of Distribute Systems, to appear in LNCS. [13] Giovanna Di Marzo Serugeno an Nicolas Guelfi. Formal evelopment of java base web parallel applications. In Proceeings of the Hawai International Conference on System Sciences, 1998, Also available as Technical Report EPFL-DI No 97/248. [14] C. Szyperski. Component Software, Beyon Object-Oriente Programming. Aison-Wesley, [15] T.E.J. Vos, S.D. Swierstra, an I.S.W.B Prasetya. Yet another program refinement relation. In International Workshop on Refinement of Critical Systems: Methos, Tools an Experience,