95-843 Service Oriented
Architecture
Governance and Service Level
Agreements
95-843 SOA Notes from InfoWorld 2007
Video on SOA Governance
SOA Governance
• Definition from CMU’s SEI
“SOA governance defines the set of policies,
rules and enforcement mechanisms for
developing, using, and evolving service
oriented systems and for analyzing their
business value.”
From SEI Report SLA's in SOA Environments
SOA Governance
• Definition from IBM:
“SOA governance is an extension of IT
governance, which is an extension of corporate
governance.
SOA Governance exercises control of the lifecycle
of services and composite applications in an
organizations SOA”
From IBM's Web Site on SOA Governance
SOA Governance: Key points
• SOA is about the sharing of services.
• Services must be created and used according to
rules that all of the stake holders can follow.
• Collections of rules are known as policies.
• SOA Governance is about the development and
management of policies.
• Collaborative processes produce and manage
policies.
• This collaborative process may be disruptive.
95-843 SOA Notes from InfoWorld 2007
Video on SOA Governance
SOA Governance
• Is meant to resolve issues including:
- which services should be created?
- how should they be created?
- who should have access to these services?
- how will the services be provisioned?
From SEI's report on SLAs
Policies
• Classified into:
(1) Design time policies and
(2) Run time policies
95-843 SOA Notes from InfoWorld 2007
Video on SOA Governance
Design Time Policies
• Rules for developers
- Interoperability framework
Require interoperable protocols be used by
services
- Provide incentives to developers
for building proper services and by actually
using existing services rather than ignoring
them.
95-843 SOA Notes from InfoWorld 2007
Video on SOA Governance
Run Time Policies
• Lay out the details of service contracts:
Security
Expected Service Levels
Restrictions on service use – authorization
decisions
May be enforced by runtime components
95-843 SOA Notes from InfoWorld 2007
Video on SOA Governance
Governance Software
• An SOA Registry – lists services and service locations.
• An SOA Repository – points to the runtime and design
time policy information associate with services.
• Oracle offers SOA Governance 11g
• Oracle Web Service Manager can be accessed via the
Enterprise Manager. These policies may be created and
deployed to the OSB.
• EM or OSB may also be used to monitor usage.
• All without changing the service.
95-843 SOA Notes from InfoWorld 2007
Video on SOA Governance
Ownership
• Every service has a clearly specified owner.
• Disputes will arise over what functionality the
service will provide.
• These disputes must be resolved.
• Part of SOA governance is to provide a forum
and a means for dispute resolution.
95-843 SOA Notes from InfoWorld 2007
Video on SOA Governance
Collaboration
• One key to a successful SOA implementation is
government through collaboration.
• Policies must be developed, maintained and
modified by committee and not by decree.
• People on the ground must have real input.
• Policy changes must be distributed and
feedback must be solicited.
• SOA Governance requires the right processes
and culture
95-843 SOA Notes from InfoWorld 2007
Video on SOA Governance
Service Level Agreements
• An architect selects services based on desired
functional characteristics.
• But the architect must also consider non-functional
qualities of service such as
availability, reliability, performance, security, and price.
• An SLA spells out who is responsible for what.
• SLAs have been used in IT for years. The definition of
SLAs for SOA based environments is more recent.
• SOAs may cross organizational boundaries.
• May be a simple text document or may be machine
readable XML.
Notes from SEI Service Level Agreements in
SOA Environments
SLA’s Describe:
• How delivery of the service at the specified level of
quality will become realized.
• Which metrics will be collected.
• Who will collect the metrics and how.
• Actions to be taken when the service is not delivered at
the specified level of quality and who is responsible for
doing them.
• Penalties for failure to deliver the service at the
specified level of quality.
• How and when the SLA will evolve as technology
changes (perhaps new technologies are expected to
reduce end-to-end latency).
Notes from SEI Service Level Agreements in
SOA Environments
Also May Be Defined in SLA’s
•
•
•
•
•
•
Latency.
Number of transaction handled per unit of time.
Cost per invocation.
Length of time the service will be supported.
Error rate of service.
Availability
- Length of time to recover from failure
- Uptime
- Scalability
• Non-repudiation, confidentiality, integrity, auditing,
authentication, authorization, encryption
Notes from SEI Service Level Agreements in
SOA Environments
Why Machine Readable SLA’s Would
Be Cool
• Automatic negotiation between consumers and
producers.
• Tooling could be built that sends notifications when
deviations occur.
• A billing system could calculate charges based on the
SLA in effect.
• An automated SLA management system that measures
and monitors the the quality parameters would use an
SLA as input.
• Still an area of research. See WS-Agreement at Open
Grid Forum.
• See WS-Policy at W3C.
Notes from SEI Service Level Agreements in
SOA Environments
Service user side
Service User
Instrumentation
Metrics
Service provider side
Service call
Service Provider
Instrumentation
Figure 1:
Conceptual Architecture
For SLA Monitoring and
Management
Metrics
Key:
Measuremen
t
Subsystem
Measurement
Subsystem
component
data
Values of SLA
parameters
Evaluation
Procedure
events or
action requests
Action handler
Values of SLA
parameters
Evaluation
Procedure
events of
Action requests
Action handler
Adapted from the work of Ludwig and
colleagues [Ludwig 2003]
Delimits
scope of
service user
or provider
Data flow
Component
interaction