Data transport standard
1 / 58

Data Transport Standard - PowerPoint PPT Presentation

  • Uploaded on

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

PowerPoint Slideshow about ' Data Transport Standard' - lanza

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

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

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!

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, Inc.Phone: 904-281-7235Email: [email protected]

Name: Gary Allen, ELM Resources

Phone: 510-903-0674

Email: [email protected]