January 14th 11:00 AM12:30 PM Morning Session

1
January 14th 1100 AM-1230 PMMorning Session
www.oasis-open.org
2
www.oasis-open.org

• 1100 AM 1230 PM
• SLA
• Service Contracts
• Cross domain services
• Non Functional Properties of Services
• Tracking/ Auditing Charge Back

3
Measuring Services SLA Compliance

• Need to differentiate between service SLA and
  measuring service SLA compliance
• Services may need to have a service compliance
  interface (testing to verify claims against SLA)
• Relationship to service composition
• W-SLA, service testting and monitoring
• Relation to Non-functional properties

4
Scope of Typical Telecom SLA

• Network SLA compliance measurement is required
  whenever a network service performance based on a
  contractual agreement.
• Performance is used here to define any number of
  attributes of that network.
• Usually the SLA domain is defined with
  demarcation points in the network and these are
  usually defined at the boundaries of the control
  domains, (typically the edge NEs).
• Although an SLA is usually a comprehensive
  contract for multiple items (e.g. spans) each
  item must be measured individually and
  constitutes its own SLA.
• Services measured can include
• Response, capacity, security, dependability,
  flexibility, cost, etc..
• The Level metric can be a specific value or a
  range and are relevant to the Service. These
  levels might be defined as 10ms, gt 5 Mbps
  etc..
• Agreements define the services, levels,
  measurements, and consequences of exceeding,
  meeting, or missing defined levels. These might
  include
• monetary compensation
• contractual changes
• publicity
• liability
• Authority for measuring SLA compliance
• Service consumer,
• Service provider,
• Independent third party

5
Minimal Aspects Approach

• It can be argued that there are only three
  primary aspects for any SLA
• Performance
• Delay Delay variation (jitter)
• Connectivity - no connection, no performance
• Dependability - no connection, no performance
• Availability
• Reliability
• Data integrity
• Errors
• Sequencing (Delivery order)
• Privacy - Ethical/legal requirements
• Cost
• Security
• Theft of service
• Dependability
• Reliability
• Interoperability
• Scalability
• Flexibility

6
Composed services and their part in Web Services
Service Level Agreements (WSLA)

• Need a taxonomy or ontology of service behaviors
• Need an approach to calculating behaviors of
  composed services
• Service failure is one of many identified
  behaviors

7
Background Orchestration as a New Programming
Paradigm

• SOA promotes the concept of combining services
  through orchestration - invoking services in a
  defined sequence to implement a business process
• Orchestration compounds the task of testing and
  managing the quality of the deployed services
• Testing composite services in SOA environment is
  a discipline which is still at an early stage of
  study
• Describing and usefully modeling the individual
  and combined behaviors - needed to offer Service
  Level Agreements (SLA) - is at an even earlier
  stage

8
Testing Composed Services

• Its fairly straightforward to test the operation
  of a device or system if we control all the
  parts.
• When we start offering orchestrated services as a
  product, the services we are using may be outside
  our control.
• For example consider well-known components
• Google mapping service
• Amazon S3 storage service
• Mobile operators location service

9
Testing Composed Services (2)

• With orchestrated services, there is never a
  complete box we can test
• With orchestration as the new programming
  paradigm, testing becomes a much bigger problem
• Failures of orchestrated services are often
  Heisenbugs - impervious to conventional
  debugging, generally non-reproducible
• Offering a WSLA based on testing alone, without
  reliable knowledge of component service
  behaviors, may be risky

10
Web Services SLA (WSLA)
Packets
Provider X Service X
Service Provider Z
Client
Network
Web Service
WSLA
Provider Y Service Y
Message flows

• Concerned with behaviors of the message flows and
  services spanning the end-to-end business
  transaction
• Clients can develop testing strategies that
  stress the service to ensure that the service
  provider has met the contracted WSLA commitment
• Composed services make offering a WSLA more risky

11
How can WSLAs be derived from behaviors of
component services?

• Need to develop a model of the behavioral
  attributes of the individual component Web
  Services which contribute to the overall behavior
  of an orchestrated or composed Web Service.
• Need to model the combination of individual
  service behavioral models

12
Web Services behaviors

• Behaviors may be described and quantified for
  each Web Service
• May be combined by a calculus of behaviors when
  multiple services are composed
• Behavior parameters may become a part of the
  service description, perhaps in WSDL.

13
Web Services behaviors (2)

• To develop a Service Level Agreement (SLA) for a
  composed service (Z), we need to have relevant
  behavior descriptions for the individual services
  (X and Y)
