SLA-Aware Enterprise Service Computing

SLA-Aware Enterprise Service
Computing

Longji Tang, PhD in CSSE
longji.tang@fedex.com

Agenda
 Introducing Myself
 Challenges of Enterprise Service Computing
 SLA-Aware Enterprise Service Computing
 SLA-Aware SOAP Web Service Architectural

Style
 Can REST Web Service be SLA-Aware?

 Conclusion

September 19, 2012 2

Introducing Myself
 My name is Longji Tang, PhD in Software
Engineering, I graduated from Computer
Science of University of Texas Dallas, 2011.
 My PhD dissertation title is
“Modeling and Analyzing Enterprise Service-Oriented
Architectural Styles” http://gradworks.umi.com/3494567.pdf

 Currently, I am a Sr. Technical Advisor in FedEx
IT. I have been working in IT industry since 1995
as developer, architect, project manager of
FedEx.com data center move project.


Agenda

Style

 Conclusion


Challenges of Enterprise Service Computing

http://www.windowsitpro.com/blog/
tony-redmonds-exchange-unwashed-50/office/
cloud-outages-reinforce-careful-assessment-slas-negotiated-140241 http://money.cnn.com/2011/04/21/technology/
amazon_server_outage/index.htm

http://news.cnet.com/8301-1023_3-57415281-93/gmail-users-experience-outage/


Challenges of Enterprise Cloud Service
Computing

http://www.informationweek.com/security/attacks/anonymous-hacks-wal-mart-capitalone-finl/231902602


Challenges of Enterprise Service Computing

In the Fig. we’ve displayed
in order of fastest average
performance across the
globe, the top ranked
service provider sites. This
representation only includes
provider sites we’ve been
testing for 6 months or
longer, eliminating dispersal
and I hope… yielding the
most honest display of
response times across the
best of the best.
by CloudSleuth, 2011

https://cloudsleuth.net/blog/cloud-provider-global-performance-ranking-%e2%80%93-12-month-average


Challenges of Enterprise Service Computing –
Facing the Facts
Outages: Security Threads: Latency:
 04/21/2011 – Amazon  2010 – the  2010 - Cloudkick - one of
East Data Center Anonymous group the many outfits that
EC2 outage which successfully crashed offer a service for
caused many web Mastercard.com and overseeing the use of
sites down strained the websites Amazon EC2 and other
 08/07/2011 – Amazon of Visa and PayPal. so-called compute clouds
Dublin Data Center  Dropbox could indeed - first noticed an Amazon
Power outage see the contents of latency spike around
 Google Email files, putting users at Christmas time, and the
outages risk of government problem has grown
searches, rogue steadily over the past
 08/17/2011 - few weeks.
Microsoft Office365 Dropbox employees,
outage which and even companies  Aberdeen's report -
impacted its CRM trying to bring mass application performance
customers copyright-infringement could impact overall
suits. corporate revenues by
up to 9%.


What are the risks moving to cloud?

The figures are from dynaTrace presentation in 2011 Cloud Expo

• Projects fail to deliver acceptable performance
• Service consumers’ business is impacted


Agenda
SLA-Aware SOAP Web Service
Style
Style

 Conclusion


SLA-Aware Enterprise Service Computing

 What are SLA and SLA-Aware?
 Why SLA?
 SOAP-Based SLA-Aware ESC
 REST-Based SLA-Aware ESC


 Service Level Agreement is a negotiable QoS
