A formal model of services

Abstract

Service-oriented software systems rapidly gain importance across application domains: They emphasize functionality (services), rather structural entities (components), as the basic building block for system composition. More specifically, services coordinate the interplay of components to accomplish specific tasks. In this article, we establish a foundation of service orientation: Based on the Focus theory of distributed systems (see Broy and Stølen [2001]), we introduce a theory and formal model of services. In Focus, systems are composed of interacting components. A component is a total behavior. We introduce a formal model of services where, in contrast, a service is a partial behavior. For services and components, we work out foundational specification techniques and outline methodological development steps. We show how services can be structured and how software architectures can be composed of services and components. Although our emphasis is on a theoretical foundation of the notion of services, we demonstrate utility of the concepts we introduce by means of a running example from the automotive domain.

From StPowla processes to SRML models

“…A (formal) model of services based on Component Based Development (CBD) can be found in [BKM07]. There, services are seen as "crosscutting elements of the system under consideration", describing "partial views on the set of components in the system under consideration" [BKM07].…”

“…There, services are seen as "crosscutting elements of the system under consideration", describing "partial views on the set of components in the system under consideration" [BKM07]. SRML captures a different notion of SOC in that there is no "system under consideration", conceived a priori, that services crosscut.…”

A Use-Case Driven Approach to Formal Service-Oriented Modelling

“…Given that different people have different perceptions of what SOC and CBD are, we will simply say that, in this paper, we will take CBD to be associated with what we called the 'static' engineering approach. For instance, starting from a universe of (software) components as 'structural entities', Broy et al view a service as a way of orchestrating interactions among a subset of components in order to obtain some required functionality -"services coordinate the interplay of components to accomplish specific tasks" [6]. As an example, we can imagine that a bank will have available a collection of software components that implement core functionalities such as computing interests or charging commissions, which can be used in different products such as savings or loans.…”

Towards Smart Systems of Systems

“…The use of collaborations for the modeling of services [13,14], the use of class diagrams for the structure and graph transformations for the behavior modeling [15,16], and a formal model of ensembles [17] have been proposed. However, none of these approaches supports the construction of dynamic collaborations as required for smart SoS where systems dynamically join or leave the federation.…”