SLA@SOI Prediction Service

Overview

The approach to design-time prediction used in SLA@SOI is based on the Palladio Component Model (PCM) prediction method.The goal of the original PCM method is to predict QoS properties of a component-based software architecture at design-time. In SLA@SOI, this method is also used for service components rather than software components, and service-oriented architectures rather than component-based software architectures.

Prediction Input Models

Before a prediction can be performed, a system has to be completely described, with a specification consisting of five parts:

1. A software component model (represented by a PCM Repository instance) containing the software components (together with their interfaces, behaviour, and sub-level composition)
   
2. An architecture model (PCM System) describing the top-level composition of components to form the system
   
3. A resource model (PCM ResourceEnvironment) describing the available virtual nodes (PCM ResourceContainer instances) and network links (PCM LinkingResource instances)
   
4. A deployment model (PCM Allocation), i.e., a mapping of software components to virtual nodes
   
5. A usage model (PCM UsageModel) describing the usage of the system
   

Any consistent combination of parts (1) to (5) forms a prediction scenario and provides all necessary information for prediction to be performed.

Enhancement of Prediction for SLA@SOI

The SLA@SOI Prediction Service is intended to offer the following features, beyond the current capabilities of the PCM prediction method:

• On-the-fly prediction: Design-time prediction shall be executable as part of the automatic SLA negotiation process between a service consumer and a service provider. Thus, it has to be programmatically invoked, with all necessary data given as an input or retrieved during a preparation phase, and return the results to its caller.
• Multi-scenario prediction: Prediction shall not only be executed for a single scenario, but rather for a series of related scenarios. Such a series involves varying a certain scenario part (for example, the deployment model), while keeping the other parts fixed. To some extend, prediction must be able to automatically produce different scenario variants on the basis of parameters given as an input or retrieved during preparation. The results of all predicted scenario variants shall be returned to the caller in terms of a result list. Each entry of the result list shall contain a reference to the corresponding scenario variant, as well as the prediction results themselves.
• Distributed prediction process: Prediction shall be done in a distributed process across several service providers. The providers are connected to each other through their provided and required services. Each providers sees his own part of the architecture and performs predictions for this part. Thus, prediction must translate response time and throughput requirements for provided services into a usage profile, and deduce response time / throughput for required services from simulation results.
  

Concepts & Implementation

The Design-time Repository and Prediction Service implementation consists of four libraries within the negotiation module:

• org.slasoi.negotiation.repository.models
• org.slasoi.negotiation.repository.access
• org.slasoi.prediction.models
• org.slasoi.prediction.access

In the following sections, each of these libraries is described separately.

Negotiation.Repository.Models

• Code location: http://svn.fzi.de/svn/sla_at_soi/project/Software/slasoi/trunk/negotiation/repository/models
• Contains the meta-models for data residing in the design-time repository

Software Model

Description: A model describing the parts of the architecture that are to be specified by the software provider and service provider (or, in PCM terminology: component developer and system architect). These are the individual software or service components with their interfaces, their behaviour (annotated with parametric resource demands), and their composition to a system. The contents of the model are devided into two parts:

• A Component Repository (represented by a PCM Repository instance) describing components (basic and composite), interfaces, and behaviour
• A set of Architecture Repositories (PCM System instances) describing component composition to a system

Usage: The Software Model provides two parts of a prediction scenario: The software component model (provided by the Component Repository) and the architecture model (provided by each of the Architecture Repositories). Complete prediction scenarios can be formed by adding a resource model, a deployment model, and a usage model.

Discussion: In its current form, the Software Model accepts only one component repository. The idea is that systems are stored component-wise into the repository, and one repository contains the components of all systems under consideration. Each composition of components to a system is stored in an own architecture repository. This approach is very general but has great problems in practice. These problems are mainly rooted in the fact that the PCM Repository class representing the Component Repository is not prepared to store components across system borders:

• Adding a new component to the repository means extending an existing EMF object tree with a new sub tree. Because components are bound through a containment relationship to the repository, they are not meant to be exchanged between repositories, and it is very hard (or nearly impossible) to consistently insert the new component and update all involved references correctly. Rather, the component would have to be "rebuilt" within the repository, a task that is probably equally error-prone.
• Similar problems arise when adding an interface to the repository. Furthermore, when a component C providing or requiring an Interface I shall be added to the repository, it has to be decided wheter I matches any of the already existing Interfaces or not. Even if there is an already existing Interface I* that totally equals I, it is unclear if the identities of I and I* should be assumed to be equal.
• Any element added to the repository could potentially violate the requirement of unique Identifiers throughout the whole repository. It is unclear how to react to such a condition.