contract between service consumer (SC) and
service provider (SP) on the service
guarantees for service consumers. The
guarantees include the operations that need
to be executed and the promised QoS that
should be provided. Formally, we define SLA
as
SLA= SLA (SC, SP, C(QoS)),
such as Amazon’s EC2 Service Level Agreement (http://aws.amazon.com/ec2-sla/).


 SLA-Awareness is a capacity and design
principle to guarantee QoS provided by
services. It uses dynamic SLA binding in a
service computing system environment to
achieve its goal. The capacity and quality of
an SLA-Aware service computing system is
controlled by dynamic SLAs and managed by
dynamic SLM.

such as SOA@SOI SLA-Aware Web Service Infrastructure


 Benefits of Adopting SLA and SLA-
Awareness in Enterprise Service Computing
 Service providers can delivery better services with
higher quality, since SLA is the design constrain.
 Service providers can gain higher reputation and
increase ROI and reduce failure penalty.
 Service consumers can get the service value from
what they pay.
 Service consumers can get guarantee (include
service violation benefit) from SP.
 Both SP and SC can get dynamic and real-time
high-assurance service from SLA-Awareness.

Dynamic SLA vs. Static SLA

Vertical SLA vs. Horizontal SLA



SLA-Aware QoS Taxonomy

SLA-Aware QoS Class

Performance Depedability Security Cost & Payment

· Response time · Availability · Security · Cost
· Latency · Accuracy · Trust · Penalty
· Round trip time · Robustness · Reputation · Service credit
· Scalability · Reliable message
· Throughput · Error rate
· Transaction rate
· Connect time


SLA-Aware SOAP Web Service Architectural Style
 Framework, Standard and Language
 Web Service Level Agreement (WSLA) : a specification and
reference implementation proposed by IBM.
 WS-Agreement: a specification from the Open Grid Forum (OGF)
which provides an agreement protocol between service
consumers and service providers.
 WS-Policy and WS-Policy Attachment: specifications of service
qualities which are part of SLA developed by the World Wide
Web Consortium (W3C).
 SLAng: an XML language for defining SLA which is a part of the
contracts between web service clients and web services.
 Web Service Offering Language (WSOL): a formal XML language
compatible with the Web Services Description Language
(WSDL).



 SLA-Aware Architectural Style
 SLA-Aware Web Services
 SLA-Aware Web Service Consumers
 SLA-Aware SOA Data
 SLA-Aware SOA Infrastructure
 SLA-Aware SOA Management
 SLA-Aware SOA Process
 SLA-Aware Quality Attributes


Service Discovery
SLA Dashboard

Find Service Register
registry

Workstation
Customer
SLA-Aware Service Consumer SLA-Aware Service Provider

Negotiating
Client-Side SLA Management
Offering Service Level Management
or Service Level Mamagement

Gathering Gathering
Request service Claim QoS Provisioning SLA monitoring
data data

Service Delivery
Cluster

SLA-Aware Business Application
invocating SLA-Aware Web Service
or SLA-Aware Web service

SLA Monitoring

Monitoring Data Monitoring

Agents
servers


SOAP-Based We Service SLA-Aware ESC
Cloud

Cloud
Workstation
Laptops

On-demand
SLA-Aware Dynamic Data Center requests
Enterprise Services Delivery Network Business Applications
Delivery Network

invoke
Public Cloud Private Cloud Other
Serices Services Services Business Applications

ne
Virtualized Infrastructure Provisioning Services ot g
SOA Management
ia
te

ri n g
Service SLA Provisioning Service Policy

nito
monitoring
Orchestration provision SLA Other

mo
Services Virtualization Management Managements
Utility Handler
Controller

o rt

ch
g

at
re p
ri n

w
ito
Dynamic Virtualized Infrastructure Monitoring

on
m
Virtual Virtual Virtual
Servers Storages Network monitoring

g
itorin
mo n
Physical Resources
Physical
Resource
Management


Enterprise Application
(travel reservation, call center, ….)

SLA
SLMi SLAi
Monitoring

Service Consumer Interface
Service Provider Interface

Enterprsie Services
(search, ticket negotiation, billing, …)

SLA
SLMj SLAj
Monitoring

Internal Service Delivery Network Service
(IP, Ethernet, SAN)

SLA
SLMk SLAk
Monitoring

External Service Delivery Network Service
(ATM, SDH, Dark Fiber)


SLA-Aware Travel
SLA-Aware
Reservation
Client
workflow
SLA01 SLA2,IaaS1
s1
SLA12
Workstation Cloud
Book airline
s2 service
IaaS1

· S1 is a travel booking service
· S2 is a airline booking service s3
· S3 is a rental car booking service
· S4 is a data service SLA13 SLA3,IaaS2

s4 BPEL
Cloud
Book car
Engine service
IaaS2
SLA4,IaaS3
Storage
Infrastructure

Data


Agenda

Style
Can REST
 Conclusion


Can REST Web Service be SLA-Aware?
REST-WS SOAP-WS
 Unified interfaces  Flexible interfaces with POST
GET/PUT/POST/DELETE  Transport agnostic
 Mostly HTTP Transport  Comparatively higher
 Lightly bandwidth bandwidth
 QoS support – based on  Wide array of message level
transport QoS options – WS-*
 Complexity - lower  Complexity - higher
 Communication Overhead –  Communication Overhead –
high higher
 Response is cacheable by  Not cacheable, you have to
client, server or proxy use server-side cache tech
 Suited for lightweight scenario  Suited for heavyweight
scenario


Can REST Web Service be SLA-Aware?
 Dynamic SLA or SLA-Aware depends on many
Technologies:
 Standards, Languages and Tools

 Machine Readable Service QoS Description

 Service Monitoring

 Service Level Management (SLM)

 SOAP-WS is comparatively mature and more supported in
all technologies above.
 REST-WS lacks all mature technologies above and is less
supported as well as immature in them.
 Adding complicated dynamic SLA or SLA-Aware system to
REST-WS architecture is not necessary, since it will violate
the simplicity of REST-WS. However finding a lightweight
way to do dynamic SLA for REST-WS is critical for
enterprises.

Standards, Languages and Tools
 WDSL 2.0 – Recommended by W3C, 2007
 Provided formal way to describe REST Web Service
 Potentially to define QoS – features and properties
 Could not describe “content negotiation” – not SLA-Aware
 WADL (Web Application Description Language) – W3C
Member Submission, 2009
 a XML-based description language for HTTP-based Web applications,
such as applications which follow the REST architectural style
 WADL is not yet widely supported. It has the advantage over the more
complicated WSDL in that it does not impose any further level of
abstraction on the service description; however, as tools become
available for application development with WADL, it is likely they will
include ways of automatically generating WADL, and this risks imposing
an RPC style on it, going against the intended simplicity of REST.
 Google REST API Compile and Google REST Describer based on
WADL, 2007 by Thomas Steiner


Context, Quality and Relevance of REST-
WS
 Context – conditions for the service usage
 Quality – QoS (response time, availability, ….)
 Relevance of service outcome – a service
outcome (representation) is considered relevant
when the provided results match the service
consumer (customer)’s need.
 Specifying context and quality in JSON
 Describing context and quality in WADL
“Context, Quality and Relevance: Dependencies and
Impacts on RESTful Web Services Design”, by Hong-Linh Truong, et al.


Context, Quality and Relevance of REST-
WS

QoS in JSON

QoS in WADL

“Context, Quality and Relevance: Dependencies and
Impacts on RESTful Web Services Design”, by Hong-Linh Truong, et al.


Monitoring Technology for REST-WS SLA
Metrics of SALMon Architecture of SALMon

SALMon: A SOA System for Monitoring Service Level
Agreements, by Marc Oriol, Xavier Franch, Jordi Marco


Monitoring Technology for REST-WS SLA

Amazon CloudWatch Developer Guide RightScale Dynamic Monitoring
Technology


Content Negotiation of REST-WS
 The service consumer and service provider of WS-* style web
services can negotiate QoS or SLA through WS-Agreement. The
question is if REST service consumer and REST services can
negotiate QoS. Roy Fielding presented “Content Negotiation” of
REST in his PhD thesis. “If the value set of a resource at a given
time consists of multiple representations, content negotiation may be
used to select the best representation for inclusion in a given
message.” I think Content negotiation can be regarded as one of
dynamic SLA for REST-WS.
 Content negotiation is a mechanism defined in the HTTP
specification that makes it possible to serve different versions of a
document (or more generally, a resource representation) at the
same URI, so that user agents can specify which version fit their
capabilities the best. (sort of QoS)
 In the new book “SOA with REST, the “Content Negotiation” is
defined as a REST design pattern


Content Negotiation of REST-WS
 Content negotiation is one of the core concepts of
RESTful systems where a client can indicate which
media type(s) it prefers. Also within the media types it
can specify the order of preference. Client does this by
using Accept header. For example, consider the
following Accept header – (negotiated by content types)
Accept: application/xml;q=0.8, application/json;q=0.9
It indicates to the server a) it can accept XML and JSON formats
and b) it prefers JSON over XML (by providing higher value for 'q'
parameter. q value ranges from 0.0 to 1.0, higher value indicates
more preference). Another more complex example:


