This document discusses key concepts of service-oriented architecture (SOA), including common service delivery approaches, SOA concepts, and key SOA elements. It also covers SOA processes, principles, services, service contracts, and the technical and business benefits of implementing an SOA.

1. UNIT – II
SERVICE ORIENTED ARCHITECTURE

2. Service-oriented business and government
• Bank
• Travel agency
• Insurance agency
• Retail store
• Lawyer's office
• Hospital
• Department of transportation
• Department of human services
• Police department

3. Three most common approaches to service
delivery
• Human- mediated delivery
• Self-service delivery
• System-to-system service delivery

4. Service oriented architecture concepts
• A style of design that guides all aspects of creating and using business
services.
• To help align IT capabilities with business goals.
• To provide an agile technical infrastructure that can be quickly and
easily reconfigured.
• Processes, principles and methods -> service

5. Using SOA to align business and information
technology

6. Key elements of a service-oriented
architecture

7. SOA Processes, Principles and Tools
• SOA changes over time, processes, principles and tools need to be put
in place to facilitate its evolution and growth.

8. Services
• IT assets that correspond to real-world business activities or
recognizable business functions.
• Its policies define
• who/what is authorized to access the service
• When the service is available
• Cost of using the service
• Reliability levels for the service
• Security levels for the service
• Performance levels for the service
• Course-grained, reusable IT assets
• Consists of one or more operations

9. Services
• Service-level abstractions –
• Focuses on issues of SOA
• Deal exclusively with services
• Define all the important elements of the services.
• Row represents
• Column represents cross cutting concerns
• Key service-level abstractions:
• Service-level interface definitions
• Service-level data model
• Service-level interaction model
• Service-level security model
• Service-level management model

10. • Service-level abstractions – can be applied to a single operation
• SOA scales up to deal with more and more services
• Line of business services:
• This layer provides business services that automate the business services that
the organization delivers to its customers, clients, citizens and partners either
directly or indirectly.
• Tend to be specific to a particular service domain
• Services from different service domains will have inconsistent

11. Reusable technical services:
• Defines services that are not specific to a single line of business
• Reusable across multiple lines of business
• Permits organizations to separate the business logic from a lot of the
infrastructure functionality.
Service contracts:
• Well-defined interface
• Separates the service’s externally accessible interface from the
service’s technical implementation
• Allows us to formalize : system and scope boundaries, minimize
dependencies, maximize adaptability, use black box testing, select
among services and more easily change service suppliers.

12. Web services platform:
• Defines the stds and run-time facilities available to all services
• Key elements:
• XML and XML Schema
• SOAP , HTTP
• WSDL
• UDDI
• WS-Security
• WS-ReliableMessaging and WS-Eventing
• WS-Transactions
• WSDM
• Extended web services standards : XBRL, FIXML, LDAP and RDF
• Every organization should explicitly define its own profile of the web
services platform and a roadmap

13. Service requesters and service providers
• Service provider – s/w module that implements a service according to
the service contract
• Service requester – s/w module that invokes a service implemented
by a service provider to accomplish some task.

14. Approved products, technologies and
facilities
• After defining web services platform, it must identify the internal
facilities.
• High degree of coupling
• Some capabilities may be available as both technical services and
internal facilities.

15. Service governance, processes, guidelines,
principles, methods and tools
• To align s/w governance and business governance
• Recognizes that services are corporate assets
• Basic questions:
• Why
• Who
• What
• How
• When

16. • Define and implement:
• Service lifecycle processes
• SOA decision making and issue resolution process
• SOA design and development process
• Monitoring business performance
• Monitoring technical performance
• Ensuring web service standards
• Define the policies and processes for identifying, implementing,
deploying and versioning services.
• Identify mandatory and optional training
• Identify the tools

17. SOA principles and guidelines
1. Services
2. Formal contract
3. Interact
4. Accessible
5. Level of abstraction
6. Meaningful
7. Loosely coupled
8. Collection of related services
9. Discrete tasks and interfaces
10. metadata

18. Key service characteristics
Primary characteristics:
• Loosely coupled service
• Interface coupling
• Technology coupling
• Process coupling
• Well-defined service contracts
• Meaningful to service requesters
• Open Standards- based

19. Secondary characteristics
• Predictable service-level agreements
• Dynamic, discoverable, metadata-driven
• Design service contracts with related services in mind
• Implementation independent of other services
• Consider the need for compensating transactions
• Design for multiple invocation styles
• Design stateless services
• Design services with performance in mind

20. Service proxy:
• Easy-to-use interface
• Encapsulate the details of the SOAP binding
• Configuration data
Legacy service:
• Do not allow the underlying middleware to spoil your interface by
exposing middleware specific APIs
• Hide protocol and encoding dependencies
• Do not expose middleware-specific data types or structures
• Do not expose middleware-specific error codes
• Hide component models

21. Technical benefits
• Efficient development
• More reuse
• Simplified maintenance
• Increment adoption
• Graceful evolution

22. More reuse
• Meaningful to the service requester
• Well-defined service contracts published in a service repository
• Dynamic, discoverable, metadata-driven
• Loose process coupling
• Loose technology coupling
• Open, standard based
• Predictable service-level agreements
• Design for multiple invocation styles
• Design service contracts with related services in mind

23. Business benefits
• Increased business agility
• Agility in terms of finding the right service
• Agility in terms of changing service providers
• Agility in terms of quickly assembling services into applications
• Agility in terms of supporting new services requesters and new delivery
• Agility in terms of dynamically adjusting capacity to meet increased business
demands
• Agility in terms of using an existing service to support new and unforeseen business
requirement
• Better business alignment
• Improved customer satisfaction
• Improved ROI of existing IT assets
• Reduced integration costs
• Reduced vendor lock-in and switching costs