Service-Oriented Architecture: Analysis, the Keys to Success!

Transcription

1 Service-Oriented Architecture: Analysis, the Keys to Success! Presented by: William F. Nazzaro CTO, Inc.

2 Introduction Service-Oriented Architecture is hot, but we seem to be asking less technical questions once we embark. Such as, What makes a good service? How do I determine if my service should be a high-level business process Should it be a low-level technical function? Are there any techniques that can help me identify the services I should expose? Service-Oriented Architecture is predicated on web services and web services provide defined functionality to be exposed for consumption. A common mistake is designing web services that provide too narrow functionality. But business process modeling, business use cases and system use cases were developed precisely to capture a meaningful business service available to a requestor just like a web service. This presentation will demonstrate how to leverage business process modeling and use case techniques to describe meaningful business process and how use case modeling concepts may be used to define and refine valuable business web services rather than the obvious low-level methods. Page 2

3 What We ll Cover SOA, Hype or Reality? Is This Really New? Types of SOA Adoption Why This Is A Challenge SOA Vocabulary Elements of SOA Breaking Down Barriers BPM, EA and OOAD Positioning SO A&D Business Strategy and Process» Business Vision View» Business Process View Building Blocks (i.e., Services) Service Identification SOA Analysis Techniques» Business Process Modeling» Use Case Modeling» Service Responsibility Card (SRC) Page 3

4 SOA, Hype or Reality? It offers organizations the ability to act or respond quickly / efficiently to changing business requirements thereby enabling Business Agility, the flexibility acquired from the plug-n-play nature of services Competitive Advantage the modularity and pay-per-use natures of services It s considered and piloted because it supports Distributed Heterogeneous Environment» Loosely coupled business applications» Interoperability of distributed and disparate systems Plug-n-Play Integration» Ease of extensibility and scalability via modularity» Flexibility to focus on end-user needs Dynamic Information Exchange/ Management» Via asynchronous messaging / communication Use of Industry Standard Technologies» XML, J2EE,.NET» Existing middleware technologies are reusable Service Oriented Architecture offers you a business reason to perform and support ongoing enterprise-wide Web integration effectively For enterprise-level integration teams, SOA is A positive step forward from traditional middleware (CORBA) or RPC-based application integration A widely accepted and supported concept across the Industry» Embraced equally by Microsoft and non- Microsoft school of thoughts» Provides a contract between developers and user community to integrate applications efficiently improving ROI and cost of ownership A few XML-based standards driven notion example - SOAP, UDDI, and WSDL Is This Really New? Page 4

5 Is This Really New? I view SOA as an Evolution and not a Revolution, that has evolved From client server to brokers Lessons learned during this period Goal: Intensive Computing Goal: e-business Or E-Commerce Multi-tier / Web Enablement (components) Goal: Business Flexibility / Reuse Service Orientation (services) Goal: Business Automation Client / Server (objects) Mainframe (monolithic) 1970s 1980s 1980s 1990s 1990s 2000s 2000s beyond Page 5

6 Types Of SOA Adoption SOA adoption will initially be driven by one or more desired capabilities: Application development (new software projects) Legacy enablement / enterprise integration (EAI replacement) Client integration (packaged software vendors) Collaboration (DOD and Federal Government) Service Delivery (top down business adoption) Initial goals, benefits and concerns are different, depending on the drivers: Application development» Delivered application functionality on time and on budget Legacy enablement / enterprise integration» Concentrates on integrating disparate or duplicate systems and extending the life of existing legacy applications Client integration» Driven by clients requirements for functionality or data at the edge of the application. Collaboration» Long term initiative with primary concerns in semantics and governance Service Delivery (IT as a service) A fully mature Service Oriented Enterprise will contain all of these capabilities Page 6

7 Why This Is A Challenge A typical enterprise might include IT elements such as: ERP, SCM, or CRM packages Legacy mainframe Cobol Systems / Legacy Database Systems Stand alone, client-server, 3-tier, n-tier, and web systems New development in Java/J2EE and Microsoft technologies Data warehouse Partner and/or client interfaces Each of these elements presents different SOA adoption challenges You can no longer build applications within an IT silo. All service oriented applications are Enterprise Applications. You have to decide, will the service interfaces you expose reside: Inside the business unit Inside the enterprise Outside the enterprise Page 7

