Problem Statement

Runtime self-management involves dynamically adapting a service-oriented computing system in response to changes in its execution environment (HFDTC06). In order to ensure the “correctness” of the runtime self-management, the system needs to satisfy the architectural constraints associated with the adaptation.

Story

We base our examples on the scenarios from the Automotive Case Study which are used to identify the modes and transitions needed to describe the desired evolution of a specific vehicle subsystem. Our case study is a Route Planning Subsystem (RPS) for a vehicle, which is in charge of providing guiding indications to the driver. The RPS has several modes of operation.

• "Planning" - where user input determines the goal destination and route plan
• "Convoy" - where one RPS is guided by another RPS in a group of vehicles
• "Detour" - an external service directs the RPS to a "safe" alternative route to reach the destination

Solution

We propose the notion of Mode as a new element of architectural descriptions. A mode abstracts a set of services that must interact for the completion of a task. The inclusion of modes and mode transitions as explicit elements of architectural descriptions helps in providing support for describing and verifying daptations of service-oriented computing systems.

Languages

• UML component diagrams (type and instance level)
• UML / ITC Message Sequence Charts (MSC)
• Darwin (+mode extensions)
• Alloy
• FSP (Finite State Process)
• PONDER A Policy Language for Distributed Systems Management
• WS-* : WSDL, WS-BPEL, WS-CDL
• Semantics: OWL-S

Tools

• WS-Engineer
• Service Broker (Dynamic Service Interactions)
• Service Bridge (Transformation and Protocol Mapping)

Languages

• UML2 CASE tool
• Type inference tool for Lambda-req
• Model checker and planner

Steps

• Build a software architecture based specification of the architecture of the system, based on some well defined requirements, including appropriate fault tolerance (and self management) mechanisms. (example: Mode1)
• Define the constraints on mode configurations in ALLOY.
• Declare the policies for mode changes in PONDER.
• Analyse the architecture to check that it has desirable Structural properties
• Build an LTSA model of the specification (and constraints and policies) as an intermediate design, actually an abstract program design, lying between the architectural specification and the code level implementation.
• Analyse the model to check that it has desirable Behavioural properties, including properties that demonstrate that the model conforms to the specification.
• Use standard transformations to turn the high level design into work activities (possibly service compositions) and service broker requirements and capabilities documents.
• Analyse the compositions for conformance with previous models.
• Deploy the service compositions.....

Relevant for Case Studies

• Automotive Case Study
• Finance (Self-Service System) - Reconfiguration of components, interactions and composition analysis

Relevant for Work Packages

• Modelling in Service-Oriented Architectures
• WP5: Combining services
• WP6: Deployment and Re-engineering
• WP8: Automotive Case Study

Papers