• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Services Orientated Architecture – What is a Service? “ Anybody can build a service. The challenge is to build a good service, based on solid design principles”
  • 2. Think Change What seems like only a ripple today... Can become the wave of the future
  • 4. What is a Service?
    • “ A service is a discrete unit of business functionality that is made available through a service contract . The service contract specifies all interactions between the service consumer and service provider. This includes:
        • Service interface
          • Specifies the service operations, i.e. What the service does
        • Interface documents
        • Service Policies
          • Ensuring service governance
        • Quality of service (QoS)
          • Service Life Cycle is Managed through a Service Level Agreement (SLA)
        • Performance
          • Service Life Cycle is Managed through a Service Level Agreement (SLA)
  • 5. Aspects of a Service
    • Service Interface Layer
      • Customer Facing – and what the service does
      • Defines the style and details of the service interactions
    • Service Implementation Layer
      • How the service provides the capabilities of its interface
      • Hidden from the service consumer
    Service Contract Service Service Policies Service Level Agreement Interface Implementation Service Operations Semantic Business Objects Internal Functionality Internal Data
  • 6. Types of Information utilised
    • Semantic Data
    • Described by a common/shared information model.
    • A view of the common aspects of services.
    • Used for information exchange through interfaces.
    • Domain Data
    • Described by an internal data model.
    • A view of the physical data.
    • Used for implementation
    • Physical Data
    • Described by a database schema.
    • Used for persistence
    Semantic Business Data Specific Common Specific Common
  • 7. Service Characteristics
    • Modularity and granularity
      • Business processes are decomposed into modular services that are self-contained.
      • Granularity is a quality of functional richness for a service.
    • Encapsulation
      • Services exhibit a strict separation of the service interface (what a service does) from the service implementation (how it is done).
    • Loose coupling
      • Coupling describes the number of dependencies between a service consumer and provider.
    • Isolation of responsibilities
      • Services are responsible for discrete tasks or the management of specific resources.
    • Autonomy
      • Autonomy is the characteristic that allows services to be deployed, modified, and maintained independently from each other and the solutions that use them.
    • Governed by policy
      • Relationships between service consumers and providers (and between services and service domains) are governed by policies and service level agreements (SLAs).
    • Reuse
      • Together, modularity, encapsulation, loose coupling, isolation of responsibilities, and autonomy enable services to be combined into multiple business processes or accessed by multiple service consumers from multiple locations and in multiple contexts.
    • Dynamic discovery and binding
      • Services can be discovered at design time through the use of a design-time service repository.
    • Stateless
      • Service operations are stateless. This means that they neither remember the last thing they were asked to do nor care what the next is.
    • Self-describing
      • The service contract provides a complete description of the service interface, its operations, the input and output parameters, and schema.
    • Composable
      • Services can be composed from other services and, in turn, can be combined with other services to compose new services or business processes.
    • Independent of location, language, and protocol
      • Services are designed to be location-transparent and protocol/platform-independent.
  • 8. Service Hierarchy Enterprise Business Process Business Service Business Service Domain Service Domain Service Domain Service External Service Integration Service Foundation Service Layer (May be used by all other Services)
  • 9. Service Dimensions Scope Scope defines the organizational boundaries that a service is expected to operate in. For example, a service with an enterprise scope is expected to be used by processes or other services across the entire enterprise (i.e., other LOBs). At the opposite end of the scale is a service that is used by only a single application or organizational group. Granularity Granularity describes the size of a service in terms of the amount of business function that is performed in a single request/response exchange of messages. Ownership Ownership defines the organizational unit that is responsible for support of a service. This extends well beyond simple maintenance and operations to the overall life cycle of the service Construction Construction refers to how the service has been implemented. The service may essentially be a service wrapper around some existing function or data in a legacy or COTS application. We call this an integration service. Large Small Granularity Composite Wrapper Construction Enterprise Application Scope Central Individual Organisation Ownership Service
  • 10. Common Service Patterns A B Business Components Business Service Service Interface Orchestration Domain Service Utility Service Foundation Service
  • 11. Common Service Patterns (Enterprise Business Process) Packaged Application Business Service Service Interface Orchestration Domain Service Utility Service Foundation Service A B Business Components Enterprise Business Process Business Service Integration Service Business Service Business Process Orchestration
  • 12. Service Types and Purpose
    • Task services
      • Services that implement a business function, such as a service that calculates the price of an insurance quote or validates the format of an address. Task services come in all different sizes, ranging from discrete utility services to large business services. Smaller services tend to be more general in purpose and provide a higher potential for reuse. Business services are often large compositions of smaller services and may be designed to support one or more specific process.
    • Entity Services
      • Services that primarily manage access to business entities. Examples of business entities are customers, policies, claims, and so on. They correspond to major business information concepts. Entities are usually medium to large in size. Entities tend to be independent of any particular business process and instead are part of multiple different business processes.
    • Decision Services
      • Services that execute business rules to provide business decisions. An example of a decision service is Approve Creditworthiness. Decision services generally provide yes/no answers to complex questions, or support frequently changing externalized rules such as tax regulations. Decision services are usually composed into other services and are small to medium in size
    The combination of these different service types provide flexible business capabilities that support the activities of a business process. Business Processes Process Services Services Decision Services Entity Services Integration Services Enterprise Services Task Task Task Decision Decision Entity Entity Entity IS IS IS Data Data
  • 14. Enterprise Perspective of SOA Define Defines communication technology for application integration Specifies Service wrapping techniques Specifies definition and requirements of a service Defines tools, processes, and technology for combining services into EBP Defines common semantics and data Enterprise Business Process Business Model Service Integration Service Common Semantics and Data Process Guidelines and Tools Service Bus
  • 15. Enterprise Architecture and SOA Enterprise Architecture Business Architecture Application Architecture Data Architecture Technology Architecture Service Orientated Architecture Integration Services Data Service Common Semantics and Data Service Bus Enterprise Business Process Business Model
  • 16. Sources of Reference
    • “ Service Orientated Architecture and Design Strategies “, M.Rosen, B.Lobinsky, K.T.Smith, M.J.Blacer, Wiley Publishing Inc., ISBN: 978-0-470-22365-9, 2008
  • 17. If you have one last breath use it to say...