MTAT Enterprise System Integration

Transcription

1 MTAT Enterprise System Integration Lecture 6: Service-Oriented Analysis Marlon Dumas marlon. dumas ät ut. ee

2 SmartEDA: Integrated Land Development Application System in Queensland Government Dept. Mineral Resources EPA Dept. Main Roads Customer Local Authority Land Dept. Permit Request and Tracking Portal SmartEDA Portal Public services Land Development Application Process centric services Land Development Rules Service Cadastral Service Land Dev. Application Data Service Basic Services (data & logiccentric) Rules Engine Geographical Information System Application Database 2

3 Danske Bank: Customer Package Process Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Introduction of Customer packages. Word template to collect info Steen Brahe, Danske Bank 3

4 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 Steen Brahe,

5 Danske Bank: Customer Package Process Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Case Transfer System Automatic validation and transfering Steen Brahe,

6 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 Steen Brahe,

7 Danske Bank: Customer Package Process Customer Service A Service B Service C Not valid XML Advisor Case Transfer System Create Credit Backoffice workers Juni 2003 August 2003 October 2003 December 2003 Marts 2007 Workflow v. 6 80% automated activities Steen Brahe,

8 Danske Bank SOA Executable Business Process A1 A2 A3 A4 WSDL A1 WSDL A2 WSDL A3 WSDL A4 Service Bus / Application Containers App1: COBOL App2: PL1 App3: Java App4: C# Steen Brahe,

9 Lifecycle and Roles in an SOA Solution Architect Service & Process Design Service & Process Implementation Developer Tester Service & Process Analysis Testing & Deployment Business Analyst Opportunity & Issue Identification Operation & Monitoring Administrator 9

10 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 Methods: Top-down capability-driven method Steve Jones: Enterprise SOA Adoption Strategies. InfoQ, Microsoft Motion Business-Capability Mapping Bottom-up process-driven methods: Thomas Erl: Service-Oriented Architecture, Concepts, Technology, and Design, Prentice Hall, 2005 Hybrid methods: O. Zimmermann et al. Elements of Service-Oriented Analysis and Design, IBM, B. Hess et al. Structuring Software Cities - A Multidimensional Approach.

11 Top-down Service Analysis Pharmaceutical company Pharmak has 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

12 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: Suppliers: organization which buys, and potentially distributes manufactured products manufacturers or wholesalers of components/raw materials Logistics Provider: provides storage and transport services

13 Top-down Service Analysis Level 0 Architecture What Customer Who Why Logistics Company Suppliers

14 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 d 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 4. See:

15 Top-down Service Analysis Level 1 Architecture: Manufacture What Who Why

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: Support Services Shared Services

17 Top-down Service Analysis The Service Map

18 Process-driven service analysis Service-oriented analysis Define business requirements 1. Collect the documentation related to the business requirements and context of a service-oriented architecture. This includes business objects and business processes Identify automation systems 2. Identify existing application logic which already covers any requirement documented in Step 1. Model candidate services 3. Identify service operation candidates and group them into service candidates.

19 Process-driven service analysis Starting point: Business Process Models: a thorough knowledge of the underlying workflow logic is required, the scope of business services may vary: process service process step sub-process service service

20 Process-driven service analysis Sources from which business services can be derived (cnd) Deliverables: Task-centric business services (Level 1): contain a set of operations that relate to a particular task of a process. Pros require little analysis effort to be produced, meet immediate requirements. Cons limited reusability potential: modeling reusable task-centric business services often requires an initial analysis of multiple business process models in order to identify commonalities.

21 Process-driven service analysis RailCo has a legacy system for order management and invoice processing specifically built to interact with a major client ( TLS ). Railco intends to make this system more extensible and generic to be able to interact with other customers and to improve the performance of their order-to-cash process. The service analysis is conducted over two internal business processes, pitched to work with the B2B solution of TLS: - Invoice Submission Process: sends an invoice to TLS, uses the Invoice Submission Web Service. - Order Fulfillment Process: accepts and processes Purchase Od Orders from TLS, uses the Order Od Fulfillment tweb bservice.