8 SOA Vocabulary 1 Service: Represents business functionality that is well defined, self contained and may be accessed through clearly defined interfaces. A service is something that a business person should recognize and understand. Service Oriented Architecture: An approach that treats software resources as services and an architecture that promotes a set of IT best practices for an organization / enterprise Software systems are architected to provide services to end-user applications or other services through discoverable interfaces. Services may be:» Accessed by other applications/services» Composed of other services» Interoperable and transparent Elements of SOA Page 8

9 Elements of SOA Service Provider: Provides capabilities or services to other business applications, components or services Publishes its capability or service with a registry (Service Broker) so other Service Consumer(s) may find / discover it Service Consumer: Requests and uses services from Service Provider(s) Searches and locates a capability or service from a registry (Service Broker) and binds with the Service Provider using a contract and interface Service Broker: Registers services from Service Providers Helps locate services for Service Consumers Publishes Service Service Provider Service Broker Service Request Service Response Search / Finds Service Service Consumer Page 9

10 SOA Vocabulary 2 Enterprise Service Bus (ESB) connects all participants of an SOA via interfaces, embraces a variety of technologies and enables multiple communication modes. Additional the Enterprise Service Bus: Offers transport to services» When a service request arrives an appropriate transport protocol is selected and supported» Service is routed to appropriate service provider with necessary quality of service (QoS) Mediates intelligent processing of service requests or responses» Mediation is primarily directed towards message validation, transformation, routing, and monitoring Acts as a gateway for services» Controls access to services and hides details of services, validates user access, and audits requests to services service service service Interface Security Service Messaging Service Other Common Services A Simplified Enterprise Service Bus Page 10

11 SOA Vocabulary 3 Web Service: A functional element or business component (a collection; reusable) accessed over the Internet using XML and HTTP Primary features of a Web Service:» Platform and language independence, building blocks for open distributed systems» Browser independence, can be accessed using browsers, but do not require a browser or HTML» Data independence, offers a mechanism to expose business services without affecting their data Web Services add the following characteristics to an SOA Invocation of a service over the Web» Sending a request and receiving a response» Can be synchronous or asynchronous» Needs A transport type to transfer the data (example- HTTP) A payload format to define the format of the data (example- XML) Interoperability with other business applications or components» Must be invoked by a client using the service» Can be a remote method or a procedure call, middleware, database access or adapters Discovery or locating service across a network» Looking up a service dynamically that matches client s need» Must have Service information such as location and parameters to invoke the service Standards and Standardization Committees (See Appendix) Page 11

12 Breaking Down The Barriers One of the problems blocking SOA adoption in companies is that when the architects and developers start talking in jargon, they lose the business executives and managers in the blur of XML, WSDL, SOAP and UDDI. * The basic principle is, making SOA understandable, making it something that business and IT own together so that when you have a business strategy, it's linked directly to IT. It's a balance of the technical and non-technical approaches that makes SOA successful," ** BEA Approaches Organizing SOA Projects into six domains Business Focus» Business Strategy and Process"» Costs and Benefits,"» Organization and Governance" IT Focus» Architecture,"» Building Blocks" (i.e. Services)» Projects and Applications" * Rich Seely, SearchWebServices.com ** David Growes, BEA Systems Page 12

13 Example: Automotive Work Order Problem Statement / Scenario Adapted from: IBM Developerworks, Elements of Service Oriented Analysis and Design, Olaf Zimmermann, Pal Krogdahl, Clive Gee Page 13

14 BPM, EA and OOAD Positioning Our Focus Shifts To Adapted from: IBM Developerworks, Elements of Service Oriented Analysis and Design, Olaf Zimmermann, Pal Krogdahl, Clive Gee Page 14

15 SO A&D: Business Strategy and Process Business Vision View Business Vision Document Business Vision View Techniques Example Class Diagram Business Process View Example Business Process View Examples Business Process Model Page 15

