Gregorio D´ıaz1 and Luis Llana2
1 Computer Science Dept. University of Castilla-La Mancha 2 Computer Science Dept. Complutensis University of Madrid
[email protected], [email protected]
Abstract. Design and implementation via contractual specifications helps designers and programmers understand and analyze when the re- quirements have been elicited according to the client’ desires. In general, software is released when some tests have been successfully passed. How- ever, these tests only cover a finite set of possible executions. But in sys- tems such as web services, which involve a set of heterogeneous parties, it is difficult to identify an appropriate set of tests because their execution tends to be nondeterministic since most rely on underlying software sys- tems where most of the information is hidden due to copyright or security concerns. In this work, we propose that the use of contract specifications, such us C-O Diagrams, allow one to specify and codify a system, where once the software has been released it is still possible to check if the execution conforms to a given contract. To achieve this goal, we pur- pose a monitoring technique, where all actions specified in a contract are recorded in a log that will be used by the monitor software to check if the contract is being fulfilled and alerting all parties when it is not so that the system can force reparations.
1
Introduction
Acontract from a software perspective refers to a set of statements agreed be-
tween the involved parties. These statements have different detail level depend- ing on the case. One of the first approaches to use contracts in software designs dates to the mid-eights, with the Eiffel language, where the contract refers to a set of pre and post conditions and invariants following the ideas defined by Hoare. These ideas have proven effective for the development of Object Ori- ented designs. However in more recent paradigms such as component-based and interaction-based developments, the abstraction level has changed and therefore new definition of contracts need to be introduced.
In the context of SOA, there are different service contract specification lan- guages, such as ebXML, WSLA, and WS-Agreement. These standards and spec- ification languages suffer from one or more of the following problems: They are restricted to bilateral contracts, lack formal semantics (so it is difficult to rea- son about them), their treatment of functional behaviour is rather limited and the sub-languages used to specify security constraints, for instance, are usually
K.-K. Lau, W. Lamersdorf, and E. Pimentel (Eds.): ESOCC 2013, LNCS 8135, pp. 119–133, 2013. c
limited to small application-specific domains. The lack of suitable languages for contracts in the context of SOA is a clear conclusion of the survey [15] where a taxonomy is presented.
In [12] C-O Diagramswere introduced, a graphical representation not only for electronic contracts but also for the specification of any kind of normative text (Web service composition behaviour, software product lines engineering, requirements engineering, . . . ).C-O Diagrams allow the representation of com- plex clauses describing the obligations, permissions, and prohibitions of different signatories (as defined in deontic logic [14]), as well as reparations describing contractual clauses in the case of non-fulfillment of obligations and prohibitions. Also,C-O Diagrams permit defining real-time constraints. In [11] some of the satisfaction rules needed to check if a timed automaton satisfies a C-O Dia- gram specification were defined. In [13], C-O Diagrams were equipped with a formal semantics, based on a transformation of these diagrams into a network of timed automata (NTA). Finally, some conformance relationships are given in [4], where contract and implementation, are compared.The contribution of this work pursues the further development of our previous work. Here, we focus on the development of a software system implementing the conformance relationships between contracts and implementations to check if implementation executions corresponds to its contracts. The software developed in this case is a monitoring system and is based in a subscription and notification system where the different involved services subscribe to a specific contract under a specific role and are notified in case a service violates the contract.
2
Related Work
The use of deontic logic for reasoning about contracts is wide spread in the literature and was proposed in [5] for modelling communication processes. In [10] Marjanovic and Milosevic present their initial ideas for formal modelling of e-contracts based on deontic constraints and verification of deontic consis- tency, including temporal constraints. In [6] Governatori et al. go a step further, providing a mechanism to check whether business processes are compliant with business contracts. They introduce the logic FCL to reason about the contracts, based again on deontic logic. In [9] Lomuscio et al. provides another methodol- ogy to check whether service compositions are compliant with e-contracts, using WS-BPEL to specify both, all possible behaviours of each service and the con- tractually correct behaviours, and translating these specifications into automata supported by the MCMAS model checker to verify the behaviours automatically. None of the previous works provide a visual model for the definition of con- tracts. However, there are several works that define a meta-model for the spec- ification of e-contracts, with the purpose of their enactment or enforcement. In [3] Chiu et al. present a meta-model for e-contract templates written in UML, where a template consists of a set of contract clauses of three different types: obligations, permissions and prohibitions. These clauses are later mapped into ECA rules for contract enforcement purposes, but the templates do not include
any kind of reparation or recovery associated to the clauses. In [7] Krishna et al. purpose another meta-model, based on entity-relationship diagrams to generate workflows supporting e-contract enactment. This meta-model includes clauses, activities, parties and the possibility of specifying exceptional behaviour, but this approach is not based on deontic logic and says nothing about including real-time aspects natively.