SOA Standards Service Profile

Transcription

1 SOA Standards Service Profile

2 1 Contents 1 Purpose Scope Service Attributes Business Facing Properties Business Service Service Level Definition Technical Service Properties Technical Capabilities (Operations) Properties Operational Service Constructs Properties Service Profile Completion in Checkpoints Example References ehealth Ontario Confidential ii

3 Document Location Document Revision History Version Date Author Description E.Neroslavskaya Initial version, TBD alignment with UGP templates links, Example Sharon MacMillan Minor edits E.Neroslavskaya Expanded Service Definition Levels, Availability, Transaction Volumes and Capability (Operation) attributes M.Lazic Incorporated feedback from Business Analysts in business attributes E.Neroslavskaya Added technical attributes (in-sync with Taxonomy) and Projected Volumes template T.B. Added Service Operation s Exceptions V.Olenin E.Neroslavskaya Added high level pictire A.Parkitny Updated formatting and typographic items. 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. ehealth Ontario Confidential iii

4 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 RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, as described at: ehealth Ontario Confidential iv

5 1 Purpose The purpose of the Service Profile is to define the metadata to be collected about ehealth Ontario s HIAL-exposed services. Information assembled in the Service Profile will form basis for records in the SOA Service Catalog and will promote consistency in service documentation. For services to be positioned as IT assets with repeatable ROI, they need to be easily identified, discovered and understood when opportunities for reuse present themselves. The SOA Principles state that the Service Discoverability design principle is one of the most fundamental of the eight service-oriented design principles. It is by means of rich metadata (Service Profile) that services can be effectively discovered and interpreted (Ref1. SOA Principles Website). Nowadays, design time discoverability is becoming more and more important, and service metadata is one of the key concepts for defining discoverable services. The Service Profile initially acts as repository of metadata when a service is first conceptualized during the early stages of analysis, and later provides details for service design and deliveryrelated documents used during subsequent lifecycle phases. For description of types of services and their relationship to other artifacts, please see ' SOA Standards - Services Introduction - v0.01.doc' document. 2 Scope The standards in this document are intended to be applied by different project teams to consistently document the services they deliver. Delivery of consistent descriptions will be verified at each stage of the Check pointing Process and associated SOA templates. Note: Services that have not been designated as members of the HIAL Service Catalog are not required to use the metadata standards specified in this document. However, there may be benefit in doing so to promote consistency, as there is the possibility that they may eventually be designated as enterprise services. ehealth Ontario Confidential 1

6 3 Service Attributes Tables below provide description of services attributes that would be documented at different stages of SDLC and are grouped by views. ehealth Ontario Confidential 2

7 3.1 Business Facing Properties Business Service Business Service Service name (business) Description Unique, indicative natural language name that business will use for service Must be compliant with naming conventions ( See Ref6 ) Aliases Other names for the service, which might be used by someone searching for this service. Functional Domain The business domain that the service belongs to. Should be populated from the Service Taxonomy classification. ( See Ref5 ) Service Description Brief and precise description of the service with emphasis on what the service is all about, scope and the value it provides Capabilities (Operations) A list of service capabilities (operations), without parameters, and a brief and precise description of each one. It indicates the envisioned scope of functionality, and gives the reader a quick overview of what the service operation is expected to do when fully implemented. Must be compliant with naming conventions ( See Ref6 ) Service Owner Business/Program Unit that approves any changes and roadmap for the service (e.g. IAP) Target Consumers Organizations, users, systems that service is intended for. Known and projected clients ( e.g 5 laboratory sites with a total of 200 registered users) Business Processes List of end-to-end Business Processes supported by this service. Business Objective Support List of formally defined business objectives or strategies or targets that this service will support. ehealth Ontario Confidential 3

