The fast evolution of the Internet has popularized service-oriented architectures (SOA) with their promise of dynamic IT-supported interbusiness collaborations. Realizing this promise involves integrating services which are geographically distant and are offered by a variety of organizations which do not fully trust each other. Indeed, collaboration presumes a minimum level of mutual trust. Wherever trust is perceived as insufficient, business people turn to contracts as a mechanism to reduce risks. The ability to negotiate contracts (e.g. for quality of service, security, and distribution of information) and to provide services based on them is therefore one of the most pressing needs to make collaborations a reality. High-level models of contracts are slowly making their way into service-oriented architectures, but application developers are still left to their own devices when it comes to writing code that will comply with a contract concluded just before service provision. At the programming language level, contracts appear as separate concerns that crosscut through application logic. The aim of this project is to develop language based solutions to the above problem through the formalization of contracts as behavioral interfaces and the design of appropriate abstraction mechanisms that would guide the developer in the production of contract aware applications. In the project, we will concentrate on contracts dealing with performance (real-time) and information flow (confidentiality). The proposed programming language mechanisms will be formally described so that they are either correct by construction or their properties become amenable to formal proof.

Already several years ago, technology gurus predicted that the next big trend in software system development would be the service oriented architecture, SOA. A successful integration of loosely coupled services belonging to different, sometimes competing, but always collaborating organizations would storm the world. It would create a myriad of new business opportunities, enabling the formation of virtual organizations where SMEs would join forces to thrive in ever increasingly competitive global markets. While the dream lives on, and the industry pours resources into developing and deploying web services, the degree of integration achieved between different organizations remains low. Collaboration presumes a minimum level of mutual trust, and wherever trust is not considered sufficient, business-people turn to contracts as a mechanism to reduce risks. In other terms, for the SOA to deliver its promised advantages, developers need cost effective contract management solutions.

Researchers and industries alike have began addressing this very essential issue with a top down approach. Several electronic contract languages, their models and reasoning techniques are in the process of being discussed and refined. While this is a natural approach, we see the absolute need to provide the actual system developer with the means to implement their services to meet the requirements dictated by the contracts. At the moment the developer faces a situation where the programming languages originally used to produce intra-organization non-distributed applications are already stretched to cope with issues of distribution across organizational domains. When it comes to contracts, the abstraction mechanisms of current languages give almost no assistance to the developer.

In a service oriented architecture, applications are essentially distributed systems composed of services. A service is a loosely coupled, technology neutral and self describing computation element. Loose coupling is achieved through encapsulation and communication through message passing; technology neutrality results from adopting standardized mechanisms; and rich interface languages permit the service to export sufficient information so that eventual clients can discover and connect to it [Pap03].

A SOA can be implemented in many different ways. A currently very popular approach uses a specific kind of service called web service. It exchanges SOAP messages over standard Internet protocols (e.g. HTTP) which carry a payload built from a stack of open XML standards [wsa04]. There are strong similarities between services and components in a component based system [Szy03]. However, services usually have a coarser granularity and the communication medium (the Internet) with its high latency and openness constrains reliability and security beyond what can be found in most component based systems.

The services in a SOA usually belong to different organizational domains and therefore there is no single line of authority regulating their interactions. In principle a consumer must trust the provider to deliver the expected service, or establish a contract with it. In this project a contract is a generic term for the specification of a service which is negotiable and either statically enforceable or monitorable. In other words, a contract describes an agreement between distinct services that determines rights and obligations on its signatories, and for which there exists a programmatic way of identifying contract violations. A service provider may also use a contract template (i.e. a yet-to-be-negotiated contract) to publish the services it is willing to provide. As a service specification, a contract may describe many different aspects of a service, including functional properties (i.e. behavior) and also non-functional properties like security (e.g. access control), quality of service (QoS), information flow and reputation.

