Your SlideShare is downloading. ×
Service Analysis And Design
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Service Analysis And Design


Published on

Presentation given at the minor EAD, ICA, HAN University based on the book from Thomas Erl

Presentation given at the minor EAD, ICA, HAN University based on the book from Thomas Erl

1 Like
  • Be the first to comment

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
  • Transcript

    • 1. Service Analysis & Design
    • 2. What is SOA?
      • A departure from packaged, monolithic applications.
      • Breaks applications into service provider and service consumer roles.
      • Requires analysis to identify and break down business processes, sub-processes, activities, tasks, and data into reusable component services.
      • Service providers and consumers can connect within the same enterprise or across the Internet.
      • Grand vision is for SOAs everywhere – within enterprises, vendor solutions, “ecosphere” partners.
      • SOAs are made possible by well-supported interface standards – especially Web services standards.
    • 3. Why SOA?
      • SOA often is justified on cost savings, but its lasting value is in increased business agility:
      • SOA’s goal is to make business agility intrinsic to the systems architecture.
      • Promises enterprises the ability to “snap together” components in response to business change.
      • SOA also is a response to today’s highly distributed business environment:
      • The concept of an "application" now extends beyond an enterprise and beyond the scope of single provider.
      • Demand for services anytime, anywhere, through any device creates need for flexible, reusable services.
    • 4. Terminology
      • Service-Oriented Linguistics
      • “ Service-Oriented Architecture”
      • “ Service-Orientation”
      • “ Service” vs. “Web Service”
      • “ Service Composition”
      • “ Service Inventory”
      • “ Service-Oriented Computing Platform”
    • 5. The Service-Oriented Computing Platform
    • 6. SOA and Service-Orientation
      • SOA is an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing.
      • Service-orientation is a design paradigm comprised of design principles that shape solution logic into services with distinct design characteristics that support the realization of strategic goals associated with service-oriented computing.
    • 7. Service-Orientation
      • Introducing "Service Orientation"
      • What is a "Service" ?
        • Some functional block that deals with data
        • Location, Platform, Code shall be irrelevant
      • Implications
        • Location: Assume remote use
        • Platform: Assume cross-platform use
        • Code: Ignore service's inner implementation
    • 8. What is a Service
      • Service Contract
        • The service contract specifies the purpose, functionality, constraints, and usage of a service. The contract is defined by the business in business terms.
      • Service Interface
        • A Service interface provides a means for the users of a service to access its functionality according to the contract it offers. A given service may offer multiple interfaces to allow consumption of the service through different means.
      • Service Implementation
        • The implementation part of a service is the actual code. The implementation may be accomplished using any technology. Implementations, especially early ones, often represent functionality that already exists in an enterprise.
    • 9. Services & Operations
      • Service: collection of related operations that a component implements
      • Operation: set of messages exchanged between service user and provider
    • 10. Service examples
      • Base Infrastructure
        • Transport, Authentication, Authorization, Transactions, etc.
      • Monitoring and Operations
        • Statistics & performance tracking, Configuration services, Provisioning
      • Business Services
        • Order Process Integration, Logistics Tracking, Mobile Data Collection in Manufacturing, …
    • 11. Assumptions to Avoid
      • Don't think of a "Service" as …
        • Transactions, Objects, Functions
          • These are platform/tool terms
        • Synchronous or Asynchronous
          • These are contract terms
        • Stateless or Stateful
          • Statelessness doesn't exist at runtime, anyway
        • The actual invocation target
          • Intermediate services may be invoked
    • 12. Basic Terminology
      • Message
        • Data exchanged between services
        • Not Objects. Code doesn't travel
      • Context / Session
        • Defines scope of action, conversation
        • Clothes-line for state and infrastructure
      • Destinations
        • Target service or service class.
        • Logical destination, not "http://somewhere/"
    • 13. Service-Orientation Principles
      • Common principles:
        • service s use a standardized contract
        • services are loosely coupled
        • services abstract underlying logic
        • services are autonomous
        • services are reusable
        • services are composable
        • services maximize statelessness
        • services are discoverable
    • 14. Services are Autonomous
    • 15. X
    • 16.  
    • 17. SOA Service Lifecycle Design, Development and Deploy Business Operations Service Architect Business Analyst Service Development Business Activity Monitoring Business Process Modeling Core Metadata Service Develop and Deploy Management Monitoring Service Modeling
    • 18. What Is a Business Process?
      • A set of activities and tasks performed by resources
        • Humans and machines
      • using a variety of information
        • Documents, images, expertise, evidence
      • interacting in various ways
        • Sequential (predictable) and ad hoc
      • guided by corporate mission, goals and policies
        • KPI correlation, business rules, scenarios
      • to produce an optimal work outcome
      Just as the dance is not the dancer, the process should not be confused with the "resources" performing the process
    • 19.
      • BPM is a management practice that provides for governance of a business process environment toward the goal of improving agility and operational performance.
      • BPM is a structured approach employing methods, policies, metrics , management practices and software tools to manage and continuously optimize an organization's activities and processes.
      What Is Business Process Management? Architecture Graphic source: Casewise/Gartner presentation, 2005 People Technology Process
    • 20. SOA is Business Driven Product inquiry SOA – A Service Invocation Framework Product inquiry Business World Processes IT World Services Reserve inventory Reserve inventory Schedule shipment Schedule shipment Create Customer Order Create customer order Schedule production Schedule production Create Supplier order Create supplier order
    • 21. Business, Technology Model for SOA Potential Reuse
    • 22. Service Modeling Services That Map To Real Business Processes, Not As Silo-ed Apps
      • Think strategically, execute tactically: start with a single core process
      • Top down: identify the services required to support this single core process
      • Bottom up: identify functions in existing systems that could be exposed as services to support this process
      • Infrastructure services: identify common supporting functionality requirements
      Orchestrate services into processes Measure alignment with strategy Identify opportunities for optimization Analyze processes Identify supporting functionality required Harvest functionality from existing IT assets Develop new functionality Develop contracts and package as services 3 1 2 Services are mapped to business processes, and enable business process improvement over time Business Strategy & Process
    • 23. Service Modeling Shared Services Business Process Services ? ? ? ? ? ? ? ? ? ? Service Modeling What services should be created? What is the process for identifying these services? What are the characteristics that identify these services? Applications Partners & Suppliers People Data Sources Infrastructure Services Service Enablement System Access Human Access Data Access Shared Service Access Presentation Services Applications Partners & Suppliers People Data Sources Composite Applications Integration Services Orchestration Data
    • 24. Wrap up: Analysis Concepts
      • Business logic is decomposed into preliminary service operation candidates.
      • Operation candidates are grouped into logical contexts that represent conceptual services called service candidates.
      • Service candidates are organized into an enterprise service model.
      • Relate service candidates to the concepts/data the use or depend on.
    • 25. Wrap up: Design Concepts
      • Services are based on a set of pre-defined service models:
        • process services (orchestration)
        • business services (task or entity centric)
        • application services (applications, utilities, infrastructure)
      • Service models can have a functional context that is business or non-business centric.
      • The standardized use of service models establishes service abstraction layers.
    • 26. Service Models and Layers
      • Services can be organized into abstraction layers based on common service models.
      • We won’t use the business process layer
        • Mostly orchestrated (BizTalk, BPEL, etc.)
      Process services Business services Application services
    • 27. High Level Service Design
      • What is the responsibility of the service?
      • What rules does the service own?
      • What style of EAI are you implementing?
        • RPC
        • Messaging
      • Is the service itempotent?
      • What preconditions and postconditions apply to this service?
      • What actors may use this service and how will they be authenticated?
      • What data elements will be required in order to call the service?
      • What data elements will be returned by the service in its acknowledgement / receipt / return?
    • 28. Idempotence
      • Idempotent Means It’s OK to Arrive Multiple Times
        • As Long as the Request Is Processed at Least Once, the Correct Stuff Occurs
      • In Today’s Internet, You Must Design Your Requests to Be Idempotent
      Not Idempotent Baking a Cake Starting from Ingredients Naturally Idempotent Sweeping the Floor Naturally Idempotent Read Record “X” Idempotent If Haven’t Yet Done Withdrawal #XYZ for $1 Billion, Then Withdraw $1 Billion and Label as #XYZ Not Idempotent Withdrawing $1 Billion Idempotent Baking a Cake Starting from the Shopping List (If Money Doesn’t Matter)
    • 29. Formalize Service Contract
      • What message format will the service use? Typical answers here include SOAP, Proprietary XML, and various RPC mechanisms.
      • What protocol will the caller use to communicate with the service? Typical answers here include HTTP and various RPC protocols.
      • What level of availability should the caller expect for the service? Will the service be available 24x7? Whats the service level agreement that the hosting team is willing to sign up for?
      • What is the expected interaction on the part of the caller when the service is not available? Should he call again later? Try again right away? Discard the call? Return an error to the calling system?
      • If the service call is part of an expected sequence of service calls, define the sequence. This may include call-back mechanisms. Note that call-back mechanisms require the reflected service to be as well defined as the initial service, using all of the rules described here.
      • What latency should the caller expect for the synchronous return from the service call? (In messaging systems, this is the time that the caller should expect to wait for the acknowledgement or receipt.)
    • 30. Resources
        • http://