Data Transport Standard

1
Data Transport Standard
Session 51

• Nathan Chitty
• Gary Allen

2
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

3
Data Transport Issues in Higher Ed

• FTP data exchange has own challenges
• Possible to overwrite earlier files
• No confirmation of receipt
• No synchronous response

4
Data Transport Issues in Higher Ed

• Encryption today is always separate and subject
  to its own
• Issues
• Maintenance
• Failures

5
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

6
DTS Addresses These Transport Issues

• DTS addresses
• The size problem through data compression
• The FTP overwrite problem by not using filenames

7
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

8
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

9
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

10
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

11
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

12
DTS Benefits

• Includes automatic data encryption
• Uses digital signature standards
• Platform independent
• Strong authentication with non-repudiation

13
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

14
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

15
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

16
DTS Specification

• Reference implementation examples are available
• Specification does not cover
• Business rules for transaction processing
• Operational oversight, monitoring or escalation

17
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

18
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)

19
DTS Technologies

• WS-Security (Digital Signatures)
• Strong authentication with non-repudiation
• X.509 encryption keys and certificate authorities
• SSL encryption of HTTP streams

20
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

21
Immediate
22
Push/Push (part 1)
23
Push/Push (part 2)
24
Push/Pull (part 1)
25
Push/Pull (part 2)
26
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

27
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

28
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

29
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

30
Why SOAP Headers

• To answer routing and processing expectations
  without opening the payload
• Remain payload insensitive
• Allow extensibility for new processes

31
DTS SOAP Headers

• DTSRequestRouting
• DTSRequestServiceExpectation
• DTSRequestPayloadType
• DTSRequestPayloadBytes
• DTSRequestSignature

• DTSResponseRouting
• DTSResponseAcknowledge
• DTSResponsePayloadType
• DTSResponsePayloadBytes
• DTSResponseSignature

32
Convoluted Filename vs Header Elements

• A B ltX.Y.ZMgt
• 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

33
Interop Problem with SOAP Headers

• xsitype attribute in Header elements
• Java includes and requires this attribute
• .Net does not

34
All about SOAP

• ltsoapHeadergt
• ltDTSRequestPayloadType xsitype"DTSRequestPa
  yloadType" xmlns"http//www.datatransportstandar
  d.com"gt
• ltvaluegtCRC01Requestlt/valuegt
• lt/DTSRequestPayloadCodegt

35
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

36
SOAP Differences That Do Not Matter
Java ltns1DTSRequestSignature soapenvmustUnder
stand"0" xsitype"ns1DTSRequestSignature"
xmlnsns1"http//www.datatransportstandard.com"gt
ltns1valuegtSignatureValuelt/ns1valuegt lt/ns1DTS
RequestSignaturegt .Net ltDTSRequestSignature
xsitype"DTSRequestSignature"
xmlns"http//www.datatransportstandard.com"gt lt
valuegtSignatureValuelt/valuegt lt/DTSRequestSignature
gt
37
Reference Implementation Architecture

• Client Application
• Client Core
• Service Core
• Service Application

38
Client Application

• Knows nothing of SOAP or Web Services
• Implements Client Core Interface
• Setters and Getters of DTS specific elements
• Houses specific business logic

39
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

40
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

41
Service Core (cont)

• Isolated business logic
• Examples
• Invoke Service Application based on payload
• Place payload in queue

42
Service Application

• Interface for setting sent and getting to be
  returned elements
• Houses specific business logic
• Knows nothing of SOAP or Web Services

43
Connecting the layers
44
Connecting the layers
45
Connecting the layers
46
Connecting the layers
47
Connecting the layers
48
Connecting the Layers
49
DTS Version 2

• New tools
• No changes to interfaces
• Reorganization of SOAP Headers
• Full WS-Security integration

50
New Tools

• Axis 1.4 removed requirement for xsitype
  attribute
• Reduces complexity from .Net side
• Implemented WSS4J and WSE
• WS-Security integration

51
Reorganization of Headers
Version 1
Version 2
ltDTSRequestRouting xsitype"DTSRequestRouting"
xmlns"http//www.datatransportstandard.com"gt
ltUUIDgt lttransmissionDateTime
gt ltsourceIDgt
ltsourceIDCodegt ltrecipientIDgt lt/DTSRequ
estRoutinggt ltDTSRequestPayloadType
xsitype"DTSRequestPayloadType"
xmlns"http//www.datatransportstandard.com"gt
ltvaluegtCRC01Requestlt/valuegt lt/DTSRequest
PayloadTypegt ltDTSRequestPayloadBytes
xsitype"DTSRequestPayloadBytes"
xmlns"http//www.datatransportstandard.com"gt
ltvaluegt53lt/valuegt lt/DTSRequestPayloadByt
esgt ltDTSRequestServiceExpectation
xsitype"DTSRequestServiceExpectation"
xmlns"http//www.datatransportstandard.com"gt
ltvaluegtImmediatelt/valuegt lt/DTSRequestSer
viceExpectationgt ltDTSRequestSignature
xsitype"DTSRequestSignature"
xmlns"http//www.datatransportstandard.com"gt
ltvaluegtsometinglt/valuegt lt/DTSRequestSign
aturegt
ltDTSRequestHeader xmlnsdts"urnorgpescdatatr
ansport" soapmustUnderstand"1"
soapactor"urnorgpescdatatransport/dts"
xmlns"urnorgpescdatatransport"gt
ltdtsDTSRequestRoutinggt
ltdtsDTSUUIDgt ltdtsDTSSourceIDgt
ltdtsDTSSourceIDSubCodegt
ltdtsDTSRecipientIDgt
ltdtsDTSRecipientIDSubCodegt
lt/dtsDTSRequestRoutinggt
ltdtsDTSRequestPayloadTypegt
ltdtsDTSRequestPayloadBytesgt
ltdtsDTSRequestServiceExpectationgt
lt/DTSRequestHeadergt ltwsseSecurity
soapmustUnderstand"1"gt ltwsuTimestampgt
ltwsuCreatedgt ltwsuExpiresgt
lt/wsuTimestampgt ... ltSignatureValuegt lt/ws
seSecuritygt
52
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

53
WS-Security (cont)

• 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)

54
WS-Security

• .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

55
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, CRC
  implementation rules
• DTS Technical group is currently writing change
  proposal for PESC
• No changes to interfaces, Just Better!

56
Connecting the Layers
57
Additional DTS Information

• Visit PESC at www.pesc.org
• Materials available include
• Executive summaries
• Specifications
• Reference (proof of concept) implementations

58
Contact Information
We appreciate your feedback and comments. We can
be reached at
Name Nathan Chitty, Nelnet, Inc.Phone [phone]
235Email nathan.chitty_at_nelnet.net Name Gary
Allen, ELM Resources Phone [phone] Email g
allen_at_elmresources.com