Data Transport Standard (DTS) Executive Overview

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

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, e-mail and FTP) PESC is the Postsecondary Electronic Standards Council. See more information at http://www.pesc.org 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 (e-mail) 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.

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 http://www.pesc.org

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

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.

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.

Additional DTS Information Visit PESC at www.pesc.org 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.

PESC Workgroup Contacts Workgroup Chair: Workgroup co-Chair: Kim Shiflette, USA Funds (317) 806-1212 kshiflet@usafunds.org Gary Allen, Oracle (925) 694-6197 gary.x.allen@oracle.com Gary Sandler, ELM Resources (510) 903-7960 gsandler@elmresources.com Visit PESC at http://www.pesc.org

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

Data Transport – Issues E-mail 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 Email 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

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

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