Thus, the Software Model should rather hold one Component Repository for each system under consideration (even though components are then not reusable across system boundaries). At least for year 1, this approach is sufficient.

Deployment Options Model

Description: A model describing potential deployment options. The options are described by defining groups of software components that shall be deployed together on one virtual node. Individual components within a group are referenced via their ID. Multiple groups can be required to be separately deployed. Furthermore, a group can have a special flag requiring that the group is exclusively deployed on an own virtual node.

Usage: A Deployment Options Model provides information based on an existing description of components and resources. When a software component model and a resource model are given, the Deployment Options Model can be used to derive a set of possible deployment models. A complete prediction scenario can be formed by adding an architectural model and a usage model.

Discussion: Originally, a Deployment Options Model should be part of prediction service input. Ultimately, the end user should be enabled to enforce certain rules concerning system deployment. However, it was agreed that there is no sense in letting the user directly specify deployment rules for single software components or groups of components. Thus, by now (2009-03-13) the model is obsolete. However, it can still make sense to have the model as a part of the design-time repository to restrict the number of possible deployment models of a system to the most common or reasonable ones. Otherwise, the prediction service would have to try out a very large number of deployment models consisting of every possible mapping between components and virtual nodes.

In year 1, it is sufficient to use statically determined deployment models, so the Deployment Options Model is not yet used.

Usage Pattern Model

Description: A model that introduces patterns of system usages. A pattern consists of a system usage description (provided by a PCM ScenarioBehaviour) and a description of variation points (provided by PCM Identifier instances). Instances of patterns can be defined by declaring concrete values (or stochastic expressions, embedded into PCM VariableUsage instances) for each variation point and adding a workload description (PCM Workload). The usage model itself aggregates multiple pattern instances, referring to patterns stored in a repository.

Usage: The model is intended to provide a simplified method for defining system usage. The caller of prediction shall not be forced to create a complete usage scenario in PCM terminology, but only a reference to a predefined usage pattern and parameters specifying values for variation points. The pattern repository is part of the design-time repository. The pattern-based usage model is given as an input to prediction. Knowledge about the semantics of the patterns and variation points has to be shared between service provider and service customer.

Discussion: Currently there is only a first version of the model, which needs significant revision:

• The associations to PCM Identifiers do not work as intended; instead, all classes which should have an ID must inherit from the Identifier class (this requires also introducing a new class for variation points).
  
• It is not clear if leaving Workload specification completely to the pattern instance is the best way. Rather, it should be included into the pattern and just parametrized by the instance.
  
• In the long term, the model may be replaced by a more general form deduced from Lucias work with higher-ordered transformations (HOT).
  
• It is unclear how the model should or could relate to the core meta-model.

Furthermore, it is not clear if the model is needed at all. By now (2009-03-22), it is only planned to have SLAs with response time and throughput requirements for single service calls. In year 1, these SLAs, together with some additional parameters (e.g., number of sold items for the bookSale call) will be specified by the service customer. A simple parameter class and automatic adaption of an existing usage profile should be adequate.

Negotiation.Repository.Access

• Code location: http://svn.fzi.de/svn/sla_at_soi/project/Software/slasoi/trunk/negotiation/repository/access
• Represents the design-time repository itself and provides the corresponding access methods
  

Description: The design-time repository stores the models that serve as a basis for design-time prediction. Methods for adding, accessing and manipulating models have been realized. For more information, see the interface description in SLA@SOI Wiki.

Discussion: In its current form, the repository is a first shot, which will have to be seriously revisioned. Lessons lerned include:

• We are not free to load EMF models and to store them at new locations as we like. References across model parts will point to the source locations (can this possibly be avoided by a "ResolveAll" EMF call or something similar?). So, the only solution at the moment is direct copying the model files. This rules out much of the functionality written so far.
• Trying to copy new components into an existing PCM Repository is not easy. Temporary methods have been written to avoid trouble. These methods take the complete models without touching them. Again, the main part of written functionality is ruled out as non-working.

Currently, everything is fixed. The design-time repository thus is reduced to nearly nothing. The question is if that is ok for year 1, and what shall be realized in the long term.

Negotiation.Prediction.Models

• Code location: http://svn.fzi.de/svn/sla_at_soi/project/Software/slasoi/trunk/negotiation/prediction/models
• Contains meta-models for data that is used as input or output for design-time prediction
  

Prediction Result Model

