1 / 16

Seminar on Service Oriented Architecture

Seminar on Service Oriented Architecture. Governance and Service Level Agreements. SOA Governance. Definition from CMU’s SEI

cole
Download Presentation

Seminar on Service Oriented Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Seminar on Service Oriented Architecture Governance and Service Level Agreements SOA Seminar Notes from InfoWorld 2007 Video on SOA Governance

  2. 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

  3. 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

  4. SOA Governance • 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. SOA Seminar Notes from InfoWorld 2007 Video on SOA Governance

  5. 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

  6. Policies • Classified into: (1) Design time policies and (2) Run time policies SOA Seminar Notes from InfoWorld 2007 Video on SOA Governance

  7. Design Time Policies • Rules for developers Interoperability framework Stipulates protocols of services Works by providing incentives to developers for building proper services and by actually using existing services rather than ignoring them. SOA Seminar Notes from InfoWorld 2007 Video on SOA Governance

  8. Run Time Policies • Lay out the details of service contracts: Security Expected Service Levels Restrictions on service use May be enforced by runtime components SOA Seminar Notes from InfoWorld 2007 Video on SOA Governance

  9. 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 • HP offers SOA Systinet • See IBM and Microsoft as well. SOA Seminar Notes from InfoWorld 2007 Video on SOA Governance

  10. 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. SOA Seminar Notes from InfoWorld 2007 Video on SOA Governance

  11. 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 SOA Seminar Notes from InfoWorld 2007 Video on SOA Governance

  12. 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

  13. SLA’sDescribe: • 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

  14. Also May Be Defined in SLAs • 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

  15. 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

  16. Service user side Service provider side Figure 1: Conceptual Architecture For SLA Monitoring and Management Service call Service User Service Provider Instrumentation Instrumentation Metrics Metrics Key: component Measurement Subsystem Measurement Subsystem data Values of SLA parameters Values of SLA parameters Delimits scope of service user or provider Evaluation Procedure Evaluation Procedure events of Action requests events or action requests Data flow Component interaction Action handler Action handler Adapted from the work of Ludwig and colleagues [Ludwig 2003]

More Related