Service-Oriented Architecture (SOA)

Transcription

1 Service-Oriented Architecture (SOA) Marlon Dumas 27 November / 56 Context: Bridging IT & Business Value Closer communication between business & IT sharing common concepts and models Shift from programming in the small to programming in the large with emphasis on: Integration Adaptation Configuration Functions, Procedures Modules Objects Components Services 2/ 56

2 What is SOA? Purpose SOA is a paradigm for organizing and utilizing distributed resources and capabilities that may be under the control of different ownership domains.» OASIS SOA eference Model SOA does not imply technology, but it can help to structure how technology is deployed and organised. 3/ 56 What is SOA? From a Software Engineering Perspective SOA is a structure for a system consisting of a collection of software services. So what s a software service? A software asset that is deployed at an endpoint and is continuously maintained by a provider for use by one or multiple clients. Services have explicit contracts that establish their purpose and how they should be used. Software services are (supposed to be) reusable. 4/ 56

3 SOA Principles Abstraction Services share standards and contracts and nothing else! Autonomy (loose-coupling) Minimize dependencies between services and make dependencies explicit Services have owners! eusability Services are intended to be reused and composed. 5/ 56 Components of a SOA (Simplistic View) Front-end Applications App-1 App-1 App-2 App-2 App-N App-N Service Bus Services Service-1 Service-2 Service-M Service Description epository 6/ 56

4 The Service Bus Connects services, front-ends and repositories in an SOA It is not a software product (even though some vendors would like to sell it as such!): Needs to support a variety of technologies & communication modes Needs to be cross administrative domains 7/ 56 Types of Service Application Application front-end front-end Basic Basic service service Intermediary Intermediary service service Process Process centric centric service service Although they are not services themselves are the active Elements of a SOA. They initiate all business processes and ultimately receive their results. Are the foundation of the SOA. They represent the basic elements of the vertical domain. Include both data centric and logic centric services. Include technology gateways, adapters, facades and functionality-adding services. Are both client and server in a SOA. Unlike process-centric services they are stateless. Encapsulate the knowledge of the organization s processes. Typically both client and server in a SOA, and maintain the process state. Public Public enterprise enterprise service service Provide interfaces for cross-enterprise integration. Thus they are of coarser granularity and have appropriate mechanisms for eg decoupling, security, billing or robustness. 8/ 56

5 Data-Centric Services Handle persistent data. Abstracts: Storage and retrieval of data. Locking mechanisms. Transaction management. Similar to the data access layer of a traditional application architectures. But: Traditional data access layer manages all data for the entire application (horizontal slicing). A data centric service only deals with one major business entity (vertical slicing). 9/ 56 Data-Centric Services A data-centric service should strictly encapsulate its data entities. Any other service that requires access to this data needs to use the service interface of the corresponding data-centric service. Customer Customer service service Itinerary Itinerary service service Customer DB Customer service Interface: CustomerManager Interface: ItineraryManager Customer DB a) Poor design: ownership of data unclear b) Customer DB owned by customer service 10 / 56

6 Designing Data-Centric Services One of the most important tasks of an SOA architect is to identify relevant business entities that should be represented by datacentric services. Similar to traditional business domain modelling. Can use methods based on E models or OO design, but cross service relationships are not allowed (as no cross-service navigation exists as in distributed object technology). This means that complex data types used by services must be sufficiently self contained or must contain unique identifiers that enable them to relate to other complex data values. 11 / 56 Encapsulating Data and Behaviour Data-centric services should not only encapsulate access to the underlying persistent data, but also encapsulate logic and behaviour inherent to that data. Similar benefits to object-orientation, but doesn t require OO language. This should not however include business process logic or business (policy) rules which are likely to change more rapidly. 12 / 56

7 Logic-Centric Services Encapsulate algorithms for complex calculations or business rules (e.g. insurance pricing service) Stateless and functional in nature. 13 / 56 Intermediary Services Stateless mediators that bridge technological inconsistencies or design gaps in an architecture. Still provide a business oriented API. Include: Technology Gateways Adapters Facades Functionality-Adding Service 14 / 56

8 Process-Centric Services Encapsulate an organization s business processes. Process logic is separated from application logic. They control and encapsulate the state of business processes. Business processes may be long lived (eg months). The interaction between the client and provider may be arbitrarily complex i.e. not limited to simple request/response patterns however, patterns of interaction are normally known in advance and governed by a contract or formal understanding of what will be provided and under what conditions. 15 / 56 SOA & Business Process Management System Silos Integrated Systems 16 / 56

