-
Notifications
You must be signed in to change notification settings - Fork 0
MUSIC
[Related Work](https://github.com/dsoa-team/dsoa-platform/wiki/Related Work)
MUSIC is the successor of the MADAM project and has its focus on the open world assumption by targeting computing environments that are characterized by openness, heterogeneity, dynamic service discovery and binding [Hallsteinsen et. al 2012]. In MUSIC, application components can be replaced by services, which are dynamically discovered and selected based on non-functional properties. MUSIC points the number of supported adaptation mechanisms, including parameter setting, component replacement and service binding, and redeploying components, as a distinguishing feature.
MUSIC implements the MAPE-K architectural pattern, where the Knowledge is composed by architectural models. In MUSIC, an application is represented by an architectural model, which consists of a component framework, describing an abstract composition of functionalities expressed as a set of typed roles (which correspond to component types) connected trhough ports. Typed roles can be dynamically configured with conforming role realizations, which correspond to component implementations. A role realization is in conformance with a role type if the ports that it implements match those defined by the role type.
Ports are defined to connect components or a component and a dynamically discovered services. Ports have properties and predictor functions which specify how the correspoding QoS can be computed and which resources are needed. The predictor functions are defined through expressions over the properties of the context and components in the roles. Finally, the adaptation process is driven by a utility function, which is used during planning to evaluate alternative configurations.
From the modelling point of view, MUSIC proposes a UML Profile defining stereotypes and tagged values, which are used to specify application architecture, variation points, component and service properties, context dependencies and links between the domain and adaptation models. The MUSIC profile is organized in three packages: Types, Realizations and Middleware Extensions.
As DSOA, MUSIC platform defines a language that is used to model QoS-Aware Service-Based Applications. In MUSIC, this model pass through a transformation process giving origin to a model@runtime, which is central to the adaptation process. There are some important points that MUSIC does not deal with. Firstly, QoS is not a explicitly represented in MUSIC. Instead it is modelled through the use of properties. Consequently, the supporting middleware has no information concerning how the QoS can be effectivelly monitored, nor how different quality metrics can be computed. So, the developer has no opportunity to express that kind of information. Secondly, it doesn't seem to be possible to define new metrics at runtime, an consequently the embedded monitor can not be easily extended. These points are central to DSOA platform.