SOA Standards - Patterns

SOA Standards - Patterns

Contents 1 Message Exchange Patterns... 1 1.1 Synchronous request/response... 1 1.2 Synchronous Request/Acknowledgement... 1 1.3 Request/Acknowledgement/Poll... 2 1.4 Request/Acknowledgement/Callback... 3 1.5 Handling large payloads... 4 2 Service Implementation Patterns... 5 2.1 Workflow Connector... 5 2.2 Service Interceptor... 6 2.3 Canonical Message Model... 7 2.4 Policy Centralization (Non-Functional)... 9 2.5 Business Activity Monitoring (BAM)... 10 2.6 Business Rules Centralization... 12 2.7 Service Monitoring... 13 2.8 Configuration Management... 14 3 References... 15 ehealth Ontario Confidential ii

Document Location Document Revision History Version Date Author Description 1.0 2013-6-25 B.Platt Initial Draft Terminology Used in this Document This document uses the following terminology: MUST: This word means that the definition is an absolute standard. MUST NOT: This phrase means that the definition is an absolute prohibition. SHOULD: This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT: This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. MAY: This word means that the standard is optional. The service developer may choose to include the item based on the needs of their design. The above definitions are loosely based on the RFC 2119 Key words for use in RFCs to Indicate Requirement Levels as described at: http://www.ietf.org/rfc/rfc2119.txt ehealth Ontario Confidential iii

1 Message Exchange Patterns ehealth supports following Message Exchange Patterns (MEP). 1.1 Synchronous request/response Request/Response is used when the client must have an immediate response or wants the service to complete a task without delay. Request/Response begins when the client establishes a connection to the service. Once a connection has been established, the client sends its request and waits for a response. The service processes the request as soon as it is received and returns a response over the same connection. 1.2 Synchronous Request/Acknowledgement Request/Acknowledge services typically perform the following steps: 1. Receive request 2. Authenticate client credentials (optional) 3. Authorize client for requested operation (optional) ehealth Ontario Confidential 1

4. Validate request (optional) 5. Generate Request Identifier or URI 6. Store and Forward request 7. Return an acknowledgement *You can also use a Request/No Acknowledgement commonly known as fire and forget. 1.3 Request/Acknowledgement/Poll Request/Acknowledge/Poll variation on the Request/Acknowledgement pattern allows clients to poll for results at their leisure ehealth Ontario Confidential 2

Request/Acknowledgement/Poll variation on this Request\Acknowledgement pattern allows clients to poll for results at their leisure 1.4 Request/Acknowledgement/Callback Request/Acknowledgement/Callback can be used when the status updates or final results for a request must be delivered as soon as possible to one or more recipients. In this variation of Request/Acknowledgement, the request processor pushes a Representation or Callback Message to a Callback Service. ehealth Ontario Confidential 3