16 The Business Vision View Reveals the overall vision of the business Describes a goal structure for the business Illustrates problems that must be solved in order to reach those goals Identifies strategies to be undertaken to solve the problems Documented via a Business Vision document Business Vision Document High-level document, not detailed Basic strategy for moving forward Summarizes business to motivate employees and stakeholders This artifact isn t new, but it s critical for successful SOA deployments? Business Vision drives a set of Business Architecture Requirements (People, Process, Partners, Goods, Markets, Customers) and then organize into a TOWS matrix Don t just think SOA, think:» Agility» Compliance» Merger & Acquisition» Software as a Service» Etc Business Vision Document Page 16

17 The Business Vision View: Techniques Strategy Definition Position of the company with regard to current and future world Reveal the strategic goals and needed changes for the business Use a TOWS Matrix to model» (Threats, Opportunities, Weaknesses, Strengths) Conceptual Modeling Definitions of the important concepts used in the business Identifies relationships between the concepts Use class diagrams to model concepts Goal/Problem Modeling Definition of the goals for the company Breaks high-level abstract goals into measurable sub-goals that are achievable by a business process Problems that obstruct goal achievement are revealed Use object diagrams to model Goal/Problem relationships Page 17

18 Example: Automotive Work Order Class Diagram to Model Concepts Adapted from: IBM Developerworks, Elements of Service Oriented Analysis and Design, Olaf Zimmermann, Pal Krogdahl, Clive Gee Page 18

19 The Business Process View The Business Process View reveals the business processes with which a business achieves its goals All processes collectively attempt to achieve the overall goals of the business The processes show The activities that must be undertaken to achieve an explicit goal, Along with their relationships to the resources that participate in the process The process definitions are used to Understand the business See threats or opportunities to the business Improve or innovate the business Act as the context for process automation systems Page 19

20 Example: Automotive Work Order Business Process Model Adapted from: IBM Developerworks, Elements of Service Oriented Analysis and Design, Olaf Zimmermann, Pal Krogdahl, Clive Gee Page 20

21 Example: Automotive Work Order Initial Use Case Diagram and Use Case Steps Create Work Order Get Customer & Vehicle Info Catalog Application Customer Application Create Work Order Create Work Order Get Auto Service Options Service Rep Inventory System List Required Parts & Supplies Check Inventory Levels Work Order System Scheduling ERP Reserve Low Inventory Level Parts Schedule Appointment Reserve All Parts Save Work Order Page 21

22 SO A&D: Building Blocks (i.e., Services) Events Events Events Manual Business Area Organization Automated Automated System Automated Manual Business Area Business Area Manual Events Events If we are describing a business area we will describe the interactions which occur within that workflow. But if our interest is in how a software system serves its users, our scope narrows considerably. Events In SO A&D we actually need to consider both views, but we should work from the outside-in Determine the business interactions and our needs to support them Determine the software system interactions required to support the business interactions Adapted from: Evanetics & Nazzaro, Use Case Modeling Course Page 22

23 Example: Automotive Work Order Revised Use Case Diagram and Use Case Steps Create Work Order Get Customer & Vehicle Info Catalog Application Customer Application Create Work Order Dealership Create Work Order Get Auto Service Options Service Rep Inventory System Parts Supplier List Required Parts & Supplies Customer Check Inventory Levels Work Order System Scheduling ERP Reserve Low Inventory Level Parts Schedule Appointment Reserve All Parts Save Work Order Page 23

24 Example: Automotive Work Order Initial Service List Customer Service The Customer Service manages contact and automobile information for each customer Catalog Service The Catalog Service provides maintenance offerings for any automobile, and specifies parts, supplies and labor Work Order Service The Work Order Service tracks the progression of a single instance of servicing a single automobile Inventory Service The Inventory Service provides the quantity on hand for any needed items and facilitates the ordering of any items not on hand Scheduling Service The Scheduling Service identifies the next available date and time that corresponds to the required Duration, Mechanic Type and Bay Type Guidance: think coarse grained services, not CRUD Page 24