9 Public Enterprise Services Services that an enterprise offers to partners (B2B) and customers (B2C). These services have specific requirements: Interfaces at the enterprise have the granularity of self-contained business documents. Decouple business partners using asynchronous communication Crossing the organization s borders implies higher security requirements, e.g. authentication, encryption and access control. Billing for cross-enterprise services implies need for nonrepudiation. egulated by Service Level Agreements. 17 / 56 SmartEDA: Integrated Land Development Application System 18 / 56

10 Danske Bank: Customer Package Process Steen Brahe, 2007 Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Introduction of Customer packages. Word template to collect info 19 / 56 Danske Bank: Customer Package Process Customer Create Card Create Account Advisor Backoffice workers Create Credit Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Backoffice group created Handles the creation process 20 / 56

11 Danske Bank: Customer Package Process Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Case Transfer System Automatic validation and transfering 21 / 56 Danske Bank: Customer Package Process Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Workflow enabled creation process v. 1 Automatic process control, 0% automated activities 22 / 56

12 Danske Bank: Customer Package Process Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Workflow v. 6 80% automated activities 23 / 56 Lifecycle and oles in an SOA Developer Solution Architect Service & Process Design Service & Process Implementation Tester Service & Process Analysis Testing & Deployment Business Analyst Opportunity & Issue Identification Operation & Monitoring Administrator 24 / 56

13 Service Analysis and Design Service Analysis: identification and definition of the business services that an organization provides or consumes, internally or externally. Service Design: definition of a set of technical services to support the delivery of business services through IT. Service Analysis & Design Methods Top-down capability-driven method Bottom-up process-driven method Thomas Erl: Service-Oriented Architecture, Concepts, Technology, and Design, Prentice Hall, 2005 Hybrid methods www-128.ibm.com/developerworks/webservices/library/ws-soad1 25 / 56 Top-down Service Analysis Pharmaceutical company Pharmak has a natural medicines business unit comprising four main areas: Sales: contacts customer receives order from customer checks stock requests for an order to be shipped - if item(s) on the order are available Manufacture: makes item(s) requests for an order to be shipped - after manufacturing the item(s) Logistics & Warehouse: adds new item(s) into stock requests an external company, or internal logistics, to deliver an order to a customer receives supplies from suppliers 26 / 56

14 Top-down Service Analysis Finance: prepares bill for customer orders raw materials from suppliers receives invoice from suppliers prepares invoice for customer The organization interacts with the following partners: Customer: organization which buys, and potentially sells on, jars Suppliers: manufacturers or wholesalers of components/raw materials needed to make jars Logistics Provider: used when the standard supply chain cannot cope with local demand, or to supply to global markets 27 / 56 Top-down Service Analysis Level 0 Architecture What Customer Who Why Logistics Company Suppliers 28 / 56

15 Top-down Service Analysis Level 1 Architecture We reason in terms of capabilities (what can each area do?) Service analysis is carried out according to each Level 0 element identified before, Decomposition: the enclosing service confers behavior and management onto those at a lower level: As a rule of thumb, a maximum of 8 Level 1 services for each Level 0, with a normal amount around / 56 Top-down Service Analysis Level 1 Architecture: Manufacture Supply Stock What esearch & Development Supplies In Verify Supplies Quality Control Verify Who Send For Approval Manufacture Test Product Test Final Product egulatory Approval Product Manufacture Finish Packaging Manage Approval equest new supplies equest Stock / Add Stock equest Stock / Add Stock Why Order Supplies Stock Management egulator External 30 / 56

16 Top-down Service Analysis Level 2+ Architecture Drilling down from Level 0 into lower abstraction level elements is a series of repetitions of the same steps. Purposes: 1. to delve deeper and understand the problem domain more, 2. to identify: Virtual Services Support Services Shared Services 31 / 56 Top-down Service Analysis The Service Map 32 / 56

17 Top-down Service SOA Design Phase Customer Logistics Company Suppliers 33 / 56 Top-down Service Design Services involved: Sales: Order Management: Make Quote Process Order Order Cancel Order Check Availability Check Stock equest Shipment Ship Order equest Bill Bill Customer Logistics & Warehouse: Stock Availability: Provide Availability Check Stock Warehouse Management: Stock Out Ship Order Deliver 34 / 56

