SOA Standards Service Profile
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
SOA Standards Service Profile
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
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 iiSOA Standards Version: 1.1
Service Profile Date: 2013-02-01
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.
eHealth Ontario Confidential iiiSOA Standards Version: 1.1
Service Profile Date: 2013-02-01
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.
eHealth Ontario Confidential ivSOA Standards Version: 1.1 Service Profile Date: 2013-02-01 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. eHealth Ontario Confidential 1
SOA Standards Version: 1.1 Service Profile Date: 2013-02-01 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
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
3.1 Business Facing Properties
3.1.1 Business Service
Business Service Description
Service name Unique, indicative natural language name that business will use for service
(business)
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 A list of service capabilities (operations), without parameters, and a brief and
(Operations) 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 List of formally defined business objectives or strategies or targets that this
Support service will support.
eHealth Ontario Confidential 3SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
Business Service Description
Stability (over next … Predicted changes need within next (n) years, and/or Expected life, if this is a
years) 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)
eHealth Ontario Confidential 4SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
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 Continuous Availability | High Availability | Continuous Operation | Disaster
Characteristic (class) 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
eHealth Ontario Confidential 5SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
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 List of “required” services that this service is obliged to depend upon.
services Any implementation of the service must interact with the required
services. The operation dependencies may make this dependency
(invocation dependencies)
more explicit.
Other Specified Other specified dependencies, e.g. integrity dependencies.
Dependencies
Developers can “code to” the knowledge of specified dependencies,
(integrity 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 Link Consumer Implementation Guide document.
Guide
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:
eHealth Ontario Confidential 6SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
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 ATNA | XDS | DSUB | PIX | PDQ
Standard
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 7SOA Standards Version: 1.1 Service Profile Date: 2013-02-01 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 Description Inputs / Interaction Transaction Response Capability Outputs Exceptions Type Volumes Time (Operation) (MEP) Name eHealth Ontario Confidential 8
SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
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 Duration of time and an agreed-to service level within which a business
Objective (RPO) process must be restored after a disaster (or disruption)
Recovery Point The point in time to which data must be recovered with an agreed-to
Objective (RTO) “acceptable loss”
Endpoint Description
Endpoint URLs and For each environment:
Environments
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 9SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
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.
eHealth Ontario Confidential 10SOA Standards Version: 1.1
Service Profile Date: 2013-02-01
6 References
ID Reference Location/Description
Ref SOA Principles Web http://serviceorientation.com/index.php/serviceorientation/service_discoverability
Site: Service
Discoverabilty
Ref2 NCI SAIF Service https://wiki.nci.nih.gov/display/SAIF/6.4+-+Catalog+of+NESI+Precepts
Inventory Blueprint https://wiki.nci.nih.gov/display/EAWiki/SOA+Service+Taxonomy
Ref3 High Availability http://teamsites/sites/ea/EA%20Document%20Library/1/High%20Availability/Definition
Definitions s%20V1%200-0%20(2013-03-04).docx
Ref4 Logical Architecture AP-SLO-001: Performance:
Principals AP-SLO- Applications, services and transaction orchestrations need to be designed in
001: Performance 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 http://teamsites/sites/ea/SOA%20Methodology%20Library/1/SOA-
Taxonomy Policy-ServiceTaxonomyV1.3.doc
Ref6 SOA Service http://teamsites/sites/ea/SOA%20Methodology%20Library/1/SOA-
Naming Conventions Policy-ServiceNamingConventionsV1.1.doc
Ref7 Projected Volumes http://teamsites/sites/ea/SOA%20Methodology%20Library/1/Projected
Template VolumesTemplate.xls
Ref8 Capturing Service http://www.ibm.com/developerworks/websphere/techjournal/1112_clar
Characteristics k/1112_clark.html
http://www.ibm.com/developerworks/websphere/techjournal/1201_clar
k/1201_clark.html
eHealth Ontario Confidential 11You can also read
