Data Transport Standard - PowerPoint PPT Presentation

Data transport standard
1 / 58

  • Uploaded on
  • Presentation posted in: General

Session 51. Data Transport Standard. Nathan Chitty Gary Allen. Data Transport Issues in Higher Ed. E-mail is not reliable or flexible enough for confidential and time-sensitive data No guarantee of delivery No guarantee of order of delivery for sequence dependent data

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Data Transport Standard

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Data transport standard

Session 51

Data Transport Standard

Nathan Chitty

Gary Allen

Data transport issues in higher ed

Data Transport Issues in Higher Ed

  • E-mail is not reliable or flexible enough for confidential and time-sensitive data

    • No guarantee of delivery

    • No guarantee of order of delivery for sequence dependent data

    • No automatic confirmation of receipt or facility for retransmit

    • No synchronous response available

    • Email size limitations

Data transport issues in higher ed1

Data Transport Issues in Higher Ed

  • FTP data exchange has own challenges

    • Possible to overwrite earlier files

    • No confirmation of receipt

    • No synchronous response

Data transport issues in higher ed2

Data Transport Issues in Higher Ed

  • Encryption today is always separate and subject to its own

    • Issues

    • Maintenance

    • Failures

Dts addresses these transport issues

DTS Addresses These Transport Issues

  • DTS addresses

    • The confirmation issue with a send-receive protocol – confirmation is built in

    • The order of delivery problem by actively delivering and receiving the data – no unconfirmed hand-offs

Dts addresses these transport issues1

DTS Addresses These Transport Issues

  • DTS addresses

    • The size problem through data compression

    • The FTP overwrite problem by not using filenames

Dts addresses these transport issues2

DTS Addresses These Transport Issues

  • DTS addresses

    • The lack of a synchronous response by building in a required synchronous response, even if only for handling status

    • The encryption issue by using standard HTTPS for encryption – the same technology as for online banking

What is dts

What is DTS?

  • DTS – Data Transport Standard – is a specification for an adjunct to or a replacement for existing data transport mechanisms

    • PGP / GnuPG encryption

    • SecretAgent w/ Email

    • FTP and SecureFTP

What is dts1

What is DTS?

  • DTS is a specification not a product

  • DTS was developed by the Postsecondary Education Standards Council (PESC) for exchanging data for:

    • Inquiries

    • Reports

    • Transactions

What is dts2

What is DTS?

  • DTS uses Internet technologies to facilitate real time data exchange and transaction processing

  • DTS builds on stable technologies, not specific products

  • DTS, once implemented, reduces programming and per-transaction costs through standardization

Dts benefits

DTS Benefits

  • A Web Services implementation

    • Delivery confirmation included – no guessing

    • All requests get a response

    • All submissions get an answer of some kind

  • Facilitates real time data exchange

Dts benefits1

DTS Benefits

  • Includes automatic data encryption

  • Uses digital signature standards

  • Platform independent

  • Strong authentication with non-repudiation

Benefits to system providers

Benefits To “System Providers”

  • Adds value to schools’ systems

    • Schools want transport added to systems and are generally not concerned with the technologies

  • Easier to build one transport protocol for all recipients

    • Just as CommonRecord created the drive to build one XML format

Benefits to service providers

Benefits to “Service Providers”

  • As everyone implements DTS, the need to support other transports will drop

  • If any school implements DTS, service providers will have to support it

  • Also provides a single communication infrastructure option for internal systems

Dts specification

DTS Specification

  • Specification covers

    • Technical interchange rules and processes

    • Recommended best practices

  • Technical Specification is the pure Simple Object Access Protocol (SOAP) interface

  • Implementation Guide is for both .Net and Java reference implementations

Dts specification1

DTS Specification

  • Reference implementation examples are available

  • Specification does not cover

    • Business rules for transaction processing

    • Operational oversight, monitoring or escalation

Dts technical workgroup

DTS Technical Workgroup

  • Task: Create a written specification for real-time exchange of data between organizations

    • Meets business requirements

    • Standards based

    • Standard technologies (Java, .Net)

    • Payload Insensitive

    • Secure and reliable

Dts technologies

DTS Technologies

  • Global XML Web Service Architecture (GXA), generally accepted as the foundation for building Web Services

    • WSDL (Web Service Definition Language)

    • SOAP (Simple Object Access Protocol)

    • WS-I (Web Service Interoperability)

    • WS-S (Web Service Security)

Dts technologies1

DTS Technologies

  • WS-Security (Digital Signatures)

    • Strong authentication with non-repudiation

    • X.509 encryption keys and certificate authorities

  • SSL encryption of HTTP streams

Anticipated architectures

Anticipated Architectures

  • Immediate processing

    • Request and processed Result Response

  • “Push/Push” deferred processing

    • Request and Acknowledge Response

    • Request with Result and Acknowledge Response

  • “Push/Pull” deferred processing

    • Request and Acknowledge Response (just send)

    • Request for Result and Result Response



Push push part 1

“Push/Push” (part 1)

Push push part 2

“Push/Push” (part 2)

Push pull part 1

“Push/Pull” (part 1)

Push pull part 2

“Push/Pull” (part 2)

Dts analogy

DTS Analogy

  • DTS is the definition of the “Pipe” and the structure of its contents

    • The “Pipe” is the internet

    • The content is SOAP

    • The end points/junctions are Web Services

    • The sources are Web Service enabled clients

Dts analogy1

