E-Transcripts: The K-12 Data Model Meets the University:

1. E-Transcripts: The K-12 Data Model Meets the University: Development of E-Transcript schemas and the infrastructure needed to support them. Ron Kleinman Chief Technical Evangelist Market Development Engineering

2. The Problem to be Solved University High School Transcripts Infrastructure You Them Q 1: Who is Them?

3. School Interoperability Framework (SIF) Standard Unified K-12 Data Model Intra-School / District Infrastructure External K-12 Data Supplier  Standardized Partner on “the other side of the wire”

4. A bit of History: In the beginning K-12 Problem = Isolated Applications Library Student Info Xportation DB DB DB • Multiple Data Entry • Inconsistent Data

5. Solution: Shared Data Facility Library Shared Data Facility Student Info DB DB • One Consistent Copy of Data  Data Model • Any updates available to all • … but legacy applications weren’t written that way!

6. Enter the Agent and ZIS Library DB DB Shared Data Facility (ZIS) Agent 2 Student Info Agent 1 • Shared Data Facility is Zone Integration Server (ZIS) • Agent Isolates Application from ZIS • Agent / Application Interface is “Open” • Topology Independent (LAN, WAN, Internet)

7. What is the SIF v1.0 Standard? Library DB DB SIF SIF Agent 2 Student Info Agent 1 ZIS • SIF defines Agent / ZIS Interoperability • XML Schemas for all K-12 “Object Documents” • A “platform neutral” wire • A 4-part “Document Exchange” choreography

8. 1. Agent Registration:Session Based Communication Agent ZIS • Session Creation: Negotiation • Security (authenticate once) • SIF Version • Max Buffer Size • Transport (HTTPS is default) • Push / Pull

9. 2. Object Monitoring: Setup Lib Agent SIS Agent ZIS Subscribe Provide Object Xport Agent Subscribe • SIS Agent provides Student InfoObjects • Library & Xport Agents subscribe to changes

10. 3. Object Monitoring: Update & Coordination Lib Agent SIS Agent ZIS Event Publish Change Xport Agent Event • New Student Enrolled • Subscribers Alerted

11. 4. Object Info Retrieval:Sharing “owned” data Request ZIS Request Xport Agent SIS Agent Response Response Xport Agent: Find Name / Address of New Student => Bus Driver alerted to new stop (with no additional data entry)

12. ZIS Functionality Agent 1 ZIS Agent 2 DB • ZIS: Store and forward Persistent Message Router • Session • Maintain negotiated Agent Parameters • Security • Enforce site security policies

13. ZIS Functionality (Cont): • Provide / Subscribe • Maintain per agent Message Lists • Multiplex published Events to Subscribers • Guarantee Event delivery • Request / Response Matching • Route object requests to providing Agents (Data Confederacy) • Route object responses to requesting Agent  MOM, but defined wire, not API

14. And then came …“No Child Left Behind” • Failing schools needed to be identified • K-12 School comparisons required • Comparisons require aggregate data • Aggregation requires similar data • SIF owned K-12 data model! • Federal Government encourages SIF • States start specifying SIF in RFPs National K-12 Data Uniformity

15. SIF Status: Circa V1.5: Report Generation Facility Providing K-12 Aggregated Data to Applications “outside the zone”

16. SIF Reporting: The Players Report Collector App 1 ZIS App 2 Report Generator

17. Manifest Object:What is wanted and When • Contract between Generator & Collector • Requested Report Format • Reference to agreed Report Specification • Query structure to specify Report Contents • Qualifier conditions on SIF Objects • Fields wanted in Report

18. Manifest Object: (Con’t)What is wanted and When • Report Authority Object • ID of Authority requesting Report • Contact Information • Other Data • Manifest ID • Date / Time Range that Collector will accept Report  Accepted or Rejected by Generator

19. Report Container Object:Data Collection satisfying Manifest • Collections of other SIF Object Elements • Reference to Manifest ID • Sent within specified time window  Fulfillment of Manifest Contract

20. SIF Reporting Sequence:Data Confederacy  Data Union Report Generator Report Collector App 1 App 2 Manifest Data Request 2 Response Response 2 Data Request 1 Report Event Response 1 OR Report Request Report