8 Business Service Description Stability (over next years) Predicted changes need within next (n) years, and/or Expected life, if this is a temporary service Documentation Link to SharePoint documentation site (must be centralized site for all service docs). Provide one link if all documents are in same folder. Link to Charter: Link to BRD: Link to FDD: Link to TDD: Link to Operating Books: Federation Segment Privacy Disclosure Visibility Specify the ownership and hosting of the service based on segment it is in. Provincial cgta cneo ccwo PI PHI PI-PHI None External Internal Native (see Ref5 for classification description) ehealth Ontario Confidential 4

9 3.1.2 Service Level Definition Targeted service levels should be defined by Business Users early in the planning stage. For definition of availability, RTO, RPO please refer to Ref3: High Availability Definitions. Service Level Definition Response Time Maximum Throughput Primary Operating Characteristic (class) Description Average response time and Range of acceptable response times as per SLA. An order-of-magnitude estimate of the maximum number of times the service will perform any of its operations in a given time period. For example, maximum of 100 query transactions per second. Continuous Availability High Availability Continuous Operation Disaster Recovery Refer to Ref3 High Availability Definitions Target Availability e.g 99.99% Transaction Volumes Link to the Transaction Volumes document, containing current and projected transaction volumes by client and by time of the day. (Use template provided below Ref7 ) and publish it along with documentation. Message Sizes Concurrency Message Size range as per SLA for request and response The number of requests that can be processed at the same time. Performance Category Immediate User Waiting User Transparent Large Objects Refer to Ref4 for definitions ehealth Ontario Confidential 5

10 3.2 Technical Service Properties Technical Service Version Service name (technical) Technical Owner Architecture Layer Version Dependent Services Dependencies on other services (invocation dependencies) Description Name used in technology definition (e.g. WSDL name for a Web service.). Team responsible for provisioning (specifying, implementing, certifying) this service process capability core-business underlying utility infrastructure Refer to Ref5 Service Taxonomy for classification definitions. Version number of service currently being documented Major.Minor List of dependent services and/or dependent applications, which currently invoke this service s operations [It is best if this can be supplied through an automated query on Service Catalog or Production Software] List of required services that this service is obliged to depend upon. Any implementation of the service must interact with the required services. The operation dependencies may make this dependency more explicit. Other Specified Dependencies (integrity dependencies) Interface Specification Consumer Implementation Guide Other specified dependencies, e.g. integrity dependencies. Developers can code to the knowledge of specified dependencies, since these dependencies are considered to be permanent. Link to Service Interface Specification document. Include functional flows in the specs. Link Consumer Implementation Guide document. Mapping Link to Mapping Specification document if transformation is required to native format. Interface Contract Authentication Link to service interface contract e.g., WSDL Any combination of: ehealth Ontario Confidential 6

11 Technical Service Version Authorization Batch mode Description IP Mutual SSL SAML SSL STS OneID Group PDP IP Does the interface process individual business actions, or does it take a group of actions at a time and process them together Batch Individual Service Transport MLLP HTTP HTTPS MQ classification definitions. Refer to Ref5 Service Taxonomy for Service Protocol SOAP1.1 SOAP 1.2 REST classification definitions. Refer to Ref5 Service Taxonomy for Service Format XML ER7 JSON Binary XOP for classification definitions. Refer to Ref5 Service Taxonomy WS* Standards / Policy Healthcare Payload Standard Link Service Policies expressed as WS-Policy, WS-Security Policy document; include WS-Topics if service is Notification Producer List any WS* standards used in the service. ATNA XDS DSUB PIX PDQ Refer to Ref5 Service Taxonomy for classification definitions. Service Payload Standard ebxml CeRX HL7v2 HL7v3 Refer to Ref5 Service Taxonomy for classification definitions ehealth Ontario Confidential 7

