Post on 24-Jul-2018
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential ii
1 Contents
1 Purpose .................................................................................................................................... 1
2 Scope ....................................................................................................................................... 1
3 Service Attributes .................................................................................................................... 2
3.1 Business Facing Properties............................................................................................... 3
3.1.1 Business Service ....................................................................................................... 3
3.1.2 Service Level Definition ........................................................................................... 5
3.2 Technical Service Properties ............................................................................................ 6
3.3 Technical Capabilities (Operations) Properties................................................................ 8
3.4 Operational Service Constructs Properties ....................................................................... 9
4 Service Profile Completion in Checkpoints .......................................................................... 10
5 Example ................................................................................................................................. 10
6 References ............................................................................................................................. 11
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential iii
Document Location
http://teamsites/sites/ea/SOA%20Methodology%20Library/
Document Revision History
Version Date Author Description
1.0 2012-10-29 E.Neroslavskaya Initial version, TBD alignment with UGP templates links, Example
1.1 2013-02-01 Sharon MacMillan Minor edits.
1.2 2013-03-10 E.Neroslavskaya Expanded Service Definition Levels, Availability, Transaction Volumes and Capability (Operation) attributes.
1.3 2013-05-10 M.Lazic Incorporated feedback from Business Analysts in business attributes
1.3.1 2013-06-06 E.Neroslavskaya Added technical attributes (in-sync with Taxonomy) and Projected Volumes template.
1.3.2 2013-07-31 T.B. Added Service Operation’s Exceptions.
1.4 2013-11-01 V.Olenin
1.5 2013-11-03 E.Neroslavskaya Added high level pictire
1.6 2013-11-04 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.
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential iv
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: http://www.ietf.org/rfc/rfc2119.txt.
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 1
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 delivery-
related 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.
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 2
3 Service Attributes
Tables below provide description of services attributes that would be documented at different
stages of SDLC and are grouped by views.
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 3
3.1 Business Facing Properties
3.1.1 Business Service
Business Service Description
Service name
(business)
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.
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 4
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 Specify the ownership and hosting of the service based on segment it is in.
Provincial | cGTA | cNEO | cCWO
Privacy Disclosure PI | PHI | PI-PHI | None
Visibility External | Internal | Native (see Ref5 for classification description)
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 5
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 Description
Response Time Average response time and Range of acceptable response times as per
SLA.
Maximum Throughput 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.
Primary Operating
Characteristic (class)
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 Message Size range as per SLA for request and response
Concurrency 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
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 6
3.2 Technical Service Properties
Technical Service Version Description
Service name (technical) Name used in technology definition (e.g. WSDL name for a Web
service.).
Technical Owner Team responsible for provisioning (specifying, implementing, certifying)
this service
Architecture Layer process | capability | core-business | underlying | utility | infrastructure
Refer to Ref5 Service Taxonomy for classification definitions.
Version Version number of service currently being documented Major.Minor
Dependent Services 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]
Dependencies on other
services
(invocation dependencies)
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)
Other specified dependencies, e.g. integrity dependencies.
Developers can “code to” the knowledge of specified dependencies,
since these dependencies are considered to be permanent.
Interface Specification Link to Service Interface Specification document. Include functional
flows in the specs.
Consumer Implementation
Guide Link Consumer Implementation Guide document.
Mapping Link to Mapping Specification document if transformation is required to
native format.
Interface Contract Link to service interface contract e.g., WSDL
Authentication Any combination of:
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 7
Technical Service Version Description
IP | Mutual SSL | SAML | SSL | STS
Authorization OneID Group | PDP | IP
Batch mode 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 Refer to Ref5 Service Taxonomy for
classification definitions.
Service Protocol SOAP1.1 | SOAP 1.2| REST Refer to Ref5 Service Taxonomy for
classification definitions.
Service Format XML | ER7 | JSON | Binary |XOP Refer to Ref5 Service Taxonomy
for classification definitions.
WS* Standards / Policy 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.
Healthcare Payload
Standard 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
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 8
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
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 9
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 Description
Maintenance Windows SLA and OLA
Service Manager Person responsible operating this service
Recovery Time
Objective (RPO)
Duration of time and an agreed-to service level within which a business
process must be restored after a disaster (or disruption)
Recovery Point
Objective (RTO)
The point in time to which data must be recovered with an agreed-to
“acceptable loss”
Endpoint Description
Endpoint URLs and
Environments 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.)
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 10
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 M M M M M M M M M M
Technical O M M* M M M M M
Operational M M M M M M
5 Example
TBD: Attach filled-in sample Service Profile.
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
eHealth Ontario Confidential 11
6 References
ID Reference Location/Description
Ref SOA Principles Web Site: Service Discoverabilty
http://serviceorientation.com/index.php/serviceorientation/service_discoverability
Ref2 NCI SAIF Service Inventory Blueprint
https://wiki.nci.nih.gov/display/SAIF/6.4+-+Catalog+of+NESI+Precepts
https://wiki.nci.nih.gov/display/EAWiki/SOA+Service+Taxonomy
Ref3 High Availability Definitions
http://teamsites/sites/ea/EA%20Document%20Library/1/High%20Availability/Definitions%20V1%200-0%20(2013-03-04).docx
Ref4 Logical Architecture Principals AP-SLO-001: Performance
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-to-system 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)
Ref5 SOA Service Taxonomy
http://teamsites/sites/ea/SOA%20Methodology%20Library/1/SOA-
Policy-ServiceTaxonomyV1.3.doc
Ref6 SOA Service Naming Conventions
http://teamsites/sites/ea/SOA%20Methodology%20Library/1/SOA-
Policy-ServiceNamingConventionsV1.1.doc
Ref7 Projected Volumes Template
http://teamsites/sites/ea/SOA%20Methodology%20Library/1/Projected
VolumesTemplate.xls
Ref8 Capturing Service Characteristics
http://www.ibm.com/developerworks/websphere/techjournal/1112_clar
k/1112_clark.html
http://www.ibm.com/developerworks/websphere/techjournal/1201_clar
k/1201_clark.html