22 Process-driven service analysis Start Invoice Submission Order Fulfillment Create and Issue Invoice Export Invoice Transform Invoice Validate Invoice Start Receive PO Validate PO invoice valid? time for metadata check? yes no yes Check Metadata PO valid? yes Tranform PO no Send Notification no Import PO Metadata valid? yes no Send PO to Queue Submit Invoice Stop Stop

23 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 Refine and apply service-orientation Identify service compositions Revise operation grouping Analyze processing requirements Identify application service operations Create application service candidates Revise service compositions Revise operation grouping

24 Process-driven service analysis 1 Decompose the business process Break down the workflow logic in the most granular representation of process steps. Start Create and Issue Invoice Export Invoice Invoice Submission Process Create electronic invoice, Issue electronic invoice, Export electronic invoice to network folder, Poll network folder, Retrieve 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? Transform Invoice Validate Invoice no yes Submit Invoice no yes Metadata valid? Check Metadata yes no Stop

25 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). Invoice Submission Process Create electronic invoice, Manual step (accounting clerk) Issue electronic invoice, Manual step (accounting clerk) Export electronic invoice i to network folder, Custom developed component (legacy logic) Poll network folder, Performed by a custom developed component Retrieve electronic invoice, Performed by a custom developed component Transform electronic invoice to XML document, Performed by a custom component Check validity of invoice document. If valid, end, Performed by Invoice Submission WS Check if it is time to verify TLS metadata, Performed by the Invoice Submission WS If required, perform metadata check. Performed by the Invoice Submission WS If the check fails, end. Could become e part of a generic e service candidate. date Could become e a separate ate service candidate. date

26 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 Invoice 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.

27 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. Invoice Processing Metadata Checking

28 Process-driven service analysis 5 Refine and apply principles of service-orientation Refine the candidates according to the principles of reusability and autonomy. Invoice Processing Polling Notification if documents arrive for which there are subscribers, issue notifications Validate invoice Transform Metadata Account Checking Documents

29 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 Business Services Task-centric Business Services Technical Support Services shared across different domains (Finance, Sales)

30 Process-driven service analysis 7 Revise business service operation grouping Revisit contexts and operation candidates. New services may be created. For complex cases, further steps can be taken: 8 Analyze application processing requirements 9 Identify application service operation candidates 10 Create application service candidates 11 Revise candidate service compositions 12 Revise application service operation grouping g (Optional) Keep an inventory of service candidates

31 Process-driven service analysis The reverse of the medal: Percolating Processes (according to S. Jones) 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 ibl 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).

32 Meet-in-the-Middle Approach to SOA 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. Refactor the current solution by attacking the major inflexibilities. Start Start Create and Issue Invoice Receive PO Validate PO Legacy System Invoice Processing Research & Development Manufacture Supplies In Order Management Sales Contract Management Export Invoice Transform Invoice Validate Invoice PO no valid? yes Tranform PO Import PO Send Notification 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 Quality Control Product Manufacture Regulatory Approval Packaging... invoice no valid? yes time for Check metadata Metadata check? yes no Metadata no valid? Send PO to Queue Stop Metadata Checking check if it is time to verify TLS metadata PO Processing receive PO document validate PO document Logistics & Warehouse Logistics Management Stock Forecasting Stock Availability Stock Control Finance Order Supplies Submit Invoice 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 Warehouse Management Stop already existing built independently

33 Synthesis Service Analysis Identification and definition of the services an organization wants to provide or that are involved in a particular project; Service: a discreet domain of control that contains a collection of tasks to achieve related goals. Deliverable: Service Interaction Map (SIM). Approaches: Top-down service decomposition. Bottom-up: identify services from business process models Meet-in-the-middle.

34 Reminder Lecture next week will be at 10:15 in room 305. Practical session at 12:15 in room

35 References and acknowledgments Slides about the Danske Bank case study are from a talk by Steen Brahe: Example used for top-down service analysis inspired by: Steve Jones: Enterprise SOA Adoption Strategies. t InfoQ, Example of process-driven service analysis inspired by: T. Erl: Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall, Reading of the week: E.S.K. Yu and J. Mylopoulos: Modelling Organizational Issues for Enterprise Integration. In Proceedings of the International Conference on Enterprise Integration and Modelling Technology, Turin, Italy, October 1997, pp