Description: Connects a set of prediction results with information about system deployment. The deployment assigns groups of software components to virtual nodes. The results can contain percentiles, mean values and confidence intervals. The semantics of a result (identification of QoS metric, identification of point of measurement) is encoded into a string atttribute of the Result class.

Usage: The model is intended to be used as result data output of prediction. As prediction not only deals with one concrete scenario, but with a series of possible scenarios, the top-level ResultSet class includes a series of DeploymentResult instances, where each instance reflects one prediction scenario (deployment: resources & allocation) and the corresponding prediction results.

Discussion: There are several open issues with the model:

• Details are still missing, like attributes describing the properties of a virtual machine.
  
• Specification of result semantics (currently reflected by the assignment attribute of the Result class) is not fully solved yet: How can semantics be encoded in a string? Required knowledge for interpretation of this string has to be shared between service provider and customer.
  
• How can the prediction caller influence what measurements should be done and returned as prediction results? What kind of results shall be returned by default? Such information would have to be part of prediction input data.
  
• The application of the ConfidenceInterval class is yet unclear.
• The aggregation of infrastructure costs is not yet supported. It is unclear if this should be provided by prediction.
• How should / could the model relate to the core meta-model?
  

Negotiation.Prediction.Access

• Code location: http://svn.fzi.de/svn/sla_at_soi/project/Software/slasoi/trunk/negotiation/prediction/access
• Represents the design-time prediction and provides the "predict" method
  

Description: The prediction component provides the main "predict" method to perform design-time prediction. See the interface description on the SLA@SOI Wiki for details. A series of scenarios is predicted in one prediction run. The required information is gathered as follows:

prediction model	fixed or variable	source of information (year 1)	source of information (long term)
software component model	fixed for each software system under consideration	statically retrieved from DTR	statically retrieved from DTR
architecture model	fixed for each software system under consideration	statically retrieved from DTR	statically retrieved from
resource model	variable because of different available infrastructure options	statically retrieved from DTR (?)	built on-the-fly from infrastructure options
deployment model	variable because of variable resource model and multiple deployment options	statically retrieved from DTR (?)	built on-the-fly from resource model and deployment options
usage model	fixed by the caller of prediction	built on-the-fly (pattern-based) or statically retrieved from DTR (?)	built on-the-fly from pattern retrieved from DTR and parameters given as

Discussion: So far, the prediction component is mainly a skeleton showing the outline of what should be realized in the long term. For year 1, ORC will be statically loaded from the design-time repository. No dynamic generation of model parts will be involved.

Open Questions

Currently (2009-03-22), the most important open questions for year 1 prediction service implementation are:

• What is REALLY needed for year 1 as input and output of prediction service? Who (name of developer) will call prediction and take back the results?
• How can prediction service be executed within an OSGi platform and accessed from outside? How shall functionality be divided between client and server side?
• Can I assume predefined infrastructure options or is a real query necessary?
• What are the assumptions about external Services (bank service)? Must response time and throughput requirements of external services be returned to the prediction caller?
• How can throughput be measured with an open workload? How is it possible to assure that the system is not overloaded?
• What will be the exact scenarios that the ORC model needs to reflect?
• What requirements have to be fulfilled for technical integration of prediction into the SLA@SOI framework?
• Is signalling for adhoc demonstrator needed (and if yes, how to do that)?

Meeting Notes

2009-03-31 (Jens, Christof, Franz)

Result-Datenformat Prediction Service

• Änderungen PredictionResultModel:
  • Deployment Options (linke Hälfte): In Besprechung geändert --> Franz checkt neue Version ein
  • Results (rechte Hälfte): Referenziere Core-Metamodell --> Jens
• Beispiel-Results erstellen und mit Partnern abstimmen (v.a. Costas) --> Jens

Remote PCM

• PCM als separater Prozess (OSGi Plattform - Eclipse 3.3 - JDK 1.6)
• SLA-Framework basiert auf EMF 3.4 und JDK 1.5
• Verwende RPC statt "raw" TCP
• Aufteilung der Funktionalität zwischen Client (SLA Framework) und Server (PCM/OSGi):
  • Zunächst nur einzelne Simulationsläufe in PCM; "Ansteuerungslogik" auf Client-Seite

Weitere Ergebnisse

• Results werden mit String qualifiziert (Format mit Costas absprechen, z.B. Service-Name:Interface:Operation)
• Infrastruktur-Optionen in Jahr 1 fix
• Alle Modelle in Jahr 1 fix (aus Design-time Repository), keine dynamische Erstellung von Modellen