From WS-Agreement to REST-Agreement
 WS-Agreement describes an XML schema for specifying service level
agreement (SLA) and a simple protocol that describes how parties can
communicate to build an agreement among them.
 WS-Agreement (Open Grid Forum or OGF) is one of tech standards for
building dynamic SLA or SLA-Awareness in SOAP-WS systems.
 Roland Kubert, et al, proposed a REST-Agreement:
 Identifying resources – Template, list of templates, agreement, list of agreements, agreement
state
 Describing on resource representations by XML
 Defining URIs:
 /rest-agreement/templates (GET)
 /rest-agreement/templates /search{query} (GET)
 /rest-agreement/template/{id} (GET)
 /rest-agreement/agreements (POST)
 /rest-agreement/agreement/{id} (GET)
 /rest-agreement/agreement/{id}/state (GET)
 Validating templates, offers and agreements – to ensure the correctness of an SLA instance,
the validation includes:
 Every SLA instance is in XML format.
 Every SLA template or SLA is an instance of the REST-Agreement XSD.
 Handling state
 Encode state in URIs or
 Store state in a persistent storage and encode a reference to the state in the URIs.


Does the REST-Agreement violated REST constraint?
 “We next add a constraint to the client-server interaction:
communication must be stateless in nature, as in the client-
stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that
each request from client to server must contain all of the information
necessary to understand the request, and cannot take advantage of
any stored context on the server. Session state is therefore kept
entirely on the client.”
“This constraint induces the properties of visibility, reliability, and
scalability.” -- Chapter 5 of Roy Fielding PhD Thesis
 REST-Agreement Proposed by Roland needs to keep agreement
