MODULAR PILOT
TRANSPORT DESIGN DOCUMENT
(DRAFT)
Office of the National Coordinator for Health Information Technology
Version 1.0
May 4, 2011
Prepared By:
ONC S&I RI/DP Team
DISTRIBUTION STATEMENT
The Transport Module Design is to be used by the Reference Implementation designers and
developers to design and develop the main components of the transport layer that can be
composed to provide the specified services in a scalable, extensible and reliable manner.
Modular Pilot Transport Design Document
Draft - May 4, 2011
DOCUMENT CHANGE HISTORY
Version
1.0
Date
05/04/2011
Changed By
Lockheed Martin
Items Changed Since Previous Version
First Draft
i
Modular Pilot Transport Design Document
Draft - May 4, 2011
TABLE OF CONTENTS
1.0
OBJECTIVE/PURPOSE...................................................................................................................1
2.0
REQUIREMENTS/GOALS ..............................................................................................................1
3.0
CONSTRAINTS AND ASSUMPTIONS .............................................................................................1
3.1
3.2
CONSTRAINTS ................................................................................................................................... 1
ASSUMPTIONS\ ................................................................................................................................. 2
4.0
DEPENDENCIES ............................................................................................................................2
5.0
CODE RE-USE ...............................................................................................................................2
6.0
ARCHITECTURE ............................................................................................................................3
6.1
DESIGN DIAGRAMS ............................................................................................................................ 3
6.2
SEQUENCE DIAGRAMS ........................................................................................................................ 3
6.3
INTERFACES .................................................................................................................................... 10
6.3.1 Transport Facade Interface .................................................................................................... 10
6.3.2 Certification Service Interface ................................................................................................ 10
6.3.3 State Handler Interface .......................................................................................................... 10
6.3.4 Session Handler Interface ....................................................................................................... 10
7.0
REFERENCES .............................................................................................................................. 10
LIST OF FIGURES
FIGURE 1. PACKAGE DIAGRAM ................................................................................................................................... 3
FIGURE 2 TRANSPORT CORE SYNCHRONOUS REQUEST - INITIATING GATEWAY .................................................................... 4
FIGURE 3. TRANSPORT CORE SYNCHRONOUS REQUEST - RESPONDING GATEWAY ................................................................ 5
FIGURE 4. TRANSPORT CORE - DEFERRED WORKFLOW - INITIATING GATEWAY .................................................................... 6
FIGURE 5. TRANSPORT CORE - DEFERRED WORKFLOW - RESPONDING GATEWAY - SEND ACKNOWLEDGEMENT ......................... 7
FIGURE 6. SEQUENCE DIAGRAM - TRANSPORT CORE DEFERRED RESPONSE - INITIATING GATEWAY - RECEIVE RESPONSE ............. 9
ii
Modular Pilot Transport Design Document
Draft - May 4, 2011
1.0 OBJECTIVE/PURPOSE
This document provides a high-level design of the Reference Implementation (RI) Transport
Module Core components. These components are used by Request and Response Orchestrator
components of RI Gateway to address the requirements of the Transport Module specification.
Specifically, these components are used by the initiating RI Gateway to validate the incoming
request information and to add WS-Addressing headers. In Deferred Request/response mode, these
components handle the state and session creation and maintenance.
On the Responding RI Gateway, the transport core components are used to validate the request
(general conformance), validate the namespaces, validate the WS-Addressing headers, and validate
the certificate.
2.0 REQUIREMENTS/GOALS
The goals of the Transport Core design are to:

Provide a design to address the functional requirements of Transport module.

Identify and define components for non-overlapping functionalities of Transport
Module.

Code to interfaces, not implementations.

Promote code reuse.

Achieve ease of integration.

Be extensible.

Couple loosely with other components.

Achieve ease of Unit testing and Integration testing.
3.0 CONSTRAINTS AND ASSUMPTIONS
3.1 CONSTRAINTS

The Transport Module is required to support two central architectural principles of
the Nationwide Health Information Network:

Use the public Internet – The Nationwide Health Information Network is not a
separate physical network, but a set of protocols and standards that enable secure
health information exchange via the public Internet.

Platform neutral – The Nationwide Health Information Network has adopted a stack
(web services) that can be implemented using many operating systems and
programming languages.
1
Modular Pilot Transport Design Document
Draft - May 4, 2011

The Transport Module will be based on Simple Object Access Protocol (SOAP) 1.2
messages over HyperText Transport Protocol (HTTP). All higher-level messaging
elements and attachments must be bound to a SOAP message. This excludes the use of
incompatible transport protocols such as Health Level Seven (HL7) Minimal Lower
Layer Protocol (MLLP) for National Health Information Organization (NHIO)-to-NHIO
messaging.

The NHIN Messaging Specification restricts the use of the WS-Addressing ReplyTo and
FaultTo elements to the predefined anonymous endpoint reference.

Reliable messaging should be available to support specific information exchanges, but
it is not a requirement for every NHIN service.

The cipher suite recommendation from the Organization for the Advancemnt of
Structured Information Standards (OASIS) committee for SAML2.0 over the Transport
Layer Security (TLS) protocol was for forward-looking applications to implement
TLS_RSA_WITH_AES_128_CBC_SHA, which has both speed and security strength. This
translates to the Basic128 algorithm suite as defined in the WS-SecurityPolicy and is
declared within the sp:AlgorithmSuite assertion.
3.2 ASSUMPTIONS\