1.5 Handling large payloads When the size of the payload start to negatively affect infrastructure and service scalability or start to affect performance of other services, the payload will be handled through 'Claim Check' (http://www.eaipatterns.com/storeinlibrary.html) or 'Content Enricher/Filter' (http://www.eaipatterns.com/dataenricher.html, http://www.eaipatterns.com/contentfilter.html) patterns. ehealth Ontario Confidential 4

2 Service Implementation Patterns 2.1 Workflow Connector If services need more than complex service orchestration such as complex looping constructs, embedded business rules, human workflow, a long-running process that maintains state for( minutes, hours, weeks or more), processes that need compensating transactions, then these services should be orchestrated in a Workflow engine as a business process. Workflow engine technologies make it possible for developers to create Process Managers that govern entire workflow life cycles from process instantiation to termination. ehealth Ontario Confidential 5

2.2 Service Interceptor ehealth Ontario Confidential 6

2.3 Canonical Message Model The Canonical Message Model (CMM) will reduce the number of data dependencies between integrating applications. See http://soapatterns.org/design_patterns/canonical_schema 1. The CMM will be constructed from data contained in both requester and provider proprietary message models and converted into a normalized canonical message model format. This is different from developing an enterprise canonical model because only data relevant to the message is considered. 2. HL7 messages will act as a CMM between the requester and provider services or will be a part of the requester or provider message model. 3. For each requester there will be a transformation of its proprietary model to the CIMM (Canonical Message Model). 4. For each provider there will be a transformation of its proprietary model to the CIMM (Canonical Message Model). 5. Individual application and service will retain their proprietary message models. 6. The ESB will provide an enforcement point for centralized management and governance of all the transformations. See http://soapatterns.org/compound_patterns/enterprise_service_bus 7. Reusable transformation logic contained by components in the ESB will be leveraged with the CIMM instead of the service proprietary message models. These components can be dynamically configured by policies that can be looked up in the service registry and repository. ehealth Ontario Confidential 7

Figure 1: Problems with direct transformation between service requesters and consumers Figure 1: CIMM transformation in the ESB ehealth Ontario Confidential 8

2.4 Policy Centralization (Non-Functional) The SLA need not be unique to the service consumer and it is preferable that it applied to a particular class of consumers. Registered and monitored SLAs will enable Impact Analysis, Dependency tracking and Capacity Planning. ehealth Ontario Confidential 9

2.5 Business Activity Monitoring (BAM) When near real-time summary of business activities (dashboard) or business intelligence reports are needed by operations managers and upper management then the business processes need to be instrumented to report KPI s and metrics to a Business Activity Monitor (BAM) platform. When orchestrated services in a business process need to publish near real-time analytics to a dashboard or collect data for future business intelligence reports the Key Performance Metrics (KPI) along with associated metrics should be instrumented in the business process and transmitted to a Business Activity Monitoring (BAM) platform. Near Real-time Dashboard and Business Intelligence Reports ehealth Ontario Confidential 10

ehealth Ontario Confidential 11

2.6 Business Rules Centralization Business rules are abstractions of the policies and practices of eho that can be reused and governed. See Rules Centralization http://soapatterns.org/design_patterns/rules_centralization There are many key benefits to centralizing business rules: Business rules can be utilized across the entire application portfolio as services. Duplicated business rules can be identified across the application portfolio and replaced thereby reducing maintenance costs. Business processes are more agile when they contain business rules the can be dynamically reconfigured. Provides a foundation for rapid reconfiguration, responsiveness to changing needs, flexibility to alter workflow. ehealth Ontario Confidential 12

2.7 Service Monitoring Service Monitor and Audit Facility Overview: 1. The Service Monitor is composed of 3 components: a. The Collect component collects and stores incoming statuses (including performance, faults, number of calls, and data transferred) and provides summary and detail reports. b. The Monitor component continuously monitors the data collected and can execute rules to validate and monitor the behavior of services. Example: Check service performance against a SLA. 2. The Act component will notify support staff once a problem has occurred. It can send commands either automatically or by the support staff such as restarting a service or changing an associated policy for the service. 3. Common Service Reporting should include metrics for: a. Accuracy - error rate of the service. Report average number of errors over a given time period. b. Availability - percentage of time the system is available outside of planned maintenance. c. Capacity - number of concurrent requests handled by the service in a given time period. Latency - maximum amount of time between the arrival of a request and the completion of that request ehealth Ontario Confidential 13

2.8 Configuration Management There are three patterns that can be used to configure the service: leverage capabilities of ESB or any other container the service is deployed into 'pull' configuration from centrally deployed configuration server 'push' configuration from centrally deployed server to the service implementation ehealth Ontario Confidential 14

3 References ID Reference Location/Description Ref Ref Ref Ref SOA Patterns Web Site: Decomposed Capability SOA Patterns Web Site: Rules Centralization SOA Patterns Web Site: Contract De-normalization SOA Patterns Web Site: Validation Abstraction http://soapatterns.org/design_patterns/decomposed_capability http://soapatterns.org/design_patterns/rules_centralization http://soapatterns.org/design_patterns/contract_denormalization http://soapatterns.org/design_patterns/validation_abstraction ehealth Ontario Confidential 15