state on the server-side. It slightly violates REST “stateless”
constraint.
 To satisfy some of enterprise requirements or needs from cloud
computing, such as dynamic SLA management, negotiation feature
between service consumers and service providers, I do think we
need to relaxing some of REST constraints. It is a design tradeoff.
You sacrifice certain scalability, but you get REST SLA feature.
September 19, 2012 The University of Texas at Dallas 34

Agenda

Style

 Conclusion


Conclusion
 Introduced SLA-Aware Enterprise Service
Computing
 Presented SLA-Aware SOAP-WS
Architectural Style
 Discussed Potential Approach of Dynamic
SLA for REST-WS
 Finding lightweight way to make RESTful
web service QoS-Aware & SLA-Aware is
important to enterprise service computing.


References
 Longji Tang, Modeling and Analyzing Enterprise
Service-Oriented Architectural Styles, PhD
Thesis, UTD, 2011
 Roy Fielding, Architectural Styles and the Design
of Network-based Software Architectures, PhD
Thesis, University of California, Irvine, 2000.
 Raj Balasubramanian, Benjamin Carlyle , Thomas
Erl , Cesare Pautasso,Herbjörn Wilhelmsen and
David Booth, SOA with REST: Principles,
Patterns & Constraints for Building RESTful
Enterprise Solutions, Prentice Hall, 2012.


Thank You!


SLA-Aware Enterprise Service Computing

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (6)

SLA-Aware Enterprise Service Computing