In a SOA, entities participating in a service provision (as either providers or consumers) have partial access to information. Most notably, a service consumer has hardly any access to the code implementing the service (located at the provider's side), and is therefore unable to examine, much less verify, the service implementation to have assurance of its compliance with published interfaces. This makes a clear distinction with single-organization situations. While service providers may use some kind of static verification to raise their confidence in the good properties of the service to be delivered, service consumers still need runtime monitors to collect data to detect misbehaviors as soon as possible, or for resolving disputes at a later stage. This means that, in fact, a contract is more than a mere service specification because it must also identify the way this service is to be monitored.

There exists a number of contract models for services. The business process standard ebXML [ebx] describes a Collaboration Protocol Agreement as a contract between business partners that specifies the behavior of each service (by simply stating its role) and how information exchanges 1In the case of a bilateral contract one usually talks about the roles of service provider and service consumer; but multilateral contracts are also possible where the participants may play other roles are to be encoded. IBM's Web Service Level Agreement (WSLA [wsl]) is an XML specification of performance constraints associated with the provision of a web service. It defines the sources of monitoring data, a set of metrics (i.e. functions) to be evaluated on the data, and obligations on the signatories to maintain the metric values within certain ranges. The set of predefined metrics and the structure of WSLA contracts are designed for services involving job submissions in a grid computing environment. The later WSAgreement [wsg], a Global Grid Forum recommendation that has not reached the standard status yet, is based on WSLA but adapted to more recent web services standards (e.g. WS-Addressing and WS-Resource Framework). WS-Agreement is also parametric on the language used to specify the metrics (but it must be an XML dialect).

A number of problems have previously been identified for these standards and specifications: They are restricted to bilateral contracts, lack formal semantics (and therefore it is difficult to reason about them), their treatment of functional behavior is rather limited and the sublanguages used to specify QoS and security constraints are usually limited to small applicationspecific domains.

In order to remedy the situation the research community has produced contract taxonomies [Aag01, BJP99, Tos05], formalizations using logics (e.g. classical [DKR04], modal [DM01], deontic [PDK05] and defeasible logic [Gov05]) and formalization based on models of computation (e.g. finite state machines [CMJW04] and Petri Nets [Das00]). The diversity of contract types, their applications and properties poses a serious challenge to the definition of a generic contract model. This, however, has been identified as a major precondition for the advancement of the area [ARM04]. Other requirements include design methodologies, model verification and implementation tools, middleware infrastructures and programming language technologies that are contractaware.

• Quality of Service

According to the ARTIST roadmap [ARM04], quality of service is a “function mapping a given system instance with its full behavior onto some [quantitative] scale”. Typical QoS measures for web services include average response time, minimum communication bandwidth and peak CPU usage. Contract languages like WSLA and WS-Agreement (mentioned in the previous section) permit the specification of QoS constraints over web services. QoS measures usually depend on the behavior of the environment as well as of the service, thus models tend to have a stochastic nature, although this is not really necessary for monitoring purposes. Monitors are usually weaved in into the application code, creating complex dependencies that seriously affect the software development process.

• Information Flow

Information flow concerns issues like confidentiality and integrity of information. Contract languages for security (e.g. [BdWJ05]) do not usually address information flow. Regarding enforcement, there are static solutions; in fact we are not aware of any that use runtime methods. The static approach usually comes in the shape of a type system to enforce non-interference [SS01], rendering it unsuitable to most real-life situations in which an application is expected to declassify some well-defined information. Type systems that try to accommodate declassification (eg. [Mye99]) soon suffer from the label creeping problem (due to the accumulation of small losses of precision in identifying confidential information, see [DG03] for a discussion). On the other side, since information flow properties are not safety properties (in fact, they do not even qualify as properties in the Alpern-Schneider classification [AS85]), run-time approaches are generally considered inappropriate. However, recent results provide strong evidence that certain (approximations of) information flow properties may be RW-enforceable (cf. the “Secret File Policy” example [MSH03] and [Gia05]).

Current programming language abstractions are not good enough for SOA, much less for web service development. The industry develops web services using the object-oriented programming (OOP) paradigm which maps badly to document-based communication (i.e. XML documents over SOAP) that web services require (see [MSB03] for an indepth discussion). Besides, current production OOP languages (e.g. Java and C#) do not handle concurrency and message passing particularly well. Another criticism to OOP concerns the possibility of reusability. Object-orientation provides two distinct mechanisms for composing concerns: through aggregation and through inheritance. Some examples show [AT98] that reusing components through aggregation and inheritance mechanisms may not be successful when the objects implement concerns like history information, multiple views and synchronization. OOP needs therefore better abstractions.

The programming language community has long identified the need to provide easier ways to extend the abstraction mechanisms of a language. One of the main approaches of the day is that of Aspect-Oriented Programming (AOP) [FECA05], which helps separate crosscutting concerns (like logging and access control) from the main business logic. AOP is composed of a set of techniques, including code instrumentation and run-ime interceptors.

A similar approach uses composition filters (CF) [ABV92], where the idea is not to replace the programming paradigm but to enhance the expressive power and maintainability of current OO languages. CF may be considered as a modular extension to the object-oriented model with interface layers including the socalled filters. Advantages of CFs with respect to aspects are exposed in [BA01].

An alternative approach aims at defining new kinds of languages that adapt themselves better to the challenges posed by web services. Some concentrate on bridging the gap between the program language objects and the XML objects that web services should exchange [FGK02, FGK03, MSB03], others provide abstractions to manipulate interfaces [CDR05], and others address asynchronous communication by means of message passing [BMS05]. So far, Creol [Cre] belongs to the last group.

In any case, all these solutions still lack any support for discovery, monitoring and management of contracts. Approaches like AOP and CF can potentially provide some help here (see e.g. [BG01]), but they fail to abstract low level issues and basically leave too much freedom to the programmer (which leads to code maintenance and analysis issues).

Despite of the current wide acceptance of AOP as a good paradigm for improving maintainability, reusability and modularity, there is no convincing and final solution to the application of aspects to realtime systems. For some specific instance [TCB04] AO seems to perform better than OO when dealing with real-time specification, regarding system properties such as testability and maintainability. On the other hand, in [ABD+05], the authors presents a formal framework for multithreaded software and multiprocessor architecture software synthesis using timing constraints, where it is shown that AO software development is not suitable for such case.

A new concept for real-time system development (ACCORD) is presented in [TNHN04], combining both component-based and aspect-oriented software development (CBSD and AOSD, respectively). ACCORD bridges the gap between modern software engineering methods –focused mainly on component models, interfaces and separation of concerns– and real-time design methods, by proposing a model for software development using the advantages of both communities. As far as we know, the focus is primarily on the design methodology of real-time systems by using CBSD and AOSD, but not on analysis (e.g. verification) of realtime systems. It is not clear, either, how the methodology could be used inasynchronous open distributed systems such as the Internet.

We believe object-orientation is still a good paradigm for modeling open distributed systems. The main problem with OO comes from language design and implementation decisions, not from its original philosophy. The Creol project [Cre] has been addressing many of the criticisms of OO. Essentially, a Creol program consists of concurrent objects communicating asynchronously and with internal process control, using processor release points [JO04a, JO04b]. Compared to for instance Polyphonic C#, Creol has a simpler set of communication primitives using the concept of asynchronous method call. By staying within the method paradigm, inheritance and overloading is unproblematic. Creol allows multiple inheritance, which is not supported by Polyphonic C#. In addition, the dynamic class construct of Creol is well suited for reconfiguration and maintenance of services in a large network. Creol, in its current state, seems to have the basic constructs suitable for modeling Internet in an objectoriented manner. In this project, the interface mechanism of Creol will be augmented with mechanisms suitable for static control and monitoring of contracts and services.