SOA Standards Service Profile - ehealthontario.on.ca · SOA Standards Version: 1.1 Service Profile...

SOA Standards

Service Profile

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



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.

http://teamsites/sites/ea/SOA%20Methodology%20Library/



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.

http://www.ietf.org/rfc/rfc2119.txt



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.




3 Service Attributes

Tables below provide description of services attributes that would be documented at different

stages of SDLC and are grouped by views.




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.




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)




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




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:




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




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.)




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.




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

http://serviceorientation.com/index.php/serviceorientation/service_discoverability

https://wiki.nci.nih.gov/display/SAIF/6.4+-+Catalog+of+NESI+Precepts

https://wiki.nci.nih.gov/display/EAWiki/SOA+Service+Taxonomy



http://teamsites/sites/ea/SOA%20Methodology%20Library/1/SOA-Policy-ServiceTaxonomyV1.3.doc

http://teamsites/sites/ea/SOA%20Methodology%20Library/1/SOA-Policy-ServiceTaxonomyV1.3.doc

http://teamsites/sites/ea/SOA%20Methodology%20Library/1/SOA-Policy-ServiceNamingConventionsV1.1.doc

http://teamsites/sites/ea/SOA%20Methodology%20Library/1/SOA-Policy-ServiceNamingConventionsV1.1.doc

http://teamsites/sites/ea/SOA%20Methodology%20Library/1/ProjectedVolumesTemplate.xls

http://teamsites/sites/ea/SOA%20Methodology%20Library/1/ProjectedVolumesTemplate.xls

http://www.ibm.com/developerworks/websphere/techjournal/1112_clark/1112_clark.html




SOA Standards Service Profile - ehealthontario.on.ca · SOA Standards Version: 1.1 Service Profile...

Documents

Transcript of SOA Standards Service Profile - ehealthontario.on.ca · SOA Standards Version: 1.1 Service Profile...