• We also need a deep understanding of how to
  combine the descriptions of X and Y to calculate
  results for Z

Z
X
Y
14
Web Services behaviors (3)

• For each behavior, the challenges include the
  following
• How may service Xs and service Ys behavior be
  characterized?
• How may those characterizations be formalized and
  advertised by X and Y?
• How may Z incorporate Xs and Ys
  characterizations and then advertise the result?
• Z itself might become a component of an even
  larger service and therefore needs to advertise
  its own characteristics. It also needs this
  characterization to offer an SLA to consumers.

15
Web Services behaviors (4)

• Each behavior may have its own ontology,
  measures, and calculus of combining those
  measures when services are composed.

Local Ontology
Z Specific Ontology
Abstracted Ontology
?
X
Local Ontology
Z
Abstracted Ontology
Y
Need this analysis for each behavior of services
X, Y and Z
Local Ontology
16
Web Services behaviors (5)

• Ten behavior examples
• Availability and Reliability
• Performance
• Management
• Failure
• Security
• Privacy, confidentiality and integrity
• Scalability
• Execution
• Internationalization
• Synchronization
• Lets focus on a few of these behaviors

Source Advertising Service Properties,
unpublished paper by C. Hobbs, J. Bell, P. Sanchez
17
Availability and Reliability

• Availability is the percentage of client
  requests to which the server responds within the
  time it advertised.
• Reliability is the percentage of such server
  responses which return the correct answer.
• In some applications availability is more
  important than reliability
• Many protocols used within the Internet, for
  example, are self-correcting and an occasional
  wrong answer is unimportant. The failure to give
  any answer, however, can cause a major network
  upheaval.

18
Availability and Reliability (2)

• In other applications reliability is more
  important than availability
• If the service which calculates a persons annual
  tax return does not respond occasionally its not
  a major problem - the user can try again
• If that service does respond but with the wrong
  answer which is submitted to the tax authorities,
  then it could be disastrous

19
Availability and Reliability (3)

• Services are built with either availability or
  reliability in mind, with clients accepting that
  no service can ever be 100 available or 100
  reliable.
• In combining services X and Y into a composite
  service Z, it is necessary to combine the
  underlying availability and reliability models
  and predict Zs model.
• To do so without manual intervention, Xs and Ys
  models must be exposed.

20
Availability and Reliability (4)

• Availability and reliability models are often
  expressed as Markov Models or Petri Nets, which
  are easy to combine in a hierarchical way.
• Major issues
• Agreeing upon the semantics of the states in the
  Markov model or places in the Petri nets
• Finding a way for X and Y to publish the models
  in a standard form.

21
Availability and Reliability (5)

• Currently, apart from raw percentage figures,
  there is no method for describing these models
• Percentage time when the server is unavailable?
• Percentage of requests to which it does not
  reply?
• Different clients may experience these
  differently
• A server which is unavailable from 0000 to 0400
  every day can be 100 available to a client that
  only tries to access it in the afternoons.

22
Availability and Reliability (6)

• If X and Y are distributed, then it is possible,
  following network failures, that for some
  customers, Z can access X but not Y and for
  others Y but not X.
• The assessment of Zs availability may be hard to
  quantify, so it may be difficult for Z to offer a
  meaningful WSLA.

23
Failure

• The failure models of X and Y may be very
  different
• X fails cleanly and may, because of its
  idempotency, immediately be called again
• Y has more complex failure modes
• Z will add its own failure modes to those of X
  and Y
• Predicting the outcome could be very difficult
• The complexity is increased because many
  developers do not understand failure modeling
  and, even were models to be published, their
  combination would be difficult due to their
  stochastic nature.

24
Failure (2)

• One approach to describing a services failure
  model
• Service publishes the exceptions that it can
  raise and associates the required consumer
  behavior with each
• Exception D may be thrown when the database is
  locked by another process. Required action is to
  try again after a random backoff period of not
  less than 34ms.
• Crash-only failure model is a simple starting
  point for building a taxonomy of failure
  behavior. This work is just beginning.

25
Scalability

• A behavioral description and WSLA for the
  composite service Z must include its scalability
• How many simultaneous service instances can it
  support?
• What service request rate does it handle? etc.
• These parameters will almost certainly differ
  between the component services X and Y, and will
  need to be published by those services.
• X and Y are presumably not dedicated solely to Z,
  so the actual load being applied to X and Y at
  any given time is unknown to the provider of Z,
  making the scalability of Z even harder to
  determine.

