tapas wp1 – application service requirements and specification
TRANSCRIPT
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)
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.