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 ISPSSP Buyer TTP Vendor 1 Vendor n Credit Rating Agency Retail Bank 1 Retail Bank n Service Level Agreement (SLA)

Vertical and Horizontal SLAs Beans Container Network Database UserBeans Container Network

What is a Service Level Agreement? Service Level Agreement Service Level Specification Pricing Policy Client Service 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 tool Predictions 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 Business model

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 Methods Level 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.