1. Data Transport Standard (DTS)
Executive Overview

2. Executive Summary
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

3. DTS Defined Data Transport Standard
Established by PESC for exchanging data:
Inquiry
Reports
Transactions
An adjunct to or replacement for existing data transport mechanisms (PGP, Secret Agent, and FTP)
PESC is the Postsecondary Electronic Standards Council. See more information at
Data Transport Standard (DTS) is a web service that enables entities to send and respond to any type of request (inquiry, report, transaction,), between or with dot Net or JAVA platforms, utilizing SOAP. DTS is a result of a PESC initiative to create a standard method to exchange data within the Higher Education arena, regardless of the business process. It is a recommended replacement for PGP ( ) and industry wide solution for real-time or immediate requests, and offers a single solution to transport. This makes DTS a payload independent process.
Web services are based on request-response patterns. These request-response behavioral patterns occur in a synchronous (uninterrupted) mode. DTS uses the request-response behavioral pattern within a SOAP format.
SOAP, Simple Object Access Protocol, is widely accepted and open industry standard for formatting messages. The SOAP format consists of three key components * Header, Body and Faults. The Header contains routing or address information, the body contains the actual message or payload, and SOAP Faults are messages returned if an error is identified in the Header or Body. This document explains the data structure, elements required in the DTS SOAP Header and Body, and Faults pre-defined within the DTS specification. Additionally, this document describes how this process can be utilized in various business communications. Refer the DTS Technical Specification for additional information on coding and software requirements.

4. Specification for DTS Specification Covers
Technical interchange rules and processes
Recommended best practices
Specification Does Not Cover
Business rules for transaction processing
Operational oversight, monitoring or escalation
Implementation Examples
Code samples are available
The specification deals with the exchange of data, business rules determine how you will produce or process that data.
The DTS Specification includes the standardized communication protocol and rules for use.
“Business rules” include how your organization will use or generate the data, examples could include Transcripts, Admissions Data, CommonLine, CommonRecord: CommonLine, etc.
Code samples are available at

5. 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
Includes automatic data encryption
Uses digital signature standards
Platform independent
Strong authentication with non-repudiation
Data encryption is through HTTPS protocol
Digital signature standard is XML DSIG
Platforms already tested are Microsoft .Net and Java
With strong authentication you know who sent it, you are assured that you got the data from the entity you think you got it from
Non-repudiation here means the transmission is so well controlled that the sender cannot deny having sent the information

6. Next Steps
Identify business partners or internal applications seeking real time data exchange
Support the standard by funding and scheduling implementation of DTS
Implement DTS
Monitor improvements in throughput and reductions in transaction cost
Encourage your staff to evaluate the technical specification and identify opportunities for use within your organization and with your trading partners.

7. Share Information Notify the PESC DTS Workgroup with
Implementation and testing schedules
Trading partners
Issues with the defined standard
Share Implementation Experiences with Community
Successes
Difficulties
Why notify the PESC DTS Business Workgroup?
The Workgroup acts as a clearing house for all feedback on DTS
The Workgroup can facilitate identifying external testing partners
Internal testing schedules are not of interest to the Workgroup, but the Workgroup appreciates knowing external testing and production readiness information.

8. Additional DTS Information
Visit PESC at
Letter of Intent (including Business Case)
Historical Overview
Justification and Description
Community Collaboration
Executive Summaries
Specification
Reference Implementations
The Letter of Intent is a formality required for requesting a standard be defined and adopted by PESC.

9. PESC Workgroup Contacts
Workgroup Chair:
Workgroup co-Chair:
Kim Shiflette, USA Funds
(317)
Gary Allen, Oracle
(925)
Gary Sandler, ELM Resources
(510)
Visit PESC at

10. More Technical Slides Follow
The remaining slides can be material for a more technical presentation
Next slides are optional and for a more technical audience

11. Data Transport – Issues
data exchange is not reliable or flexible enough
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
size limitations
FTP data exchange has own challenges
Possible to overwrite earlier files
No confirmation of receipt
No synchronous response
Encryption is always separate and subject to its own issues, maintenance and failures

12. DTS Addresses Transport Issues
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
the size problem through data compression
the FTP overwrite problem by not using filenames
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

13. DTS Technologies Standards SSL encryption of HTTP Streams
HTTP1.1, SSL2.0, SOAP1.1, XML, WSDL2.0, zLib (RFC 1950), Base64 (RFC 3548), UUID, X.509
This suite is generally accepted as the base set of standards for building a Web Services solution
SSL encryption of HTTP Streams
WS-Security / XML-DSIG – digital signature standards
Strong authentication with non-repudiation
X.509 encryption keys and certificate authorities