Analysing Time-Related Properties of Service-Oriented Systems

Introduction

One of the foundational characteristics of service-oriented applications is that they are composed “on the fly” out of services externally procured from potentially different providers. Service requesters select and bind to a required service based on how candidate services meet required functional requirements and maximise expected levels of quality of service, at the time they are needed. For this process to work, it is essential that providers can certify that the published services satisfy the service level agreements (SLAs) that they advertise and, therefore, guarantee the fulfilment of their contractual obligations. For example, one may want to certify that a mortgage-brokerage service satisfies an SLA of the form “In at least 80% of the cases, a reply to a request for a mortgage proposal will be sent within 7 seconds” before signing off a contract with a customer. In this chapter, we propose a formal approach to the modelling and analysis of such time-related properties of service-oriented systems.

A number of approaches – see (Balsamo, 2004) for a survey – feature quantitative analysis in the early stages of design in order to prevent design choices from affecting the deployment of systems in a negative way. However, to the best of our knowledge, we are still lacking: (1) a formal model of how such quantitative aspects arise in service-oriented architectures (SOAs), and (2) methods, languages and tools that can be used by designers to develop services that can be certified to meet given timing constraints. One of the challenges raised by such scenarios to the usage of existing quantitative analysis techniques in the context of service-oriented applications is that the full extent of the system through which a service will be provided is not known at design time: designers can only rely on a model of a part of that system plus a number of requirements on the properties of the services to be discovered at run time.

The approach that we propose in this chapter is based on an extension of the SENSORIA Reference Modelling Language – SRML (Fiadeiro, 2010). SRML is a high-level modelling language that supports both the architectural and behavioural specification of service-oriented artefacts. SRML offers a technology-agnostic framework in which models are independent of the languages in which components are implemented and the network protocols through which they communicate. The architectural definition of SRML has been inspired by the Service Component Architecture (SCA) a middleware-independent framework for service deployment proposed by an industrial consortium (SCA Consortium, 2005). SCA makes available a general assembly model and binding mechanisms for service components and clients that may have been programmed in possibly many different languages, e.g., Java, C++, BPEL, or PHP. However, where SCA supports bottom-up low-level design, our aim for SRML is, instead, to address top-down high-level design. More specifically, SRML provides a language for the high-level behavioural description of each element of the architecture and mechanisms that support the design of complex services from business requirements. The analysis techniques that we have been defining for SRML aim at allowing designers to verify or validate properties of composite services that can then be put together from (heterogeneous) service components using assembly and binding techniques such as the ones provided by SCA.

The proposed extension of SRML includes semantic primitives for capturing different kinds of delays that can occur during service provision. Delays are considered at a high level of modelling, i.e., independently of the choice of implementation language or infrastructure, but on the basis of explicit assumptions on how decisions taken at lower levels of design may affect and interfere with timing properties. More precisely, the kind of delays that we model concern the internal structure/behaviour of the service (the time that internal components take to process events and perform computations on their local states), the SOA middleware (the delays that arise due to discovery and selection of external services), and the communication with the services to which they bind.