SOA Service Oriented Architecture


Published on

The presentation provides a broad overview of SOA (Service Oriented Architecture), its style, its constituents and supporting implementations.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SOA Service Oriented Architecture

  1. 1. Service Oriented Architecture August, 2008
  2. 2. Disclaimer The content of this presentation is not my own. The presentation is an aggregation of content available on the internet. Unfortunately I do not have the links to provide references or pointers to the original authors.
  3. 3. Agenda  Why do we need another architecture?  Why are present day architectures inadequate?  What is Service Oriented Architecture (SOA)?  What constitutes a service?  So what is a service?  What are the elements of a SOA?  How do the SOA elements interact?  What are the different categories of a service?  Where do the services fit in our enterprise architecture?  Which business situations make good candidates for SOA implementation?  What technologies do I use to implement SOA?  What does the SOA stack comprise of?
  4. 4. Why do we need another architecture?
  5. 5. Pressures on the business… Continuous business transformation EvolvingBusinessObjectives ChangingMarkets New Demands Growth, profit, and value Leadership Customer satisfaction Innovation Technology Regulation/ Deregulation Mergers & acquisitions Economy Competition Satisfying Unpredictable Needs CustomerSupplier Partner Business agility
  6. 6. Why are present day architectures inadequate?
  7. 7. Application Architecture – Monolithic Applications User Interface Logic Business Rules Application Logic Data Access Logic Data Application No Partitioning Mainframe Server or Deployment Monolithic applications • Applications where code implementing business rules, data access, and user interface are put together as part of a single, large computer program • Typically deployed on a single platform, often a mainframe or midrange computer* Limitations of monolithic applications: • Applications are tightly coupled • Software applications are difficult to understand and maintain • Limited scope for code reuse • Applications are inflexible for handling changing business requirements
  8. 8. Application Architecture – Client Server Applications Client Server applications • 2 tier applications with one tier containing the graphical user interface (GUI) and implementing the business rules. The application’s data storage resides in the second tier. The first tier executes on PCs or workstations and requests data from the second tier. • Although the application has two tiers, most of the code is contained in the tier executing on the workstations, hence the name “fat client”. Limitations of Client Server applications: • Lacks scalability • As logic is located in the fat client layer, code reuse is difficult
  9. 9. Application Architecture – 3 Tier Applications 3 Tier applications • 3 tier applications are partitioned into three executable tiers of code: the user interface, the business rules, and the data access software. • The 3 tiers need not reside on different platforms. Often the business tier is deployed on the same platform as the data access tier or the user interface. Limitations of 3 tier applications: • 3 tier applications are developed using a silo based approach
  10. 10. Application Architecture – Distributed Components Distributed Component based applications • Distributed component oriented architecture emphasizes on decomposition of applications into functional or logical components. Limitations of distributed component oriented applications: • Interoperability is difficult; heterogeneous components, firewall unfriendly • Software applications are difficult to understand and maintain • Components need to know platform, language specific implementation details for integration
  11. 11. Present day architectures limitations are
  12. 12. Existing IT architectures cannot support changing needs Limited scaling capability Agility  IT assets cannot be easily repositioned in response to changing requirements  No solution for efficient intra- and inter-organization information sharing  Decision cycles are unnecessarily lengthened by data stovepipes Process Heterogeneity  Systems, organizations units and network of partners duplicate the same work  Information stovepipes require point-to-point integrations that limit flexibility and create maintenance overhead  More efforts spent connecting systems together than adding mission critical capabilities Data Heterogeneity  Difficult to determine “what data means” fosters duplicate applications and data  Inability of applications to interoperate due to platform incompatibility. Data used across an organization is often inconsistent and potentially inaccurate Costs  Duplicate data entry and manual data reunion require extra man power  Point-to-point integration shifts IT professionals towards repetitive employees to time consuming tasks  Integrating data stovepipes is expensive and wasteful  Operations and maintenance costs are a rising percentage of the budget Limited agility, redundant processes , lack of system interactions, and high cost factor
  13. 13. IT Reality Requirements Time Business IT Systems IT Systems Can’t Keep Up
  14. 14. What does your enterprise needs? • Software that reflects the business need • Promotes reusability • Promotes integration • Software which is agile to enterprise’s changing business needs “Software needs to be built to change and not built to last.”
  15. 15. What is Service Oriented Architecture (SOA)? SOA? Whoa!
  16. 16. What is SOA • Service Oriented Architecture is an architectural style/pattern for creating and using business processes as “services”. • An approach for building distributed computing systems based on encapsulating business functions as services that can be easily accessed in a loosely coupled fashion. • Application’s business logic or individual functions are modularized and presented as services to client/consumer applications In essence……. • A shift in focus away from “applications” towards business processes • An architecture in which processes are constructed either in whole or in part by assembling reusable services.
  17. 17. A Solution – Service Oriented Architecture SOA is an approach to organizing and using IT to match and combine needs with capabilities in support of the overall mission of an enterprise Capabilities performed by one for another to achieve a desired outcome Functionally aligning architecture to enable a collection of independent services to be linked together to solve a business problem The fundamental organization of a system embodied in its capabilities, their interactions, and the environment Architecture Oriented Service SOA - A paradigm that encourages organizations to re-think how their IT capabilities are organized
  18. 18. SOA: What it is not “It is an approach for building agile and flexible business applications.” It’s not: • Product • A specific technology • An application • A specific standard • A specific set of rules
  19. 19. What constitutes a service? SOA? Whoa!
  20. 20. Service and Service Scenario Definition A service is a self-sufficient unit of work representing a specific business function, accessible through well defined interfaces, governed by a defined contract. Service Scenario To understand what a service means, let’s consider an example. A patient walks into a hospital with an illness. The patient encounters the following actors: receptionist, doctor, technician, nurse Each of these actors is associated with some specific services. The receptionist manages the patient’s files. The doctor inspects the patient, recommends medical tests or formulates a treatment plan. The technician carries out medical tests e.g. pathology test or radiology test or lab test. The nurse takes care of the patient and ensures their adherence to the specified drug treatment. Each of these actors typically use independent/coordinated IT applications to record patient related information.
  21. 21. Service -Inspection -Treatment -Patient-care -Drugs -Manage files Doctor Nurse Receptionist Technician -X-ray films Patient Hospital External Clinic Cure Process Business Objective HIS ECP Clinical Systems RIS PIS
  22. 22. The previous slide takes a simplistic view of the hospital functioning. The actual functioning may involve number of different departments such:  Insurance Company – claim  Accounts – patient billing  Medical Exam Agencies – lab, pathology etc  Other hospitals – specialized care It is critical that data flows between these agencies smoothly and in a real time fashion to ensure best possible patient care. Service - continued
  23. 23. Service Department Radiology LaboratoryPathology External Hospital Accounting Drug Company Insurance Hospital Administration Radiology Order [RIS] Pathology Order [Pathology Info System] Laboratory Order [LIS] Billing [ERP] Payment Claim Processing [ECP] Drug Info [Drug DB] External EHR [EHR System] Patient Demographics [Hospital Info System]
  24. 24. Here’s how the patient care example translates into services. The green globes represent business functions exposed as “services”. Service – Drill Down HIS Lab Information Systems Patient visits the hospital Receptionist creates/updates the patient file, fixes an appointment with doctor Create/Update Patient File Fix Doctor Appointment The doctor examines the patient, prepares an inspection report, or suggests lab examination Physical Examination Report Request Lab Exam Patient visits the doctor Patient visits the laboratory The lab technician takes sample, conducts tests and prepares reports Prepare Lab Report The doctor examines the lab reports, makes a diagnosis and suggests treatment Prepare Diagnosis Prepare Treatment Accounting The Hospital reconciles with insurance company and conveys billing information to accounting which creates billing notice Billing Info Update
  25. 25. Service - Continued So how have we benefited? • Closely related business functionality continues to remain as a part of single business application i.e. for e.g. Hospital Information System, Lab Information System, Billing • Enterprise data is shared across various silos like hospital, lab, accounting etc. • Key participants like the doctor is presented with a unified view of patient data, in turn providing best possible patient care. Limitations of implementing the hospital IT as a monolithic system: • Extremely rigid application with all business functions in single application • Limited scope for code reuse • Implementation of business change would be effort intensive Limitations of implementing the hospital IT as a client server system: • No scope for integrating with external systems Limitations of implementing the hospital IT as a n tier system: • External systems can be integrated using point-to-point connectivity • Code reuse limited to the application • Separate application silos for hospital admin, lab admin and accounting would be created.
  26. 26. So what is a service? SOA? Whoa!
  27. 27. What is a Service? • Loosely coupled, autonomous, reusable, and have well-defined, platform- independent interfaces • Provides access to data, business processes and infrastructure, ideally in an asynchronous manner • Receives requests from any source making no assumptions as to the functional correctness of an incoming request • Each request encompasses a complete and independent unit of work • Each request leaves the system in a long-term steady state • Can be written today without knowing how it will be used in the future • May stand on its own or be part of a larger set of functions that constitute a larger service • Provides for a network discoverable and accessible interface • Keeps units of work together that change together (high coupling) • Builds separation between independent units (low coupling)
  28. 28. A Service…. • It has an interface and contract • It can have one or more operations (methods to do something) • Each business capability is invoked by messaging • The messages into the service request business operations • The semantics of the operations are around business functions Service Service Logic Data
  29. 29. Service Contract A service contract defines everything needed to interact with the service and nothing more Service Consumer Service Provide r Contract
  30. 30. Service Contract Service contract defines the following:  Service interface  Service description  Service level agreements
  31. 31. Service Interface Service interface specifies operations, messages, transports, and location. The interface definition can be in:  WSDL (Web Service Description Language)  XML Schemas  Proxies generated from Service Implementation  A formal hardcopy specification e.g. A credit card service may define the following service interface: Operation name: processTransaction Input Message: CreditCard data structure debitAmount Output Message: TransactionResponse data structure containing transactionID, errorCode etc URL: Interface: • Cust_Name • CC# • Expiration_Date • PIN#
  32. 32. Service Description Service description  sequencing requirements  exception handling  formal documentation and implied semantics e.g. Sequencing requirements - A third party service provider provides three separate interfaces, one for getting requestid, second for sending the request and the last one for receiving the response. Exception handling - In case of credit card service, failures will be communicated in the form of error codes. For example 10502 – Credit Card used has expired 10545 – Credit Card declined because of possible fraudulent activity 10610 – Amount limit exceeded The consumer will find documentation regarding the error codes in the service description.
  33. 33. Service Level Agreement A service-level agreement (SLA) is a formal contract between a service provider and a consumer guaranteeing quantifiable performance at defined levels. Service providers use SLAs to: • Distinguish themselves from their competitors • Guarantee the services it provides will be available for a certain percentage of time (for example, 99.9%) • Impose limits on maximum, average response times, service downtime within a timeframe • Provide an exit clause for the consumer in case of unsatisfactory services.
  34. 34. Service Level Agreement Categories Functionality • Values/functions provided – e.g. “regular fund price” • Service Interface – WSDL, non-WSDL SOAP, IDL, JMS etc • Version compatibility – interface/function compatibility, version control policy and procedures Operational aspects • Service availability – “24/7/365” or “on schedule” with downtime • Service cost – if any for consumer or license model etc • Service Change Control protocol – how a new version of the service is made available with and without backward compatibility Quality Of Services • Conditional performance expectations • Scalability – horizontal / vertical • Failover, execution exception handling protocol and alerts • Business Process Exceptions – Legitimate technical results that are considered abnormal/exceptional • Expected response time • Throughput Quality of Data • Returned data – a list of data items • Metadata round returned data – format definition for all scenarios, validity of data Service Constraints • Security policies – for users and other services • Country/industry policies – regulation of information encryption algorithms • Pre-known conditions – like delivery schedule, pick hours • Service priority – may be different for different customer status
  35. 35. What are the elements of a SOA ? SOA? Whoa!
  36. 36. SOA Model Elements Service Provider - provides a service interface for a software asset that manages a specific set of tasks Service Requester/Consumer - discovers and invokes other software services to provide a business solution Service Directory/Broker - acts as a repository, yellow pages or clearing house for software interfaces that are published by service providers Loosely coupled components communicating via well defined interfaces Bind / Invoke Service Consumer Service Provide r Service Director y Find / Details Publish Contract Contract SOA Infrastructure
  37. 37. Service Requester/Consumer The service consumer is an application, service or any other type of software module that requires a service. It is the entity that initiates the locating of the service in the registry, binding the service over transport and executing the service function. Bind / Invoke Service Consumer Service Provide r Service Director y Find / Details Publish Contract Contract SOA Infrastructure
  38. 38. Service Provider Service provider is the service, network-addressable entity that accepts and executes from consumers.  Independent software vendors are prime examples of potential service providers. e.g. – MIB,  Processes that are proven and generalized for a diverse set of applications would be good candidates for service providers. e.g. individual risk assessment in insurance industry Bind / Invoke Service Consumer Service Provide r Service Director y Find / Details Publish Contract Contract SOA Infrastructure
  39. 39. Service Broker / Directory  Service broker is an entity that collects and catalogs data about other entity and further on providing data to others  Essentially is a repository of service contracts  Provides a facility for discovering services  May contain additional information such as: o Contact Information o Usage fees  May be formal or informal o UDDI o Centralized Web site o A proprietary database of XML schemas o Printed documents  Scoped to application, department, enterprise, extended enterprise  May be formally managed by a corporate architecture group Bind / Invoke Service Consumer Service Provide r Service Directory Find / Details Publish Contract Contract SOA Infrastructure
  40. 40. How do the SOA elements interact? SOA? Whoa!
  41. 41. Service Elements  Presentation layer or another service  Locates service provider through agreed upon service directory  Binds/invokes service based service interface  Only the service interfaces are exposed  Service implementation is hidden from the service consumer  Data store encapsulated by service Service Interface Fn() Service Implementation Service Consumer Service Provider Fn() Data Service Logic
  42. 42. What are the different categories of a service? SOA? Whoa!
  43. 43. SOA Service Types SOA based services can be broadly classified under three categories  Basic Services  Intermediary Services  Business Process Services
  44. 44. Basic Services  A stateless service oriented software function  Strictly, acts as a service provider  Encapsulates all access to a particular data source
  45. 45. Basic Services Online Ordering Application Order Management Customer Management Inventory Management Basic Service Layer Application Client Layer Warehouse Application
  46. 46. Intermediary Services  A stateless service which is both a provider and a consumer  Includes business and infrastructure types  Technology gateways  Bridge gap between two technologies  Transformation  Convert message format from/to what service consumer and provider expect e.g.  Facades  Aggregated, simplified view of multiple services e.g. the underlying implementation of orderProduct service does inventory check and handles product shipping  Functionality-adding services  Add functionality to a service without changing the service itself
  47. 47. Intermediate Services Online Ordering Application Order Management Customer Management Inventory Management Basic Service Layer Application Client Layer Order and Ship Intermediate Service Layer
  48. 48. Business Process Services  Encapsulates an enterprise’s business process  Acts as both a service provider and a service consumer  Tends to be application specific
  49. 49. Business Process Services Online Ordering Application Order Management Customer Management Inventory Management Basic Service Layer Application Client Layer Order and Ship Intermediate Service Layer Catalog Service Business Process Service Layer Order Cancellation Service
  50. 50. SOA Service Types Business Process Services Intermediary Services Basic Services Application Client Layer The service types can be diagrammatically represented as below
  51. 51. SOA: Growth Stages Agility and Flexibility Complexity Process-Driven SOA Multi-Level SOA Simple SOA Maturity of SOA SOA evolves thru incremental and iterative development process
  52. 52. Simple SOA Online Ordering Application Order Management Customer Management Inventory Management Basic Service Layer Application Client Layer Warehouse Application
  53. 53. Multi level SOA Online Ordering Application Order Management Customer Management Inventory Management Basic Service Layer Application Client Layer Order and Ship Intermediate Service Layer
  54. 54. Process driven SOA Online Ordering Application Order Management Customer Management Inventory Management Basic Service Layer Application Client Layer Order and Ship Intermediate Service Layer Catalog Service Business Process Service Layer Order Cancellation Service
  55. 55. Services Where do these services fit in our enterprise architecture? SOA? Whoa!
  56. 56. Services fitment in an enterprise application The services become a part of the business layer of the enterprise application Presentation Layer/s Integration Layer/s Data Access Layers Managed Unmanaged Users Enterprise Services Service Interface Business Workflows Business Tasks Business Entities Service Adapter Business Process Service Basic and Intermediary Service
  57. 57. SOA Remember, SOA is a paradigm shift in software development
  58. 58. Shift towards SOA • Function oriented • Build to last • Long development cycles • Process oriented • Build to change • Incrementally built and deployed • Application silos • Tightly coupled • Object oriented • Known implementation • Orchestrated solutions • Loosely coupled • Message oriented • Abstraction Service5 Service6 Service9 Service1 Service2 Service3 Bus
  59. 59. SOA – A word of caution • Tools and technologies will not automatically give you SOA • SOA without good data is doomed to failure • SOA without governance will NOT realize full value • Do not rush to deploy technology solutions • Do not ignore master data, data quality and security issues • Do not underestimate the cultural issues surrounding change
  60. 60. SOA Candidate Business Scenarios Which business situations make good candidates for SOA implementation? ? ? ?
  61. 61. SOA Candidate Business Scenarios  Business Collaboration - Efficiency of working with business partners  Integration  Merger & Acquisitions  Agility to handle market change  Reuse business functionality beyond business application
  62. 62. SOA Candidate Business Scenarios – Business Collaboration Order Mgmt Service Approve FulfillOrder Valid Order Supplier Service Check Credit Hold Stock Valid Order? Online Ordering Service Req. Order Notify Buyer OrderEntry Inventory Mgmt Service Hold Ship Lookup Credit Services Approve Notify Chk Credit SOA - A sea of services
  63. 63. And what happens when the organization makes a strategic acquisition in Germany? SOA Enables System Integration Oracle HR Online Recruiting Success Factors Performance Assessment Equity Edge Stock Plan Admin Online Benefits SOA Germany HR ? ? ? ? SOA Enabled IT Systems: • Agile – Rapidly meet business needs • Reusable – Leverage existing solutions • Standardized – Meets cross-functional challenges Why not skip the middle-man? You could… but significant IT systems are rarely that simple… The plot thickens… Direct point to point becomes a complex web of connections each requiring custom maintenance… The SOA Solution ADP Payroll Why SOA? – Why not Point-to-Point?SOA Is Inevitable
  64. 64. Business Agility Division Let’s take an example of company and its Order-to-Cash process. The Order-to-Cash process within itself has multiple business functions like marketing and catalog management, order entry, inventory management, fulfillment and delivery logistics, accounting and receivables, reconciliations etc Initially all these business functions had been taken care of internally. This has changed.
  65. 65. Business Agility With the emergence of internet, customers can now access the company’s web site to submit orders. So a part of the business process has moved to the customer, it may be thru a web interface or in case of B2B type interactions via a web service. Change 1: Customer Order Entry Division Customer
  66. 66. Business Agility Many companies are finding out that different parts of their business do the same thing. Thus, the company loses on providing a consolidated customer experience and also to high maintenance costs for maintaining different business applications doing the same thing. It pays to consolidate these commonalities as shared services within the company. Examples of shared services are:  Marketing – Email generation with consistent branding  Billing – Common billing, often consolidated billing  Receivables – common credit status, collection processes etc Change 2: Shared Service – Marketing, Billing, Receivables Division Customer Shared Service
  67. 67. Business Agility Today organizations are looking for ways to minimize or eliminate inventory. Some companies allow their supplier to take care of inventory management, a cost effective solution vis-à-vis building and maintaining internal inventory management applications. Change 3: Supplier handles inventory Division Customer Shared Service Supplier
  68. 68. Business Agility Organizations today utilize efficient shipping services of vendors specialized in shipping and logistics. The organization’s business connects and uses the shipping services of the shipping company. Change 4: Order shipping by DHL, FedEx or UPS Supplier Division Customer Shared Service Supplier Outsourced
  69. 69. Business Agility For functions which are not strategic differentiators and which others do better, organizations outsource those business functions. For example, an organization can outsource its overdue payments handling to an external collections agency. Change 5: Outsourcing Outsourced Division Customer Shared Service Supplier
  70. 70. Business Agility Through analytics, bottlenecks or deficiencies in in-house processes can be identified and ironed out. Areas of high costs, improvement or automation can be focused on and removed. For example, for a high value customer with a collection issue, the organization may decide to handle the situation on its own instead of using a collection agency. Change 6: Process Optimization Outsourced Division Customer Shared Service Supplier
  71. 71. SOA What technologies do I use to implement SOA?
  72. 72. SOA Infrastructure Service Service Service Service Service AppServer (JEE / .NET) CORBA JMS FTP Web Services SOA Infrastructure can be implemented using plethora of technologies. Web Services just happens to be a popular option.
  73. 73. SOA Let’s focus on Web Services.
  74. 74. SOA enabling technologies – Web Services  XML XML is a markup language for documents containing structured information.  SOAP SOAP is a XML based lightweight protocol for exchange of information  WSDL The Web Services Description Language is an XML vocabulary that provides a standard way of describing services  UDDI The Universal Description, Discovery and Integration specification provides a common set of SOAP APIs that enable implementation of a service broker Web Services technology stack comprises the following:
  75. 75. Our Architecture in the EAI days CRM ERP PARTNER SYSTEMS FINANCE ORDER ENTRY Let’s expose the application interfaces as Web Services.
  76. 76. Web Services This has provided the following benefits: • Well defined service interface promotes reuse • XML-based data easily exchanged • Designed for remote access, across heterogeneous platforms OpenEdge Application WEB SERVICE Implementation of the application interfaces as Web services, standardizes the interfaces. TCP/IP WEB SERVICES INTERFACE .NET™ APPLICATION PACKAGED APPLICATION & LEGACY SYSTEMS J2EE™ APPLICATION XML XML
  77. 77. Web Services • Is it more agile? • Is it reliable, scalable and secure? • Can it be managed and monitored? J2EE™ APPLICATION PACKAGED APPLICATION & LEGACY SYSTEMS .NET™ APPLICATION OpenEdge Application WEB SERVICE WEB SERVICES INTERFACE But Have We Solved The Whole Problem? Web services are interoperable communications stacks but don’t offer key capabilities like routing, service deployment, management, format transformation, and guaranteed delivery. TCP/IP
  78. 78. Web Services The solution retains certain drawbacks: • Tight coupling • Little flexibility / agility • No service level monitoring capability J2EE™ APPLICATION PACKAGED APPLICATION & LEGACY SYSTEMS .NET™ APPLICATION OpenEdge Application WEB SERVICE WEB SERVICES INTERFACE Web services has just addressed part of the problem. It has achieved interoperability by standardizing the application interfaces. TCP/IP Clearly, implementing only web services is not enough.
  79. 79. SOA What does the SOA stack comprise of?
  80. 80. SOA Infrastructure Stack The SOA infrastructure stack is sub-divided into the following distinct layers: • Service enablement layer Business functionality within applications are modularized and exposed as standard interfaces • Service orchestration layer The orchestration layer provides transformation, availability, routing of services exposed at the service-enablement layer and orchestrating individual services into business services. The registry/repository is an essential component of this layer. • Process orchestration layer Business process management and business activity monitoring is part of process orchestration layer. This layer provides support for business processes built on the business services integrated in the service Orchestration layer.
  81. 81. SOA Infrastructure Stack The likely candidates for the SOA infrastructure stack implementation are mentioned below: • Service enablement layer  Web Services  EJB  JMS • Service orchestration layer  Enterprise Service Bus (ESB) products like Cape Clear ESB, IBM ESB, TIBCO Business Works etc • Process orchestration layer  BPM products like IBM Process server, Pegasystems, Savvion, Global 360 Service Enablement Service Orchestration Process Orchestration Web Services, EJB, JMS ESB BPM Infrastructure Layer Implementation product/Std
  82. 82. Enterprise Service Bus ENTERPRISE SERVICE BUS J2EE™ SERVICE LEGACY SYSTEMS .NET™ SERVICE OPENEDGE SERVICE WEB SERVICE Integrated Set of SOA Services Based on a Common SOA Infrastructure Backbone ESB Features: • Data transformation • Protocol transformation • Content-based routing • Service Registry • Logging • Persistence • Specialized Adapters • Orchestration Server • Asynchronous and synchronous messaging • Security • Transaction Management • Performance, scalability & fault tolerance
  83. 83. Business Process Management BPM is a set of integrated management and analytic processes, supported by technology, that addresses business and operational activities. BPM is an enabler for businesses in defining strategic goals, and then measuring and managing performance against these goals. Core BPM processes include financial and operational planning, consolidation and reporting, modeling, analysis, and monitoring of key performance indicators (KPIs) linked to organizational strategy BPM Features: • Business Process Modeling • Business Process Execution • Process Monitoring • Process Optimization • Content Management • Human Tasks
  84. 84. SOA Benefits  Loose coupling among interacting software agents  A mechanism for integrating software components on dissimilar platforms  Supports non-intrusive reuse of software components in ways not specifically predicted during development  Can enable easier in-house/outsourced development by breaking systems down into smaller into smaller chunks  Interoperability  Separation of developer concerns - Clean separation of business logic from presentation and resource connectivity, allows for maximum developer productivity  Increase Code Reuse – Since services do not contain presentation or data access code, the same service can be easily reused in another application that needs the same business logic  Maximize flexibility – With SOA, the different core components of the application are very loosely coupled.
  85. 85. Service Oriented Architecture Benefits Summary Agility Focus more on core competencies Creates a network of service requesters (consumers) and service providers (producers) Enable enterprises to be more agile and respond quickly to changing requirements Increase business flexibility through plug- and-play architecture and re-use of existing services Process Heterogeneity Allow interoperation with other systems without time consuming customization and point-to-point integration Ensure system change is not a constraint on business or mission change Facilitate integration with multiple solutions via open IT standards Data Heterogeneity Improve semantics of data exchanged during business process execution Maintain consistency of data across different systems Remain platform, language, and vendor independent to remove IT barriers for using best-of-breed software packages Costs Leverage existing IT infrastructure Reduce costs of development of new functionalities by acquiring pre-built components/services Lower maintenance costs SOA allows to align IT with mission of the organization Better agility, no redundancy, system interactions, and reduces overall costs of system maintenance
  86. 86. SOA – The road ahead SOA is a continuing journey and not a destination.
  87. 87. SOA – Addendum Addendum
  88. 88. SOA Standards  Web Services protocols and specifications have grown in number and complexity over the last decade.  Here we intend to provide an high level overview of some of the important specifications.
  89. 89. SOA Standards Overview Courtesy: URL
  90. 90. The WS Alphabet Soup XML Messaging Metadata TransactionsSecurity Reliability Business Process Orchestration Transport The Fundamentals - XML - SOAP - XSD - WSDL - JMS - WS-Addressing - HTTP - WS-Policy
  91. 91. Fundamentals Fundamentals
  92. 92. Fundamentals – Transport  HTTP is the most widely used protocol for internet communications.  Intra-enterprise is a mix of protocols beyond HTTP like  Message Oriented Middleware (MOM) provider specific protocol  SMTP  FTP
  93. 93. Fundamentals XML – The Data Format  XML  Provides a neutral representation of data  Supported across all platforms and programming environments  XML Schema  Syntax and structural rules  Object oriented language with rich extensibility
  94. 94. Fundamentals – Messaging - SOAP  SOAP  Enveloping structure to identify header and body contents  A SOAP message is an ordinary XML document containing the following elements: - A required Envelope element that identifies the XML document as a SOAP message - An optional Header element which contains header information - A required Body element that contains call and response information - An optional Fault element that provides information about errors that during message processing. <?xml version="1.0"?> <soap:Envelope xmlns:soap="" soap:encodingStyle=""> <soap:Header> ... ... </soap:Header> <soap:Body> ... ... <soap:Fault> ... ... </soap:Fault> </soap:Body> </soap:Envelope>
  95. 95. Fundamentals – Messaging – WS-Addressing  Existing IT technologies provide addressing capabilities as a part of their solutions, typically as a part of the transport layer. For example, if HTTP is used as the transport layer, the HTTP header holds the address information in the HTTP method and host fields.  This makes addressing transport layer specific.  Web Services are meant to be transport layer agnostic and can be implemented using any execution environment. Therefore there is a need for an independent addressing mechanism.  WS-Addressing specification is a specification of transport-neutral mechanisms that allow web services to communicate addressing information.  It essentially consists of two parts: a structure for communicating a reference to a Web service endpoint, and a set of Message Addressing Properties which associate addressing information with a particular message.  Instead of relying on network-level transport to convey routing information, a message utilizing WS-Addressing may contain its own dispatch metadata in a standardized SOAP header.  The network-level transport is only responsible for delivering that message to a dispatcher capable of reading the WS-Addressing metadata. Once that message arrives at the dispatcher specified in the URI, the job of the network-level transport is done.  WS-Addressing aims to make Web Services support: - A wide range of transport protocols - Asynchronous communication - Dynamic end point addressing
  96. 96. Fundamentals – Messaging – WS-Addressing - Contd Classical SOAP example to execute Stock Price Web Service : The type of the message being conveyed is SOAP Host URI SOAP Action !!! SOAP Message is dependent on the transport protocol !!!
  97. 97. Fundamentals – Messaging – WS-Addressing - Contd To make SOAP transport protocol neutral use <To> and <Action> tags… WS-Addressing also adds ability to make Web Services asynchronous…
  98. 98. Fundamentals – Messaging – WS-Addressing - contd current message has id “uuid:someid” and it is related with another message that has id “uuid:someotherid” and the type of the relationship is “Reply” The address of the sender of the message, the addresses for return reply or fault messages are given
  99. 99. Fundamentals – Messaging – Attachments & MTOM  SOAP With Attachments - method used by Web Services to send and receive files using a combination of SOAP and MIME, primarily over HTTP  MTOM (Message Transmission Optimization Mechanism) - a method of efficiently sending binary data to and from web services. It uses XOP (XML- binary Optimized Packaging) to transmit data and will replace MIME and DIME attachments. - MTOM allows for more efficient sending of binary data in a SOAP request or response.
  100. 100. The fundamentals – Metadata - WSDL  Web Service Description Language  Define the logical interface of a service in terms of messages and operations  Message style and encoding formats: doc/literal or rpc/encoded  Specifies endpoint addresses Port Service Binding Data Type Part Message Operation PortType WSDL Logical Contract Physical Contract
  101. 101.  Components  Types XML representations of the types (typically XML Schema language) e.g. searchRetrieveRequestType  Messages XML messages built from types passed from client to server and server to client e.g. searchRetrieveRequest, searchRetrieveResponse  portTypes Which messages are sent in which direction, and what the response is e.g. searchRetrieveRequest is sent client to server, and a searchRetrieveResponse sent back  Bindings How to encode (e.g. SOAP document/literal) How to transport (e.g. HTTP, SMTP)  Services Endpoint e.g. WSDL Components
  102. 102. The Main Structure of WSDL <definition namespace = “http/… “> <type> xschema types </type> <message> … </message> <port> a set of operations </port> <binding> communication protocols </binding> <service> a list of binding and ports </service> <definition>
  103. 103. Types • <types> define types used in message declaration • XML Schema, DTD, and etc. • XML Schema must be supported by any vendor of WSDL conformant products.
  104. 104. <types> <schema targetNamespace="" xmlns=""> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string“ minOccur = “1” maxOccur=“10”/> <element name = “payment”> <complexType> <choice> <element name = “account” type=“string”> <element name = “creditcard” type=“string”> </choice> </complexType> </element> </all> </complexType> </element> </schema> </types>
  105. 105. WSDL Messages • The <message> element defines the data elements of an operation. • Each messages can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language.
  106. 106. <message name="GetLastTradePriceInput"> <part name="body" element="TradePriceRequest"/> </message> <message name="GetLastTradePriceOutput"> <part name="body" element="TradePrice"/> </message>
  107. 107. WSDL Ports • The <portType> element is the most important WSDL element. • It defines a web service, the operations that can be performed, and the messages that are involved. • The <port> defines the connection point to a web service, an instance of <portType>. • It can be compared to a function library (or a module, or a class) in a traditional programming language. Each operation can be compared to a function in a traditional programming language.
  108. 108. <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation> </portType>
  109. 109. Operation Types • The request-response type is the most common operation type, but WSDL defines four types: • One-way: The operation can receive a message but will not return a response • Request-response:The operation can receive a request and will return a response • Solicit-response:The operation can send a request and will wait for a response • Notification:The operation can send a message but will not wait for a response • -- v 1.2 addition request – multiple response …
  110. 110. One way and Notification Example<portType name=“RegisterPort"> <operation name=“register"> <input name=“customerInfo" message=“RegInfo"/> </operation> <operation name = “register Response”> <output name = “response” message=“ResponseInfo”/> </operation> </portType >
  111. 111. Binding • Binding defines how message are transmitted, and the location of the service.
  112. 112. <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport=""/> <operation name="GetLastTradePrice"> <soap:operation soapAction=""/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>
  113. 113. <service name="StockQuoteService"> <documentation>My first service</documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location=""/> </port> </service>
  114. 114. The fundamentals – Metadata - UDDI  Universal Description Discovery & Integration  A catalog of services – think LDAP for Web Services  Browsing and querying interfaces  Synchronization between registries  Subscriptions to change notifications Marketplace Search Portal Marketplace Marketplace Search Portal Search Portal UDDI Registries & Protocol Technical Users Business Users Advanced Discovery via Portals & Marketplaces
  115. 115. The fundamentals – Metadata – WS-Policy  To use a web service a client needs more information than what is provided in WSDL. For example, - Does the web service support WS-Security? If so, - What is the encryption algorithm the web service expects or prefers? - Must messages be signed? - What character encoding is used? - What version of SOAP is supported?  WS-Policy is a specification that allows web services to advertise their policies (on security, Quality Of Service, etc).  WS-Policy provides a flexible and extensible grammar for expressing the capabilities, requirements and general characteristics of web services.
  116. 116. WS Alphabet Soup - continued XML Messaging Metadata TransactionsSecurity Reliability Business Process Orchestration Transport The Qualities of Service - WS-Security - WS-Coordination - WS-ReliableMessaging - WS-SecureConversation - WS-AtomicTransaction - WS-Trust - WS-BusinessActivity - WS-Federation
  117. 117. Security Security
  118. 118. WS-Security  WS-Security specification defines a set of mechanisms to assist in securing SOAP message exchanges. The specification provides for Quality Of Protection for the SOAP message in the following aspects: - Message integrity => message is not tampered in transit - Message Confidentiality => message is unreadable for everyone except the recipient - Single Message Authentication => You are who you said you are - Provide end to end message security
  119. 119. WS-Security - contd
  120. 120. WS-Security-contd  The business needs to prove its identity to the credit report company and the bank (authentication)  The credit report company needs to know that their paying customer won’t back out maliciously after sending the request (non repudiation)  The credit report company needs to prove it supplied the credit score itself (authentication)  All the message content needs to reach its various destinations unchanged (integrity) and be safe from competitors’ eyes (confidentiality)  The bank needs to record the receipt of the application (auditing)
  121. 121. WS-Security-contd Security Requirements WS-Security Implementation techniques / technologies Authentication SecurityToken – UserName, Binary, XML Non-repudiation, integrity XML Digital Signature Confidentiality XML Encryption Auditing WS-Security defines a <Timestamp> element
  122. 122. WS-Security-Samples SOAP Header <S:Envelope> <S:Header> <wsse:Security> <! - - Security Token - - > <wsse:UsernameToken> …………….. </wsse:UsernameToken > <! - - XML Signature - - > <ds:Signature> ……… <ds:Reference URI=“#body”> ……. </ds:Signature> <! - - XML Encryption Reference List - - > <xenc:RefereneList> <xenc:DataReference URI=“#body”/> </xenc:RefereneList> </wsse:Security> </S:Header> <S:Body> <! - - XML Encryption Reference List - - > <xenc:EncryptedData Id=“body” type=“content”> ………………. </xenc:EncryptedData> </S:Body> </S:Envelope>
  123. 123. WS-Security-Samples SOAP Header with Timestamp <S:Header> <wsu:Timestamp> <wsu:Created> 20-02-06 13:45</wsu:Created> <wsu:Expires> 21-02-06 13:44</wsu:Expires> <wsu:Recevied Actor= Delay=“60000”> 20-02-06 13:49 </wsu:Created> </wsu:Timestamp> </S:Header>
  124. 124. WS-Trust  Motivation- A SOAP Message protected using WS-Security presents the following possible issues with regards security token - Security token incompatibility - Security token trust - Namespace differences  WS-Trust defines standard interfaces for - Security token creation, management and exchange - Dissemination of credentials within different trust domains  Specific purpose of WS-Trust is to provide: - Methods for issuing and exchanging security tokens - Ways to establish and access the presence of trust relationships
  125. 125. WS-Trust-Use Case 1 contd  In complex Web service architectures, it can be cumbersome and error-prone to require that all services directly trust all possible clients.  Web services can be more flexible and manageable by designating a separate authentication service. The separate authentication service can exchange or issue tokens to consumers of a service or validate tokens for the service itself.
  126. 126. WS-Trust-Use Case 2 contd  Client understands X.509 certificates only  Service understands SAML only  No established trust between client and service
  127. 127. WS-Trust-Use Case 2 contd SOAP Client sends initial request to SOAP serviceSOAP gateway recognizes that it must map to SAML, so it contacts the Security Token Service (STS) STS sends back the token in requested formatThe gateway formats and sends the message to the service
  128. 128. Federation  Federation is a collection of realms/domains that have established trusts.  Federation is the technology and business arrangements necessary to interconnect users, applications, and systems.  Federated systems can interoperate across organizational and technical boundaries (i.e. various operating systems or security platforms)
  129. 129. Federation - Example Account Number and PIN Home Bank Network Visiting Bank Network Funds Network of Trust Federated ATM Network
  130. 130. WS-Federation  The primary goal : “Single Sign On” access across trust domains using identities from the different domains.  WS-Federation defines a model for this by building on the WS-* security specifications:  Brokering trust  Sign out messages  Attribute service  Pseudonym service  Authorities Security Token Service (STS) – Web service that issues security tokens; makes assertions based on evidence that it trusts to whoever trusts it Identity Provider (IP) – Entity that acts as an authentication service to end requestors (an extension of a basic STS)
  131. 131. Trust Topologies  Federation approach must address different trust topologies:  Model existing business practices  Leverage existing infrastructure  Sample topologies - Direct trust - Exchange - Validation - Indirect trust - Delegation
  132. 132. Direct Trust – Token Exchange Trust Get identity token Get access token1 3 2 IP/STS IP/STS Requestor Resource
  133. 133. Direct Trust – Token Validation Trust Get identity token Get access verification 1 2 3 IP/STS IP/STS Requestor Resource
  134. 134. Indirect Trust C trusts B which vouches for A who vouches for client 1 3 C B A IP/STS IP/STS IP/STS Requestor Resource 2
  135. 135. Delegation Trust 1 3 2 Trust 5 4 IP/STS IP/STS IP/STS Requestor ResourceResource
  136. 136. Attribute Service  Scenario: You ask a weather service for the current weather (or visit a weather site); it provides a personalized response because it knows your zip code  Why it worked: - Policy indicated an attribute service - Identity information was used to find zip code - Weather service was authorized to access zip code  Specification defines the concept of an attribute service but not a specific interface
  137. 137. Attribute Service - Example Trust 1 3 2 4 Trust Zip: 12309 FN: Fred … IP/STS IP/STS Requestor Resource Attribute Service
  138. 138. Pseudonym Service  This service provides a mechanism for associating alternate identities  Pseudonym represents alternate identities - Depends on scope of request - Subject to authorization control - Can be integrated with IP/STS
  139. 139. Pseudonym Service – Example 1 Trust “Fred”  “” “”  “”1 2 3 “” IP Requestor Resource Pseudonym Service
  140. 140. Pseudonym Service – Example 2 Trust “Fred”  “” “”  “” 1 2 3 “” Requestor Resource 4 IP Pseudonym Service
  141. 141. WS-Federation Features Summary  Cross-domain trust federation  Generic token acquisition - Enables different trust topologies  Single Sign-on / Sign-off  Identity protection and privacy - Attributes and pseudonyms  End-to-end security - no HTTPs required  Integrates with existing infrastructures - Business model, token format, attribute stores, directory services  Together with WS-* specifications, provides a rich fabric for building secure, reliable, transacted systems across federation boundaries
  142. 142. WS-SecureConversation  Generally a single message is exchanged between the sender and receiver in a web services interaction.  It is possible that the sender and receiver need to exchange multiple messages.  WS-Security provides for only single message security.  WS-SecureConversation defines mechanisms to allow nodes (sender/receiver) to exchange more than one message.
  143. 143. WS-SecureConversation  Participants establish a shared context (SecurityContextToken) - Context contains keys and other information - Has an identifier – used in subsequent messages - Optionally has creation/expiry timestamps  Context can be established in a variety of ways - Using WS-Trust - Having one party create the context - Through negotiation
  144. 144. Reliable Messaging Messaging
  145. 145. WS-ReliableMessaging  Ws-ReliableMessaging specification defines a messaging protocol to identify, track, and manage the reliable delivery of messages between two parties, a source and a destination.  It is extensible and allows additional functionality such as security to be tightly integrated. It can integrate with and complements the WS-Security, WS- Policy and other Web Service specifications.  The WS-RM protocol defines and supports a number of delivery assurances: - AtLeastOnce: Each message will be delivered at least once. Messages can be delivered more than one. If message is not delivered, an error is raised. - AtMostOnce: Each message will be delivered at the most once. Messages may not be delivered to destination, but destination will not get duplicate messages. - ExactlyOnce: Each message will be delivered to destination exactly once. Destination will not get duplicate messages. If message is not received, an error will be raised. - InOrder: Messages will be delivered to the destination retaining the order in which they were set by the sender.
  146. 146. Reliable Messaging Model
  147. 147. Example Message Exchange Sender Destination Establish Protocol Preconditions (Policy exchange, endpoint resolution, establishing trust) Create Sequence Create Sequence Response (Identifier= Message 1 Message 2 Message 3, LastMessage Sequence Acknowledgement (Acknowledgement Range=1,3) Message 2, AckRequested Sequence Acknowledgement (Acknowledgement Range=1..3) Terminate Sequence
  148. 148. Transaction Management Transactions
  149. 149. WS-Coordination  WS-Coordination specification defines mechanisms for transactional interoperability between web services domains and provides a means to compose transactional quality of services into web services applications.  The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services. The specification describes the definition of the structure of the context and the requirements for propagating context between cooperating services.  A business process may encompass more than one web services. Interaction with these services can be synchronous/asynchronous, short-lived/long-lived. The transactional semantics in terms of ACID properties compliance would change depending upon the type and duration of interaction with a web service.  Web Services standards have defined two different specifications based on the coordination types (i.e. period of interaction between the participants): - WS-AtomicTransaction (WS-AT): short duration, ACID transactions - WS-BusinessActivity (WS-BA): longer running business transactions
  150. 150. WS-Coordination - contd  The coordination framework is supposed to provide the following services: - Activation Service: -- Activation Service creates the CoordinationContext that is used in the subsequent stages - Registration Service: used by the participants to register with the coordinator for a given coordination protocol - Coordination Protocol Service: Defines the coordination protocol used depending upon the coordination type.  Each message sent by a participant contains CoordinationContext. It has a unique identifier, pointer to participant’s registration service and coordination type.
  151. 151. WS-AtomicTransaction  WS-AtomicTransaction (WS-AT) specification defines the guidelines which allow multiple web services to participate in an atomic transaction.  Web Services participating in WS-AT are - Short duration interactions; executed within limited trust domains - Satisfy ACID properties  WS-AT coordination protocols are: - Completion: The completion protocol initiates the commit/abort processing. - Two-Phase Commit (2PC): The 2PC protocol coordinates registered participants to reach a commit or abort decision. The 2PC protocol has two variants -- Volatile 2PC: Participants managing volatile resources such as cache etc -- Durable 2PC: Participants managing durable resources such as database etc Note a participant MAY register for more than one of these protocols
  152. 152. WS-AT Coordination Protocol – Completion Protocol The Completion protocol is used by an application to tell the coordinator to either try to commit or abort an Atomic Transaction. After the transaction has completed, a status is returned to the application. A Completion protocol coordinator MUST be the root coordinator of an Atomic Transaction. The Registration service for a subordinate coordinator MUST respond to an attempt to register for this coordination protocol with the WS-Coordination fault Cannot Register Participant. A coordination service that supports an Activation service MUST support the Completion protocol.
  153. 153. WS-AT Coordination Protocol – 2PC Protocol The Completion protocol is used by an application to tell the coordinator to either try to commit or abort an Atomic Transaction. After the transaction has completed, a status is returned to the application. A Completion protocol coordinator MUST be the root coordinator of an Atomic Transaction. The Registration service for a subordinate coordinator MUST respond to an attempt to register for this coordination protocol with the WS-Coordination fault Cannot Register Participant. A coordination service that supports an Activation service MUST support the Completion protocol.
  154. 154. WS-AT Example  STEP 1: On completion of work, the Completion participant initiates the commit process by sending a Commit message to the coordinator.  STEP 2: The coordinator initiates the prepare phase on the Volatile2PC participants by sending a Prepare message. Each participant signals the successful completion of the prepare phase by responding with a Prepared Message.  STEP 3: When all Prepared messages are received from Volatile2PC participants, the coordinator initiates the prepare phase on the Durable2PC participants by sending a Prepare message.  STEP 4: When all Prepared messages are received from Durable2PC participants, the coordinator decides to commit, sends the Committed message to the Completion participant, and sends the Commit message to both Volatile2PC and Durable2PC participants. There is no ordering constraints among steps 4a, 4b, 4c.
  155. 155. WS-BusinessActivity  WS-BusinessActivity (WS-BA) specification defines the guidelines which allow multiple web services to participate in a long running transaction.  Long running transactions/business activities show the following characteristics - A business activity may consume many resources over a long duration. - There may be a significant number of atomic transactions involved. - Individual tasks within a business activity can be seen prior to completion of the business activity, their results may have an impact outside the system boundary. - Responding to a request may take a long time. Human approval, assembly, manufacturing, or delivery may have to take place before a response can be sent. - In a case where a business exception requires an activity to be logically undone, abort is not sufficient. Exception handling mechanisms may require business logic, in the form of a compensating transaction, to reverse the effects of a previous task.
  156. 156. WS-BusinessActivity - contd  WS-BA coordination types: - AtomicOutcome: A coordinator MUST direct all participants to either close or compensate. - MixedOutcome: A coordinator MUST direct all participants to an outcome but MAY direct individual participant to close or compensate.  All Business Activity coordinators must implement AtomicOutcome coordination type. Implementation of MixedOutcome coordination type is optional.  WS-BA coordination protocols: - BusinessAgreementWithParticipantCompletion: Under the BusinessAgreementWithParticipantCompletion protocol, a child activity is initially created in the Active state; if it finishes the work it was created to do and no more participation is required within the scope of the BA (such as when the activity operates on immutable data), then the child can unilaterally send an exited message to the parent. However, if the child task finishes and wishes to continue in the BA then it must be able to compensate for the work it has performed. In this case it sends a completed message to the parent and waits to receive the final outcome of the BA from the parent. This outcome will either be a close message, meaning the BA has completed successfully or a compensate message indicating that the parent activity requires that the child task reverse its work.
  157. 157. WS-BusinessActivity - contd  WS-BA coordination protocols contd: - BusinessAgreementWithCoordinatorCompletion: The BusinessAgreementWithCoordinatorCompletion protocol is identical to the BusinessAgreementWithParticipantCompletion protocol with the exception that the child cannot autonomously decide to end its participation in the business activity, even if it can be compensated. Rather the child task relies upon the parent to inform it when the child has received all requests for it to perform work which the parent does by sending the complete message to the child. The child then acts as it does in the BusinessAgreementWithParticipantCompletion protocol.
  158. 158. How Business Activities differ from Atomic Transactions?  Exception Handling In a business activity, the coordinator needs to handle an exception by retrying or selecting an alternative strategy or by aborting the activity (this may require explicit compensating transactions to be invoked) in order to achieve a defined business goal. In an atomic transaction, exception are handled via retries or aborts. Atomic transactions do not require special programmatic handling.  Duration A business activity occurs over many minutes, days, weeks. An atomic transaction typically is instantaneous.  Isolation Unlike an atomic transaction, a business activity does not hold locks and therefore has weaker isolation characteristics. In business activities, intermediate steps become visible outside the system boundary even if the activity is partially complete.  Durability Business activities span long time spans, hence post intermediate step completions, their state is persisted, unlike atomic transactions where intermediate steps are not persisted.  Diverse operational characteristics Unlike atomic transactions, business activities do not expect their participants to be available simultaneously.
  159. 159. Thank You