21. SIF v1.5: PresentReport Generation Facility • Student aggregation data added to Data Model • Statewide Application registers in each District Zone • Choreography allows time decoupling • State defines what is in report and when due • District Reporter gathers data • District Reporter posts Report event or • State requests report

22. SIF v1.6: Near FutureExternal Access to Zone Data • Utilize Web Services Technology • Zone is K-12 Web Service (Data Union) • ZIS / SIF Infra are implementation details • Report Requestor “uses” SOAP / WSDL • Defined usage (ex: Document, Literal) • Same Manifest & Report Container XML • State-level UDDI for District Zones • Opens Zone to other non-SIF clients • Remote Zone Maintenance & Management • E-Transcripts

23. K-12 Web Service:Access via SOAP / WSDL State Client College Aggregates Transcripts K-12 Zone Web Service Other Zone Manager Control & Monitoring

24. A SIF K-12 E-Transcript Web Service: So with the selection of SOAP and WSDL, is the basic design completed? Well … not exactly: Infrastructure Options Message Choreography Document Data

25. Defining the Infrastructure:Two Message Exchange Models A Request B 1:1 Response A Subscribe& Request MOM B N:1 C-Z Publish & Respond

26. E-Transcript Partners:Initial Analysis • Message Oriented Middleware Model • Central point known to all potential partners • Centralized security & administration • Partners have long term relationships • Broadcast of published events to multiple subscribers • Intra-Enterprise rather than Inter-Net  Applicable to SIF Zone (i. e. ZIS)  Not applicable to E-Transcripts

27. 1:1 Interoperability is only easyif it’s you on both ends of the wire 1. Define the Infrastructure

28. Infra Basic Decisions Univ Request HS Response • How does Univ find HS? • Supplied URL or national SIF Zone Registry • What data can Univ and HS exchange? • SIF standardized XML Schemas • Manifest / Report Container / E-Transcript • Does HS Zone have to be on line? • Only E-Transcript Report Generator WS • HS Response synch/asynch? • RPC (1) or Document Exchange (2): <2>

29. Infra Security Decisions Univ Request HS Response • Authentication (Request really from Univ?) • Digital Signature (dynamic 3rd party verification) • User ID / Password (Pre-stored OOB) <Yes> • Authorization (Univ allowed to request this?) • Ex: Who can access Student X Transcripts? <Yes> • Encryption <Yes> • Prevent lurking, spoofing, password stealing • Non-refutability: <No> • Party can’t deny they sent the message • Non-alterability <Maybe> • Party can’t change message contents after receipt

30. Infra Message Decisions Univ Request HS Response • Common Transport Layer • HTTP, HTTP/S, SMTP, TCP, ebMS, …? <HTTP/S> • Message Packaging Options • Multiple Attachments? <Maybe: Assessments> • Binary Attachments? <Future: E-Portfolio> • Message Service Level Enhancements <No> • No Duplicates, Guaranteed Delivery, … • Sessions (vs. Separate Exchanges) <No> • Session Control (Start, End, Cancel, Sleep, Wake ..) • Session State (Version, Security Cookie, …) • Defined Transaction Choreographies <Yes>

31. 1:1 Interoperability is only easyif it’s you on both ends of the wire 2. Define the Choreography

32. Transaction Choreography:Document Exchange Sequences • Automate Manual Partner Interactions • Design Criteria • Type of Partner Relationship • Extent of Standardization in Document Formats • Extent of Standardization in Transaction Choreography

33. Ex 1: Purchase Cycle with known supplier (GM / Delco) • Partner Relationship: Stable, Long Term • Customer knows Recipient Supplier • Supplier knows Initiator Customer • Document Formats: Accepted by both • Defined by sender • Transaction Choreography • Known, agreed to by both parties

34. Goods Purchase Choreography Customer Supplier Purchase Order (PO) PO Received PO Accepted (T/C) T/C Accepted Shipping Info Shipping Info Accepted Invoice