Each NHIO is responsible for the authentication and authorization of its users.

Each hosting organization is capable of providing an administration point and an
information point for Access Consent Policy.

X.509 certificates will be used by all NHIOs, following a process defined by the Office
of the National Coordinator for Health Information Technology (ONC). The fact that all
certificates are issued by following the same process will serve as the basis of trust
and authentication between NHIOs; all messages between NHIOs are both signed and
encrypted using these certificates.

Transport Module does not have to define any custom SOAP faults. It is the
responsibility of the other NHIN specifications that use the Transport Module.
4.0 DEPENDENCIES
The Transport core components will use the RI Core components like Logging, Exception
Handling, Data Access Object (DAO), Utilities, etc.
5.0 CODE RE-USE

Transport Core's SOAPProcessor component can be reused by other modules for
getting the SOAP Message parts like Header, Body, etc.

Transport Core's Certification Service can be reused by Security Module for retreiving
a certificate from Keystore, etc.
2
Modular Pilot Transport Design Document
Draft - May 4, 2011
6.0 ARCHITECTURE
The intent of this design is to identify and define the interfaces the Transport Core exposes, the
interfaces that are used by the Transport Core, and to expand upon the high-level components
defined in the Transport Module Architecture document.
TransportFacade is the interface with which other modules communicate with the Transport
Core subsystem. The default implementation interacts with the other classes within the subsystem
for addressing necessary functionality. This default implementation can be extended by other
variants of Transport Core implementation.
Transport Core subsystem relies on RI Core components for logging, exception handling, utilities,
etc. Appropriate interfaces of RI core will be used by Transport Core.
6.1 DESIGN DIAGRAMS
The following diagram shows the packages where the Transport Core components reside and the
dependencies with other packages of the RI Gateway.
Figure 1. Package Diagram
6.2 SEQUENCE DIAGRAMS
The following diagram shows the sequence of operations that are performed using the Transport
core components as part of initiating a request from the Gateway.
3
Modular Pilot Transport Design Document
Draft - May 4, 2011
Figure 2 Transport Core Synchronous Request - Initiating Gateway
4
RI Transport Arch. Design
Delivery Date: May 4, 2011
The following diagram shows the sequence of operations that are performed using the Transport core components as part of responding
to a request on the Responding Gateway.
Figure 3. Transport Core Synchronous Request - Responding Gateway
5
RI Transport Arch. Design
Delivery Date: May 4, 2011
The following diagram shows the sequence of operations that are performed using the Transport core components as part of initiating a
request on the Initiating Gateway in Deferred request/response mode.
Figure 4. Transport Core - Deferred workflow - Initiating Gateway
6
RI Transport Arch. Design
Delivery Date: May 4, 2011
The following diagram shows the sequence of operations that are performed using the Transport core components as part of an
acknowledgement to a request on the Responding Gateway in Deferred request/response mode.
Figure 5. Transport Core - Deferred workflow - Responding Gateway - Send Acknowledgement
7
RI Transport Arch. Design
Delivery Date: May 4, 2011
The following diagram shows the sequence of operations that are performed using the Transport core components as part of initiating a
request (this request is actually a response to an earlier deferred request) on the Responding Gateway in Deferred request/response mode.
Figure Transport Core - Deferred Workflow - Responding Gateway - Send Response
8
RI Transport Arch. Design
Delivery Date: May 4, 2011
The following diagram shows the sequence of operations that are performed using the Transport core components as part of
acknowledging to a request on the Initiating Gateway in Deferred request/response mode.
Figure 6. Sequence Diagram - Transport Core Deferred Response - Initiating Gateway - Receive Response
9
RI Transport Arch. Design
Delivery Date: May 4, 2011
6.3 INTERFACES
6.3.1 TRANSPORT FACADE INTERFACE
This interface is the primary interface used by other modules to communicate with the Transport
Core subsystem. It provides a means to validate requests, build headers, etc.
6.3.2 CERTIFICATION SERVICE INTERFACE
Transport Core uses this interface internally to validate certificates and to check a certificate
against the Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP) service.
Security Module will use this interface to retrieve a certificate, given some identifying
information such as an alias of the certificate.
6.3.3 STATE HANDLER INTERFACE
Transport Core uses this interface internally. The default implementation will persist the state of
the requests/responses in deferred workflow mode. Currently, the state is persisted in an objectoriented database, db4o. This interface can be extended to provide a different implementation.
6.3.4 SESSION HANDLER INTERFACE
Transport Core uses this interface internally. The default implementation will persist the
responses received in deferred workflow mode. These responses will be persisted until the
requester retrieves it or until a set time period, configurable by the user, elapses. Then the
responses will be purged. Currently, the responses are persisted in an object-oriented database,
db4o. This interface can be extended to provide a different implementation.
7.0 REFERENCES
The following references were used to produce this document:
1. NHIN Messaging Platform Specification document (Production), available at
http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_910523_0_0_18/NHI
N_MessagingPlatformProductionSpecification_v2.0.pdf
2. Modular Pilot Architecture Transport Module (DRAFT)
(Modular_Trnsprt_Arch_1_0_Final.docx), available at
http://jira.siframework.org/wiki/display/MSP/Reference+Implementation+Team
10