18 Top-down Service Design Finance: Customer Management: Make Bill Bill Customer Services involved in the Customer: equest Quote Place Order Order Cancel Order 35 / 56 Top-down Service Design Let s refine the interactions and define the roles: Stock Availability Check Stock warehouse Warehouse Management Ship Order Order Management sales equest Quote Make Order Cancel Order Customer customer Deliver Bill Customer Customer Management finance 36 / 56

19 Top-down Service Design 37 / 56 Bottom-up Process-driven Service Analysis Business Process Models can be used as the source which to identify services: a thorough knowledge of the underlying workflow logic is required, the scope of the identified services may vary: process service process step sub-process service service 38 / 56

20 Bottom-up Process-driven Service Analysis After loosing its unique client TLS, ailco Ltd. needs to find new customers. This leads the company to build a standardized set of services, generic enough to facilitate interactions with multiple clients. To pursue this goal, ailco Ltd. decides to overhaul its existing environment in favor of an SOA. The service analysis is conducted over two internal business processes, pitched to work with the B2B solution of TLS: - Submission Process: sends an invoice to TLS, uses the Submission Web Service. - Order Fulfillment Process: accepts and processes Purchase Orders from TLS, uses the Order Fulfillment Web Service. 39 / 56 Bottom-up Process-driven Service Analysis Start Submission Order Fulfillment Create and Issue Export Transform Start eceive PO Validate Validate PO invoice valid? no PO valid? yes no time for metadata check? yes yes Check Metadata Tranform PO Send Notification no Import PO Metadata valid? yes no Send PO to Queue Submit Stop Stop 40 / 56

21 Bottom-up Process-driven Service Analysis Applying the framework: Step 3 - Model candidate services Model candidate services Decompose business process Identify operation candidates Abstract orchestration logic Create service candidates efine and apply service-orientation Identify service compositions evise operation grouping Analyze processing requirements Identify application service operations Create application service candidates evise service compositions evise operation grouping 41 / 56 Bottom-up Process-driven Service Analysis 1 Decompose the business process Break down the workflow logic in the most granular representation of process steps. Submission Process Create electronic invoice, Issue electronic invoice, Export electronic invoice to network folder, Poll network folder, etrieve electronic invoice, Transform electronic invoice to XML document, Check validity of invoice document. If valid, end, Check if it is time to verify TLS metadata, If required, perform metadata check. If the check fails, end. invoice valid? time for metadata check? Create and Issue Export Transform Validate no Start yes Submit no yes Metadata valid? Check Metadata yes no Stop 42 / 56

22 Bottom-up Process-driven Service Analysis 2 Identify business service operation candidates Some steps can be easily identified as not belonging to the potential logic to be encapsulated in a service candidate (e.g. activities performed manually or by some legacy logic). Submission Process Create electronic invoice, Manual step (accounting clerk) Issue electronic invoice, Manual step (accounting clerk) Export electronic invoice to network folder, Custom developed component (legacy logic) Poll network folder, Performed by a custom developed component etrieve electronic invoice, Performed by a custom developed component Transform electronic invoice to XML document, Performed by a custom developed component Check validity of invoice document. If valid, end, Performed by the Submission WS Check if it is time to verify TLS metadata, Performed by the Submission WS If required, perform metadata check. Performed by the Submission WS If the check fails, end. Could become part of a generic service candidate. Could become a separate service candidate. 43 / 56 Bottom-up Process-driven Service Analysis 3 Abstract orchestration logic Identify the parts of the processing logic that this layer would potentially abstract (e.g. business rules, conditional / exception / sequence logic). The workflow logic of separate process service candidates, derived from the Submission and Order Fulfillment processes would include the following conditions: if the invoice document is valid, proceed with the metadata check, else, end process, if the interval period for performing a metadata check has completed, perform the metadata check, else, skip the metadata check. if the PO document is valid, transform the PO document, else, end process. 44 / 56

23 Bottom-up Process-driven Service Analysis 4 Create business service candidates The identified steps are grouped by logical context, with each group representing a service candidate. The context depends on the type of the business services chosen. Processing Metadata Checking 45 / 56 Bottom-up Process-driven Service Analysis 5 efine and apply principles of service-orientation efine the candidates according to the principles of reusability and autonomy. Processing Polling Notification if documents arrive for which there are subscribers, issue notifications Transform Metadata Account Checking Documents transform native documents to XML transform PO XML document into native electronic PO format 46 / 56