35. Goods Purchase Choreography:Migration • Legacy System • Documents  Signed Business Forms • Infrastructure  Fax Machines • Security  Signature, filed copies • Solution: Leverage Industry standards • UBL defines XML Document Schemas • ebMS provides secure reliable transport • BPSS defines document choreography • Automatic processing possible at both ends • Just-in-time inventory reordering

36. Ex 2: Filing Tax Return to State Government • Partner Relationship: “Same time next year” • Taxpayer knows Recipient State Government • Recipient does not know Initiator Taxpayer • Needs Taxpayer ID, Partnership ID • Tax Document Formats: Standard • Defined by State • Transaction Choreography • Known by both parties, enforced by State

37. Tax Return Choreography Tax Payer Government Tax Forms (opt) Tax Returns Refund (?) Notice of Audit (!)

38. Tax Return Choreography:Migration • Legacy System • Documents  Tax Forms • Infrastructure  Snail Mail • Security  Authorization (Taxpayer ID) • Solution: State defines Email Doc • Taxpayer software has forms GUI • Sends Line IDs & Values, not Tax Forms • Optional Auto-filing via email • Earlier refund incentive for Taxpayer • No State Government Tax Data Re-entry

39. Ex 3: Application and HS Transcript to University • Partner Relationship: “One night stand” • Must interoperate seamlessly on 1rst contact • Document Formats: Wildly Varied • Transcripts Defined by individual HS • Applications Defined by individual University • Neither document pre-known to other party • Transaction Choreography: Varied • Ex: NCAA Clearing House interactions • “Final” Transcript optionally required

40. Transcripts Choreography:Typical Manual Exchanges Student High School College Application Written Release Transcript & Assessment Written Notification Final Transcript

41. Transcript Choreography:Legacy System Problems • Documents  Defined by High Schools • University must interpret data • Infrastructure  Snail Mail • University must reenter data • Security  Spoof-able authentication • No prior University / HS relationship • HS sends Transcript at Student’s request • Could come from “another source” • No verification sent back to High School

42. HS Transcripts from University viewpoint • Sent from an institution University never heard of • Signed by someone University never heard of • Testifies to accomplishments of a student University never heard of • Uses ill-defined subjective terminology  Transcript = a letter of recommendation

43. Transcript Choreography: Tentative Migration • Standardize on E-Transcript Data • Extension of SIF Data Model • Reduce interpretation effort • Adopt an automated infrastructure • Application Document submitted via email • Application has SIF Zone & Student ID • Registry converts Zone ID to Zone WS URL • University requests Documents as needed

44. E-Transcripts Choreography:SIF Document Exchanges High School Zone Registry Student College Application Written Release HS ID Lookup Transcript URL Transcript Manifest Transcript/Assessment Final Transcript Manifest Final Transcript Report

45. 1:1 Interoperability is only easyif it’s you on both ends of the wire 3. Define and Standardize on the Document Formats (XML Schemas)

46. E-Transcripts: Student Recordfor institutional transfers • Student Data • Transcripts (Course IDs, Grades) • Class Standing (Rank, Decile) • Assessment (ACT, SAT, AP Credits) • Course Data • ID, Title, Description, # Credits (Carnegie Units) • Articulation (Cross correlation with State standards)

47. E-Transcripts: Student Recordfor institutional transfers (Con’t) • School Data • Name, Type, Contact Info • # School days per year, # Students • Grade Conversion (Point Range for A – F) • Graduation Requirements • Other (optional free-form) • Public Service • Special Projects

48. SIF E-Transcripts:Leverage Other Standards • National Center for Educational Statistics • Course Classification across states • Iowa, Louisiana – a work in progress • Post Secondary Electronics Standard Council (PESC) • Intra-college xfers, EDI  XML • Course syllabus in free form text • Brigham Young, U of Texas, U of Florida, … • SPEEDE / ExPRESS • NCAA Clearing House interactions

49. SIF E-Transcripts:Futures • E-Portfolios • Embedded URLs to non-ASCII data • Artwork, piano audio, movies • Security an issue

50. Standardized E-Transcript Web Service: Advantages to University • Secure Transcript Acquisition • Auto-correlate with Student Application • Reduce manual interpretation • Compare Apples to Apples • Staged Migration from Manual System