data transport standard
Skip this Video
Download Presentation
Data Transport Standard

Loading in 2 Seconds...

play fullscreen
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]
    • 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


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




















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]