DTS Analogy

  • DTS defines how others can connect to the “Pipe” already installed

    • Any connections must have certain “threads”

    • Any connections must handle two way traffic independent of how the traffic will be used

Dts analogy2

DTS Analogy

  • By knowing about the pipe and the type of connections, any “plumber” can use his/her own tools to make connections; just so long as the threads match

How did we do it

How Did We Do It?

  • Created basic HelloWorld service and client

    • Worked interoperable

  • Added simple Headers to HelloWorld

    • Was not interoperable

  • Added complex Header to HelloWorld

    • Was not interoperable

Why soap headers

Why SOAP Headers

  • To answer routing and processing expectations without opening the payload

  • Remain payload insensitive

  • Allow extensibility for new processes

Dts soap headers

DTS SOAP Headers

  • DTSResponseRouting

  • DTSResponseAcknowledge

  • DTSResponsePayloadType

  • DTSResponsePayloadBytes

  • DTSResponseSignature

  • DTSRequestRouting

  • DTSRequestServiceExpectation

  • DTSRequestPayloadType

  • DTSRequestPayloadBytes

  • DTSRequestSignature

Convoluted filename vs header elements

Convoluted Filename vs Header Elements

  • A [B] <X.Y.Z:M>

    • A = File Type, B = Encrytption, X.Y.Z = key identifier, M = Unique message ID

  • Encryption unnecessary because using HTTPS

  • DTSRequestPayloadType = A

  • DTSRequestRouting

    • SourceIDSubCode = X, SourceID =Y(.Z)

    • UUID = M

Interop problem with soap headers

Interop Problem with SOAP Headers

  • xsi:type attribute in Header elements

    • Java includes and requires this attribute

    • .Net does not

All about soap


<DTSRequestPayloadType xsi:type="DTSRequestPayloadType" xmlns="">



All about SOAP

Soap is the key

SOAP is the Key

  • The SOAP transmitted across the wire is of primary importance

    • Element names

    • Type attribute

    • Not Namespace moniker (Java uses one by default, .Net does not)

  • How you get the correct SOAP is not important

Soap differences that do not matter

SOAP Differences That Do Not Matter




xsi:type="ns1:DTSRequestSignature" xmlns:ns1="">








Reference implementation architecture

Reference Implementation Architecture

  • Client Application

  • Client Core

  • Service Core

  • Service Application

Client application

Client Application

  • Knows nothing of SOAP or Web Services

  • Implements Client Core Interface

    • “Setters” and “Getters” of DTS specific elements

  • Houses specific business logic

Client core

Client Core

  • Knows nothing of business logic

  • Uses properties set to construct the SOAP

  • Interface for “setting send” and “getting returned” elements

  • Handles the communication to Service Core- DTS Specification

Service core

Service Core

  • Accepts transmissions from Client Core

  • Implements Service Application Interface

    • “Setters” and “Getters” of DTS specific elements

  • Creates return SOAP

    • Format return acknowledgement or data from Service Application

    • Construct SOAP faults

Service core con t

Service Core (con’t)

  • Isolated business logic

    • Examples

      • Invoke Service Application based on payload

      • Place payload in “queue”

Service application

Service Application

  • Interface for “setting sent” and “getting to be returned” elements

  • Houses specific business logic

  • Knows nothing of SOAP or Web Services

Connecting the layers

Connecting the layers

Connecting the layers1

Connecting the layers

Connecting the layers2

Connecting the layers

Connecting the layers3

Connecting the layers

Connecting the layers4

Connecting the layers

Connecting the layers5

Connecting the Layers

Dts version 2

DTS Version 2

  • New tools

  • No changes to interfaces

  • Reorganization of SOAP Headers

  • Full WS-Security integration

New tools

New Tools

  • Axis 1.4 removed requirement for xsi:type attribute

    • Reduces complexity from .Net side

  • Implemented WSS4J and WSE

    • WS-Security integration

Reorganization of headers

Reorganization of Headers

Version 1

Version 2














































<wsse:Security soap:mustUnderstand="1">








Ws security


  • Version 1 utilized portions

    • Authenticity of data via Digital Signatures

    • However, proprietary Signature header element

  • Version 2 implements WS-S Header construct

    • Removal of proprietary signature element

    • Inclusion of Security block

    • Inclusion of Binary Security Token element

Ws security con t

WS-Security (con’t)

  • Binary Security Token Element

    • Specification allows for the public X.509 certificate to be included in the transmission

    • Since, Certificate Authority signed X.509 certificate

      • No need to exchange public key

      • Trust the certificate chain (CA)

Ws security1


  • .Net

    • Implementing WS-S via WSE in .Net adds WS-Addressing block

    • Creates interoperability problem between .Net and Java

    • SOAP Output handler created to remove it

Technical wrap up

Technical Wrap Up

  • Version 1 approved by PESC (5/2006)

  • Electronic Exchange Advisory Team (EEAT) within NCHELP- Electronic Standards Committee is currently writing FFEL Commonline, CAM, CR:C implementation rules

  • DTS Technical group is currently writing change proposal for PESC

    • No changes to interfaces, Just Better!

Connecting the layers6

Connecting the Layers

Additional dts information

Additional DTS Information

  • Visit PESC at

  • Materials available include

    • Executive summaries

    • Specifications

    • Reference (proof of concept) implementations

Contact information

Contact Information

We appreciate your feedback and comments. We can be reached at:

Name:Nathan Chitty, Nelnet,

Name:Gary Allen, ELM Resources


  • Login