12 3.3 Technical Capabilities (Operations) Properties Service acts as a container for capabilities, each individual capability represented in the following table. Guidelines: Description - Brief and precise description of functionality Inputs/Outputs - Input / Output parameters, at a minimum, indicate high-level parameters, example usage and a link to parameter specifications document. Exceptions - A list of exceptions for each service capability (operation) that will contain following: Exception Name, Error Code and Exception Description. Each operation s exception provided have to include following: Exception Name, Error Code (exception related unique error code/id) and Exception Description (a brief & precise description/definition of the exception as well as the reason the exception would be raised). Interaction Type - Refer to Ref5 Service Taxonomy for classification Message Exchange patterns definitions. Transaction Volumes - Link to the Transaction Volumes document (Transaction Volumes Template), containing current and projected transaction volumes by client and by time of the day or actual numbers. Response Time - Average response time and Range of acceptable response times as per SLA Technical Capability (Operation) Name Description Inputs / Outputs Exceptions Interaction Type (MEP) Transaction Volumes Response Time ehealth Ontario Confidential 8

13 3.4 Operational Service Constructs Properties The Operational view of the service information is associated with Service Endpoint and Service Level Definition. Service Level Definition Maintenance Windows Service Manager Recovery Time Objective (RPO) Recovery Point Objective (RTO) Description SLA and OLA Person responsible operating this service Duration of time and an agreed-to service level within which a business process must be restored after a disaster (or disruption) The point in time to which data must be recovered with an agreed-to acceptable loss Endpoint Endpoint URLs and Environments Description For each environment: Gateway Service endpoint url for invocation Backbone Service endpoint url for invocation Native Service endpoint url for invocation Deployment Unit Name of the deployment unit realizing service and exposing this endpoint (e.g., WSP, XML Proxy name, EAR file name etc.) ehealth Ontario Confidential 9

14 4 Service Profile Completion in Checkpoints The Service Attribute views correlate with the Check pointing Process and the Software Development Lifecycle (SDLC): The Business view is relevant for all phases of UGP, SDLC, and Operations and End-of- Life (EOL); The Technical view is relevant at Checkpoint 3 (CP3) Physical Architecture gate to EOL; The Operational view is relevant during the build/test phase that leads up to Checkpoint 4 (CP4). The following table illustrates at which stage it is expected that the SOA Service Profile and Service Catalog will be updated with information: M Mandatory, O Optional, * fully described View CP0 CP1 CP2 CP3 DIT FIT SIT UAT PST Prod Business Technical Operational M M M M M M M M M M O M M* M M M M M M M M M M M 5 Example TBD: Attach filled-in sample Service Profile. ehealth Ontario Confidential 10

15 6 References ID Reference Location/Description Ref Ref2 Ref3 Ref4 Ref5 Ref6 Ref7 Ref8 SOA Principles Web Site: Service Discoverabilty NCI SAIF Service Inventory Blueprint High Availability Definitions Logical Architecture Principals AP-SLO- 001: Performance SOA Service Taxonomy SOA Service Naming Conventions Projected Volumes Template Capturing Service Characteristics s%20v1%200-0%20( ).docx AP-SLO-001: Performance: Applications, services and transaction orchestrations need to be designed in accordance with performance goals aligned to their context of use. Generally the following classes of expectations for performance are distinguished: - Immediate class response time for infrastructure, common services registries and others, generally applicable to services that are invoked as sub-components of a larger transaction (e.g. time synchronization, authentication, validate client/provider/location ID, validate consent); - User Waiting class response time for business application services used in contexts where end-users are typically waiting for a response in real time (e.g. list lab results, get drug profile, get client demographics, put a referral); - User Transparent class response time for business application services used in contexts where no end-user is typically waiting and the expectation of responsiveness can generally be qualified as near real time (e.g. system-tosystem back-end puts for laboratory systems); - Large Objects class response time for business application services that deal with large binary or structured data objects (> 1Mb) (e.g. get diagnostic image) Policy-ServiceTaxonomyV1.3.doc Policy-ServiceNamingConventionsV1.1.doc VolumesTemplate.xls k/1112_clark.html k/1201_clark.html ehealth Ontario Confidential 11