26
Web Services behaviors (again)

• Ten behavior examples
• Availability and Reliability
• Performance
• Management
• Failure
• Security
• Privacy, confidentiality and integrity
• Scalability
• Execution
• Internationalization
• Synchronization
• We described a few of these behaviors
• Can we use them to build WSLAs?

27
Web Service Level Agreement (WSLA)

• Based on behaviors and descriptors for these
  behaviors.
• Example Failure model
• Is transaction half-performed?
• Is it re-wound?
• These behaviors and descriptors are not available
  in the WS description, in WSDL
• No performance info
• Not even price!

28
Web Service Level Agreements (2)

• Business acceptance of composed services for
  business-critical operations depends on a service
  providers ability to offer WSLA
• Uptime, response time, etc.
• Offering an WSLA depends on ability to compose
  the WSLA-related behaviors of the individual
  services
• This information needs to be available via WSDL
  or similar source
• Should include test vectors to test the SLA
  claims
• The ability to determine and offer a WSLA
  commitment is a limiting factor for orchestration

29
Web Service Level Agreements (3)

• Need a more precise way to express the parameters
  of behaviors
• Availability What is 99.97 uptime?
• Several milliseconds outage each minute?
• Several minutes planned downtime each month?
• Failure model Crash-only as the simplest,
  lowest layer or level of failure in a future full
  failure model.
• Eight other SLA-related behaviors listed here
  each has a complex semantic for description and
  composition

30
www.oasis-open.org

• 1100 AM 1230 PM
• SLA
• Service Contracts
• Cross domain services
• Non Functional Properties of Services
• Tracking/ Auditing Charge Back

31
Non Functional Properties (NFP) of Services

• OMG RFI
• Use of distributed services in different contexts
  by different stakeholders who dont have control
  over these services, raises some challenges with
  respect to the ability to predict the behavior of
  the resulting composite service and associated
  Service Level Agreements (SLAs) without resorting
  to tight binding to the underlying services

32
What is a Service?

• A mechanism to enable access to one or more
  capabilities provided by an entity (the service
  provider) for use by others
• Services are opaque ie only information required
  by service consumers is exposed

33
What are non-functional properties of a service

• Non-functional Properties are a subset of the
  service description that specifies behavior that
  does not relate to the purpose of the service.
  Non-functional Properties of a service include -
  among others - response time, cost, availability,
  reliability, security, and scalability.
  Consumers of these services can establish
  selection criteria to select (or search for) a
  service with the desired NFP (or NFPs).
• Service composition is the main target for NFP
  RFI
• In OMG RFI
• Service Level Agreement (SLA)
• The Service Provider may guarantee the Service
  Consumer a certain level of service in return for
  a specified payment. An SLA specifies negotiated
  and mutually agreed upon service level
  commitments including the conditions of the
  outsourcing service to be provided, quality of
  service, how this quality is measured, and what
  happens if the service quality is not met.
  Typically, an SLA addresses both the functional
  and non-functional aspects (aka NFPs) of the
  service to be provided.

34
RFI Key Questions

• Provide, by order of significance, a list of
  NFPs, such as reliability and scalability, which
  you think are relevant to domains such as Telecom
  mission critical applications, etc.
• For each NFP identified as part of question 1,
  please answer the following questions
• Do you have a formal representation of this NFP?
  If yes, please describe it.
• How do you express a composite services NFP in
  terms of the aggregated NFPs of each service from
  which it is composed?
• How do you measure (or monitor) the composite
  services NFP to ensure compliance with its
  service contract?
• Describe the benefits of standardizing some of
  the above mentioned solutions. Are any of them
  proprietary? Open Source? Other?
• What published standards (from W3C, OASIS, TMF,
  etc.) do you think should be taken into
  consideration to represent, aggregate, measure or
  monitor this NFP?
• Identify the NFP related modeling approaches you
  use to support service operations including
  discovery, access, and execution.
• Identify the NFP related modeling approaches you
  use to support proper handling (i.e., definition,
  representation, aggregation, etc.) of a services
  NFP.
• Are there any available tools (commercial, open
  source, in-house) that you use to formally
  represent, compose, and monitor these NFPs? For
  each of the tools, indicate what NFPs you think
  are well treated and what kind of support is
  provided for each (i.e., presentation,
  composition, and monitoring)
• What other issues/questions about non-functional
  properties need to be addressed? Please describe
  in full including supporting rationale.

35
(No Transcript)