MODULAR PILOT DESIGN
TRANSPORT MODULE
Office of the National Coordinator for Health Information Technology
Version 1.2
June 30, 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 Design
Transport Module
v1.2 – June 30, 2011
DOCUMENT CHANGE HISTORY
Version
1.0
1.1
1.2
Date
05/04/2011
06/28/2011
06/30/2011
Changed By
Lockheed Martin
Lockheed Martin
Lockheed Martin
Items Changed Since Previous Version
First Draft
Post Implementation Updates
Incorporated Internal review feedback
I
Modular Pilot Design
Transport Module
v1.2 – June 30, 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 ........................................................................................................................ 4
6.3
INTERFACES .................................................................................................................................... 10
6.3.1 Transport Facade Interface .................................................................................................... 10
6.3.2 State 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
I
Modular Pilot Design
Transport Module
v1.2 – June 30, 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, add WS-Addressing headers and persist the request/response messages. On
the Responding RI Gateway, these components are used to validate the WS-Addressing headers
information and persist the request and response messages.
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 persist
the request/response messages.
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.
 Be 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 Design
Transport Module
v1.2 – June 30, 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 Advancement 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.

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. Note: It is anticipated that there will be change to
this assumption. There is a possibility of multiple certificate authorities involved.

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 Common components like Logging, Exception
Handling, Data Access Object (DAO), Utilities, etc.
5.0 CODE RE-USE
The Transport Module components will be reused by all the services on the Nationwide Health
Information Network to create secure message exchange.
2
Modular Pilot Design
Transport Module
v1.2 – June 30, 2011
6.0 ARCHITECTURE
The intent of this design is to identify and define the interfaces the Transport Core exposes, the
interfaces the Transport Core uses, 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 Common components for logging, exception handling,
utilities, etc. Appropriate interfaces of RI Common 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
3
Modular Pilot Design
Transport Module
v1.2 – June 30, 2011
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.
Figure 2. Transport Core Synchronous Request - Initiating Gateway
4
Modular Pilot Design
Transport Module
v1.2 – June 30, 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
Modular Pilot Design
Transport Module
v1.2 – June 30, 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
Modular Pilot Design
Transport Module
v1.2 – June 30, 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
Modular Pilot Design
Transport Module
v1.2 – June 30, 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 6. Transport Core - Deferred Workflow - Responding Gateway - Send Response
8
Modular Pilot Design
Transport Module
v1.2 – June 30, 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 7. Sequence Diagram - Transport Core Deferred Response - Initiating Gateway - Receive Response
9
Modular Pilot Design
Transport Module
v1.2 – June 30, 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 STATE HANDLER INTERFACE
Transport Core uses this interface internally. The default implementation will persist the
requests/responses and the states of the messages 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. Modular Specifications Pilot Requirements Traceability Matrix.
2. Nationwide Health Information Network Messaging Platform Specification document
(Production).
3. Modular Pilot Architecture Transport Module.
10