24 Bottom-up Process-driven Service Analysis 6 Identify candidate service compositions Identify the set of most common scenarios that can take place, in order to: evaluate the appropriateness of the candidate contexts, identify potential service composition, highlight any missing workflow logic. Core Service Domains Process-centric Services Support services shared across different domains (Finance, Sales) 47 / 56 Bottom-up Process-driven Service Analysis The reverse of the medal: Percolating Processes Organizations start with a detailed Process Map and then try to fit this into a SOA: processes become the dominant feature: POA rather than SOA, task-centric business services (Level 1) are tightly bound to the context of a single process become difficult or impossible to change, fine grained services (Level 2+) proliferate and become difficult to manage. Effects the system slowly or quickly stagnates, new solutions are built on top of the existing ones, due to the lack of reusability (process-oriented system treated as legacy application). 48 / 56

25 Start eceive PO Validate PO PO no valid? yes Tranform PO Import PO Send PO to Queue Stop Send Notification esearch & Development Quality Control Product Manufacture Logistics Management Stock Availability Warehouse Management Supplies In egulatory Approval Packaging Stock Forecasting Stock Control Order Management Contract Management Order Supplies Service Analysis and Design Meet-in-the-Middle 1. Create the Service Interaction Map (SIM) independently of the Process Map: this provides the structure for: breaking down the processes, creating a clear hierarchy of use. 2. Overlay the SIM onto the Process Map, to understand potential cuts. 3. efactor the current solution by attacking the major inflexibilities. efined SIM Start Create and Issue Legacy System Processing Manufacture Sales Export Transform Validate export electronic invoice to network folder import electronic PO into accouting system send PO to accounting clerk s work queue poll network folder for invoice retrieve electronic invoice transform electronic invoice to XML document check validity of invoice document ; if valid, end process invoice no valid? yes time for Check metadata Metadata check? yes no Metadata no valid? Metadata Checking check if it is time to verify TLS metadata PO Processing receive PO document validate PO document Logistics & Warehouse Finance Submit yes if required, perform metadata check; if metadata check fails, end process if PO document is invalid, send rejection notification and end process transform PO XML document into native electronic PO format Stop already existing built independently 49 / 56 Synthesis: Service Definition Layers 50 / 56

26 Web Service Technology Standards Orchestration / Choreography BPEL (implementation), BPMN (at modelling level) Description WSDL, XML Schema, WS-Policy Advertisement, Discovery UDDI, LDAP Messaging WS-Addressing, WS-Security, WS-eliableMessaging, SOAP Transport HTTP, TCP, SMTP, MSMQ Format and Encoding XML, Unicode 51 / 56 Implementing Process-Centric Services A1 Executable Business Process A2 A3 A4 WSDL A1 WSDL A2 WSDL A3 WSDL A4 Service Bus App1: COBOL App2: PL1 App3: Java App4: C# Steen Brahe, Danske Bank 52 / 56

27 Process-centric Services: BPEL Business Process Execution Language (BPEL) Supports description of behavioural interfaces and orchestrations: executable processes model an executable private workflow (orchestrations); abstract processes specify a public message exchange (behavioral interfaces); Imperative programming language: scoped variables, assignment, sequence, while, switch, exception handlers; Constructs specific to WS programming: XML variable typing with XPath/XQuery/XSLT expressions; primitive receive and send actions (with dynamic references); parallelism and synchronisation: flow and control links; event-action rules (event handlers); nested transactions with compensation (compensation handlers); In BPEL 2.0: multiple concurrent executions of a block of code; 53 / 56 Process-centric Services: BPEL Business Process Execution Language (BPEL) (cnd) Layered on top of WSDL: every process is exposed as a web service (or set of web services) using WSDL documents, which describe the process s structural interface (for WS Composition); WSDL references specify calls to external services; WSDL types are used to describe persistent information (variables); independent of WSDL implementation (i.e. binding and service) relies only on the abstract part. 54 / 56

28 BPEL Example: Order Management artifacts 55 / 56 SOA Trends Service Marketplaces & Software as a Service Service marketplaces controlled by a single entity (e.g. SalesForce AppExchange, StrikeIron, SOATrader, Amazon Web Services). Open service communities built around services provided by a single entity (e.g. Google mashups). E-Government service marketplaces (e.g. BizDex, DirectGov). Mobile Service Marketplaces (e.g. Intel Digital Communities Initiative, Streamspin.com) 56 / 56