The document discusses service-oriented architecture (SOA) and provides definitions and explanations of key SOA concepts and terminology. It describes SOA as breaking applications into reusable services and requiring analysis to identify business processes and data that can be exposed as services. It also notes that SOA promises increased business agility by making it possible to assemble components in new ways in response to changing business needs.

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

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:// www.serviceorientation.org http://www.ibm.com/developerworks/rational/library/07/1002_amsden/ http://blogs.ittoolbox.com/eai/business/archives/soa-design-template-23289 http://www.ibm.com/developerworks/db2/library/techarticle/dm-0803sauter2/ http://blogs.msdn.com/nickmalik/archive/2005/10/07/478230.aspx http://www.statcan.ca/english/conferences/it2007/