TAPAS

WP1 – Application Service Requirements and Specification

This Presentation

• Briefly, the goals of WP1

• The context of the problem

• Our approach

• A language for service level specifications

• Performance modelling for application services

The Goals of WP1

• Report describing application hosting requirements [delivered by Adesso].

• Service level agreement specification method.

• Service composition and analysis method.

• A toolkit for service composition and analysis.

Application Service Provision in a Federated Environment

Marketplace

ASP

ISP SSP

Buyer

TTP

Vendor1

Vendorn

Credit Rating Agency

Retail Bank1 Retail Bankn

Service Level Agreement (SLA)

Vertical and Horizontal SLAs

Beans

Container

Network

Database

User Beans

Container

Network

What is a Service Level Agreement?

Service Level Agreement

Service Level Specification

Pricing Policy

ClientService Provider

«instance»

Legal Contract

Formalisation

• We intend to produce a formal language, with a well defined syntax and semantics for describing service level specifications (SLSs).

• It would also be beneficial to extend this language to associate costs with the entities and parameters in an SLS.

• Monitoring schedules could also be included.

Benefit of Formal SLS 1.

SLS Application Container

Management Statistics

Contract Verification

Interface

Client or subcontractor

Benefit of Formal SLS 2.

SLSs for existing

clients and sub-

contractors

System model

Modelling toolPredictions and evaluation of hypothetical

SLA

Hypothetical SLS

Formal SLS with Costing

SLSs for existing

clients and sub-

contractors

System model

Modelling tool

Legal boilerplate/cost

evaluations

Hypothetical SLS

Cost model

Formal SLS with Costing and Business Modelling

SLSs for existing

clients and sub-

contractors

System model

Modelling tool

Parts and service costs.

Better availability predictions.

Cost model

Businessmodel

Our Approach

• To use popular and standard information exchange formats – XML

• To use popular and standard modelling paradigms – UML

• To concentrate on specific, popular, state-of-the-art application server technologies – Enterprise Java Beans (possibly .NET)

Our Approach 2

• The SLS specification language will associate performance targets with identifiable ASP components.

• An ASP deploys QoS-aware middleware that monitors the components identified in each SLSs that they undertake to meet.

• Additionally, modelling tools will be developed to assist ASP in determining what SLSs they can undertake to meet.

Our Approach 3

• The SLS language will not have a semantics dependent on complete models of the ASP. These are not relevant to the purpose of an SLA, which is to define an agreement. The semantics will instead be defined in terms of the domains of the performance properties, those structural elements of the ASP that are pertinent, and partial process models describing use cases.

• In particular the language will not necessarily preclude ‘un-meetable’ or unreasonable specifications.

QoS Properties

• Are somewhat dependent on the system tier being described.

• Generic properties are:– Performance (latency, scalability)– Reliability (mean time to failure)– Availability (probability that the system will be

operational at a given instant)

QoS Properties 2

• Property value targets may be specified using ranges, or statistical distributions qualified by other variables, e.g. Performance vs. Load = Scalability

• Property value targets may be qualified by a ‘confidence’ or ‘tolerance’ – e.g. the target must be met at least 95% of the time.

SLS Composition

• Composition may not lead to inherently reasonable agreements. This must be evaluated separately by the partners to the agreement using modelling.

• SLSs must adopt a naming scheme for system components/assemblies that allows SLSs from different organisations to be concatenated without ambiguity.

• These names would automatically identify model and system components in modelling tools and QoS-aware middleware.

Modelling

• We intend to use UML models as the repository for all modelling information.

• SLSs will identify model components and the properties to be established.

• The UML will be converted to a variety of formal models, amenable to analysis, e.g. SPAs, Bayesian Belief Networks.

• The results of analysis will be reintegrated into the UML model.

Vertical Composition of Models

By refinement: Components

Objects

MethodsLevel of abstraction

Container action

Persistence Action

Processor Resource

Operating System Action

Subroutines

Network Resource

Performance observations and

predictions can be made at any level

of abstraction. Consistency must

be maintained between the levels.

Vertical Composition of Models 2

• The performance of an action at a higher level abstraction is directly dependent on the performance of the lower level actions.

• We can ensure that the guarantee at the higher (simplified) level is consistent with that of the lower level actions by calculating the latency of the more detailed lower-level model (e.g. using a SPA model).

• An analogous approach is possible for reliability using Bayesian networks. The rate of failure of an assembly is conditional on the failure rates of its components.

Horizontal Composition of Models

• Is easy. UML, Markov chains, Petri nets and equivalently, stochastic algebras, are all graph-based models. It is relatively easy to translate between the different formalisms and to compose two models of the same kind.

• Composition of results is generally difficult. No safe inference can be drawn about the behaviour of one system by examining the behaviour of a similar one, since a small change can alter behaviour considerably. Instead, compose the models then recalculate.

Composition of Models of Different Types

• We will want to factor availability information into performance guarantees. Bayesian networks inherently transgress the Markov property relied upon by SPAs.

• The answer might be quite simple: Modify performance estimates in proportion to availability.

• Alternatively heuristic approaches may be investigated.

• A unified approach based on only one modelling paradigm seems unlikely.

Modelling Pitfalls

• State-space explosion is the classic problem with graph-based models.

• The middleware approach with centralised services and object-request brokering is mitigating as it reduces nxn interactions to nx1.

• We aim to provide standard models of common services to assist in avoiding these problems.

• A modelling tool must incorporate cognitive support and feedback for modellers.