Personal tools
You are here: Home Knowledge Model Browse by Domain Adaptation and Monitoring (KM-AM)

Adaptation and Monitoring (KM-AM)

by Andreas Metzger last modified Apr 29, 2012 14:26
— filed under:

WP-JRA-1.2: Adaptation and Monitoring

Modern Service-Based Applications are required to operate and evolve in highly dynamic environments, being able to adequately react to various changes in these environments. This makes adaptation, i.e., the process of modifying an SBA in order to satisfy new requirements and to fit new situations dictated by the environment on the basis of adaptation strategies designed by the system integrator, one of the key aspects of SBAs functionality. The range of possible changes that require application of adaptation includes changes in the infrastructural layer of the application, where the quality of service changes or the service becomes unavailable; changes of the (hybrid) application context and location, where the SBA should be able to replace one service by another possibly having other properties and parameters; changes of the user types, preferences, and constraints that require application customization and personalization as a means to adapt the application behavior to a particular user; changes in the functionalities provided by the component services that require modifying the way in which services are composed and coordinated; changes in the ways the SBA is being used and managed by its consumers, which should lead to changes in the application requirements and the business processes implementing them.

Depending on the type of the changes in SBA and its environment, adaptation may have different forms. In particular,

  • optimization is the modification of an application to make some aspects of it work more efficient or use fewer resources;

  • recovery (repair) is restoring an application after failing to perform one or more of its functions to fully satisfactory execution by any means other than replacement of the entire application;

  • QoS-based adaptation refers to changes in quality-of-service parameters of an SBA;

  • evolution is a long-term history of continuous modification of SBA after its deployment;

  • mediation is an activity in which a neutral third party, the mediator, assists two or more parties in order to help them achieve an agreement on a matter of common interest.

In order to detect critical changes, adaptation strongly relies on the presence of monitoring mechanisms and facilities. With monitoring we mean a process of collecting and reporting relevant information about the execution and evolution of SBA. Such information, namely monitoring events, represents evolution of SBA and changes in the environment. These events define the “What?” dimension of the monitoring process: they are used to indicate whether the SBA is executed and evolves in a normal mode, whether there are some deviations or even violations of the desired or expected functionality. Monitoring mechanisms are the tools and facilities for continuous observing and detecting relevant monitoring events; they identify the “How?” dimension of the monitoring process.

As monitoring events occur at different functional layers of SBAs, different monitoring types exist:

  • For the Business Process Management domain, Business Activity Monitoring provides near real-time monitoring of business activities, measurement of Key Performance Indicators (KPIs), their presentation in dashboards, and automatic and proactive notification in case of deviations.

  • For the Service Composition domain, Monitoring in service compositions refers to checking whether certain predefined properties over the composition model are satisfied when the composition is executed.

  • For the Service Infrastructure domain, Monitoring in Grid refers to scalable high performance monitoring on a large distributed computational Grid. It aims to tackle monitoring of generic middleware services and application-specific information and data transfer. There is also a need for the cross-cutting monitoring techniques and methodologies for SBAs.

The events identified during the monitoring process carry the information about potential changes that the system and / or the underlying platform should perform in order to adapt to a new situation. The relation between the monitoring events and the changes of SBA are defined by the adaptation requirements and objectives: requirements and needs that SBA should achieve in reaction to critical changes and events. This may include the need for the fault recovery, QoS properties optimization, requirement to mediate service interfaces, etc.

The adaptation requirements are realized through adaptation strategies. Adaptation strategies describe the ways to achieve the requirements given the adaptation mechanisms, i.e., tools provided by the underlying platform (independently) in different functional layers of SBA.

The Adaptation and Monitoring research domain is strongly related with other research areas. Engineering and Design domain and provides approaches and notations for defining:

  • monitoring specifications (monitoring languages), which describe SBA execution properties, context, events, and changes;

  • engineering principles for monitoring (design for monitoring), where monitoring architectures and realization patterns are identified;

  • adaptation specifications (adaptation languages), which describe the adaptation strategies, application variability models;

  • engineering principles for adaptation (design for adaptation) with the corresponding architectures and patters.

Domains of realization mechanisms from different functional SBA layers, in turn, provide the corresponding infrastructures, tools and techniques. This include, in particular,

  • Monitoring infrastructure, such as various logging mechanisms;

  • Monitoring tools and techniques, such as process/data mining approaches;

  • Adaptation infrastructure, e.g., automated service discovery and binding frameworks;

  • Adaptation tools and techniques, e.g., automated service composition approaches.



Document Actions
  • Send this
  • Print this
  • Bookmarks

The Plone® CMS — Open Source Content Management System is © 2000-2017 by the Plone Foundation et al.