Tisa: A Language Design and Modular Verification Technique for Temporal Policies in Web Services

Abstract

Abstract. Web services are distributed software components, that are decoupled from each other using interfaces with specified functional behaviors. However, such behavioral specifications are insufficient to demonstrate compliance with certain temporal non-functional policies. An example is demonstrating that a patient's health-related query sent to a health care service is answered only by a doctor (and not by a secretary). Demonstrating compliance with such policies is important for satisfying governmental privacy regulations. It is often necessary to expose the internals of the web service implementation for demonstrating such compliance, which may compromise modularity. In this work, we provide a language design that enables such demonstrations, while hiding majority of the service's source code. The key idea is to use greybox specifications to allow service providers to selectively hide and expose parts of their implementation. The overall problem of showing compliance is then reduced to two subproblems: whether the desired properties are satisfied by the service's greybox specification, and whether this greybox specification is satisfied by the service's implementation. We specify policies using LTL and solve the first problem by model checking. We solve the second problem by refinement techniques.

Formal Methods for Data-centric Web Services: From Model to Implementation

“…We model histicated global variable, it is modified between a do not attempt to specify focus on correctness and cts after a service call. posed in [13] employs a ormal methods techniques es. Policies include nony rules that should be mentation.…”

Formal Methods for the Specification and Testing of Data‐centric Web Services: A Case Study

“…The Tisa language recently proposed in (Rajan et al 2009) employs a similar methodology by applying formal methods techniques to specify temporal service policies. Policies include non-functional regulations and privacy rules that should be maintained by a service implementation.…”

Translucid contracts

“…If a method runs when an event of type p is announced, then its implementation must refine the contract se of the event type p. For example, in Figure 2 the method update on lines 21-26 must refine the contract of the event type Changed on lines 12-17. There are four new expression forms that only appear in contracts: specification expressions, next expressions, abstract invoke expressions, and choice expressions. A specification expression (spec) hides implementation details (i.e., algorithms) and thus abstracts from a piece of code in a conforming implementation [22,24]. The most general form of specification expression is requires sp1 ensures sp2, where sp1 is a precondition expression and sp2 is a postcondition.…”

“…The most general form of specification expression is requires sp1 ensures sp2, where sp1 is a precondition expression and sp2 is a postcondition. Such a specification expression hides program details by specifying that a correct implementation contains a refining expression whose body expression, when started in a state that satisfies sp1, will terminate in a state that satisfies sp2 [22,24]. In examples we use the following syntactic sugars: preserves sp for requires sp ensures sp, and establishes sp for requires 1 ensures sp [22].…”

“…Among others, Barnett and Schulte have used grey box specifications written in AsmL [5] for verifying contracts for .NET, Wasserman and Blum [29] also use a restricted form of grey box specifications for verification, Tyler and Soundarajan [28] and most recently Shaner et al [24] have used grey box specifications for verification of methods that make mandatory calls to other dynamically-dispatched methods. Rajan et al have used grey box specification to enable expressive assertions about web-services [22]. Compared to these ideas, our work is the first to consider grey box specification as a mechanism to enable modular reasoning about code that announces events and handles events, which is a common idiom of AO and II languages.…”