25 Service Responsibility Card (SRC) Services, Operation and I/O Determine the operations required for each service For each identified operation,» Name the operation Leverage the Service Responsibility Card (SRC) Determine the inputs/outputs for each operation For each named operation» Determine any input data required by the operation» Determine any output data provided by the operation Assume no collaboration with other services Page 25

26 Example: Automotive Work Order Service Responsibility Card (SRC) Service Name: Customer Service Description: The Customer Service manages contact and automobile information for each customer Service Responsibilities: Operation: Input Data: Output Data: Lookup Customer By Telephone Number Telephone Number Customer And Vehicle Info Operation: Input Data: Output Data: Create Customer Customer Info None Operation: Input Data: Output Data: Create Vehicle Vehicle Info, Telephone Number None Page 26

27 Example: Automotive Work Order Service Responsibility Card (SRC) Service Name: Catalog Service Description: The Catalog Service provides maintenance offerings for any automobile, and specifies parts, supplies and labor Service Responsibilities: Operation: Input Data: Output Data: List Maintenance Auto Make and Model Maintenance Code and Description Of Possible Offerings Operation: Input Data: Output Data: List Parts Supplies and Labor Maintenance Code List Of Parts, Supplies And Labor Operation: Input Data: Output Data: Page 27

28 Example: Automotive Work Order Service Responsibility Card (SRC) Service Name: Work Order Service Description: The Work Order Service tracks the progression of a single instance of servicing a single automobile Service Responsibilities: Operation: Input Data: Output Data: Create Work Order None Work Order Number Operation: Input Data: Output Data: Update and Save Work Order and Calculate New Cost Complete Work Order Information Cost Operation: Input Data: Output Data: Delete Work Order Work Order Number None Page 28

29 Example: Automotive Work Order Service Responsibility Card (SRC) Service Name: Inventory Service Description: The Inventory Service provides the quantity on hand for any needed items and facilitates the ordering of any items not on hand Service Responsibilities: Operation: Input Data: Output Data: Determine Quantity on Hand of Item(s) Item Number(s) Number On Hand, Reserved, and On Back Order for Each Item Operation: Input Data: Output Data: Reserve Item(s) Work Order Number and Parts List Back Order and Arrival Info by Part Operation: Input Data: Output Data: Return Item(s) Work Order Number None Page 29

30 Example: Automotive Work Order Service Responsibility Card (SRC) Service Name: Scheduling Service Description: The Scheduling Service identifies the next available date and time that corresponds to the required Duration, Mechanic Type and Bay Type Service Responsibilities: Operation: Input Data: Output Data: Schedule Skilled Mechanic and Service Bay Duration, Mechanic Type, and Bay Type Start Date and Time, Mechanic Name and Bay Number Operation: Input Data: Output Data: Operation: Input Data: Output Data: Page 30

31 Example: Automotive Work Order Sequence Diagram: Partial Business Process Model Page 31

32 Example: Automotive Work Order Sequence Diagram: Partial Business Process Model Page 32

33 Next Steps Page 33

34 In this new world, it's not design the business and then design the technology, you're creating one thing, which is your business as embodied in your technology base. * * Randy Heffner, Forrester Research Inc.

35 Service-Oriented Architecture: Analysis, the Keys to Success! Presented by: William F. Nazzaro CTO, Inc.

36 Appendix Additional Material

37 Standards and Standardization Committees Core Standards SOAP (Simple Object Access Protocol) Formats the message in a Web service Supports all three aspects of a Web service XML (Extensible Markup Language) WSDL (Web Services Description Language) Describes a Web service UDDI (Universal Description, Discovery, and Integration) Registers and publishes a Web service HTTP (HyperText Transfer Protocol) Carries the message of a Web service over the Internet Other Relevant Standards BPEL WS Reliable Messaging SAML and SSML WSCI Major Standardization Committees W3C OASIS WS-I Liberty Alliance Page 37

38 SOA and Web Services The Connection Service Broker Discovery / lookup Protocol Publishes Service Service Provider UDDI Communication Protocol Service Request SOAP Service Response Finds Service Service Consumer WSDL WSDL Service Interfaces Page 38