1. Open Knowledge Initiative

2. Data Specifications – IMS/SCORM Enterprise Application A Enterprise Application B Data

3. An Application Before OKI OKI in a Nutshell An Application Before OKI An Application After OKI

4. Tool and Implementation Portability

5. CourseWork and Stellar

6. Demo – Filing API  Provides Abstraction Boundary Between Application and one or more “file directories” known as “Cabinets.” Application

7. Local and Remote Cabinets File Sync. Demo

8. File Synchronization Demo  Client UI  Same code on Mac, Windows, Linux  Rich User Experience  Supports Disconnected Use  Different Byte Stores/Same application  Local, Remote, AFS, IMAP – Go Crazy!  Application Portability

9. Possible Uses  Group Collaboration with multiple users synching to central file space  Group Collaboration using Specialized Tools Exploiting “Universal” File System  Add Authentication/Authorization for security, Logging to track activity, Workflow and Usermessaging to manage projects, etc.  More integrated authoring environments  Other…

10. Development/Maintenance Effort as a Function of System Complexity Effort Complexity

11. Common Service Spec Status  Authentication  Authorization  DBC  Logging  LocalID  Shared  Filing  Hierarchy  User Messaging  Scheduling  Workflow 0.9 – Public 0.9 0.5

12. CS Implementation Activity Current Activity:  Authentication  Authorization  Filing  DBC  LocalID  Logging  Hierarchy Required Activity:  User Messaging  Workflow  Scheduling OKI-In-A-Box

13. Educational Service Spec Activity  Class Admin  Core Partner Engagment  MITSIS Engagement  Content Management/Digital Repository  Digital Library Community  DSpace Engagement  Learning Asset Model  Tool Model  Assessment

14. OKI Application Activity  LMS’s  Stellar – MIT  CourseWork – Stanford University  CHEF – University of Michigan  Indiana University  Demo Apps  Filing Demo  Hierarchy Demo  Digital Library  DSpace  Fedora  Various Educational Tool Development

15. Core Institutional Partners  Cambridge University  Dartmouth College  MIT  North Carolina State University  Stanford University  University of Michigan  University of Pennsylvania  University of Wisconsin

16. Specification/Standards Groups  Instructional Management Systems  Global Learning Consortium  Advanced Distributed Learning Network  DOD funded  SCORM  See IMS/ADL/OKI Press Release See IMS/ADL/OKI Press Release

17. OKI Architecture

18. OKI Services Course MgmtContent MgmtAssessment AuthN Etc… LocalIdFileDBCAuthZHierarchy User Messaging LoggingEtc… Shared Objects Educational Service APIs Common Service APIs Educational Service Implementations Common Service Implementations Educational Software “LMS” Institutional Infrastructure

19. Client Objects Client Apps Client Objects Client Apps Client Objects Web Apps Browser Client Objects Web Apps Browser Client Objects Client Apps OKI ServicesOKI Clients Campus Infrastructure OKI Service Model

20. Assumptions  Things Change  New Services & Functions  Method of Accessing Services  More Central Software Services  Authorization, Calendaring, etc.  Evolving Systems  Definition

21. More Assumptions  All Enterprises won’t have the same Technologies  All Enterprise Systems won’t use the same Technology  The need for sharing will grow  Differing “connectedness”  Not Web only

22. Goals  Better Integration  Allow data to be exchanged  Allow software to be integrated  Predictable Evolution  Allow for changing functionality  Minimize the negative impacts  Expanding Market Possibilities

23. Possible Integration Goals  Allow enterprise systems to exchange & synchronize information  Allow different organizations to exchange & synchronize information  Allow systems to use enterprise services  Allow for modular software which plugs into a known framework  Single System Responsible for Information

24. The API Approach  API are Interfaces only, not Implementations  Code Reuse  Could Achieve Real-time Integration  Clean Separation or Boundaries  Minimizes Impacts of Changes

25. Common Service Level APIs  Allows Integration with Enterprise Services  Adapts to Multiple Standards  Allows Several Sites to Share Services  Independence from Changing Technology

26. APIs  Definitions Example API

27. APIs  Definitions  Implementations Service API Implementation Infrastructure public class Factory implements org.okip.service.APIName.api.Factory { private static final blah blah bhal private static final yada yada yada } … Example

28. Service Based Architecture public class Factory implements org.okip.service.Example.api.Factory { private static final blah blah bhal private static final yada yada yada } … Example API … org.okip.service.shared.api.Thing things = myFactory.getSomething(); if (null != thingss) { for (int i = 0; things.length != i; i++) { out.println(things[i]); System.err.println(types[i]); } } … Application Implementation Infrastructure Service

29. Data and Functional Specification  Data standards serve two goals  Data exchange inter/intra enterprise  Both Data & Function needed for all Goals  Data duplication and propagation  data specifications can’t address all issues  Both Needed for Interoperability  And more!

30. Systems Exchanging Data System A System B 1 2

31. Systems Integrated Functionally System ASystem B 2

32. Deployment Possibilities  One system using another systems service  Framework & Component  System using enterprise service  Allow for system to use service to hide:  Functions performed different places  Different system responsible for data sets

33. Multiple OKI Servers Sharing Common Infrastructure Services SIS Data Authentication/ Authorization Digital Repository Messaging

34. Multiple OKI Servers Serving Different Content, But Sharing Some Enterprise Services SIS Data Authentication/ Authorization Digital Repository SIS Data Digital Repository

35. Kerb5 One Application Using Multiple Implementations of One API X509 AuthN App

36. Two Back End Systems – Single Access Method Class Admin Enrollment App. SIS System HR System

37. Group Integration Group Function Group Service System ASystem B

38. Implementation Supporting Multiple Protocols API X SRMISOAP Infrastructure Service Supporting both SRMI And SOAP

39. Independent or Tightly Coupled Implementations AuthNAuthZAuthNAuthZ Application A

40. API Implementations May Call APIs API 1API 2 Application X AuthNAuthZDBCLUID

41. “LMS” Varying Granularity of Service Exposure Assess Application Y AuthNAuthZ C.M.Etc. AuthZ Assess Application Z C.M.Etc.

42. Web Service Implementations? Web Service X SOAP Imp.of X API X WS Registry Server UDDI WSDL App. A

43. APIs

44. Anatomy of APIs  What does an API look like?  Java interfaces  Factory interface  Object interfaces  Used for  Presenting services to applications  Separating services from applications

45. Anatomy of APIs  What does an Implementation look like?  Java classes  Factory class  Object classes  Used for  Creating objects for an application  Accessing “real” services  An API can have many implementations

46. Anatomy of APIs  How do APIs differ from frameworks?  An API presents a service  A framework tells you how to code  An API can run in a framework  A framework might be able to run in an API  APIs are enabling  APIs foster compartmentalization

47. Anatomy of APIs  How do APIs relate to other technologies?  APIs allow the use existing software  APIs do not dictate the implementation  APIs do not dictate the application  An application doesn’t need to use all APIs  An application doesn’t need to use only APIs  API impls only need a thin Java shim

48. Anatomy of APIs  Factories  A mechanism to bind Implementations to APIs  Are used by apps to get API impl objects  Typical impl objects have factory references  Factories have owners (Agents and Context)

49. Anatomy of APIs  Factories - How the code changes  (Before) App getting an object instance  Athing a = new Athing(args);  (After) App getting an API impl object  Afactory f = FactoryManager( apiPkgName, implPkgname, owner);  Athing a = f.createAthing(args);

50. Anatomy of APIs  Example application using an API and Implementation - Jeff Kahn

51. Anatomy of APIs  Agents and Context  Factory owner is an Agent  Agents  Implementation specific  Application specific  Out of band agreements  Contain context  Proxy - next Agent in context chain

52. Anatomy of APIs  Agents and Context  Application context as owner  AppAgent appAgent = new AppAgent(context);  Afactory f = FactoryManager(api, impl, appAgent);  …  AppAgent owner = f.getOwner().getProxy(AppAgent.class());  Context c = owner.getContext();  Implementation context as owner  …  Agent owner = someFactory.getOwner();  Afactory f = FactoryManager(api, impl, owner);

53. Anatomy of APIs  Authentication/Authorization  Who are you?/What can you do?  Close association  Each is an API and implementation  Each has session context  Owner proxies can keep context

54. Anatomy of APIs  ROMI - remote object method invocation  Client/Server with invoke method  Example  public String toUpper( String s ) {  if(hasClient()) {  Class[] types = new Class[1]; types[0] = String.class();  Serializable[] args = new Serializable[0]; args[0] = s;  String upCase =  return getClient().invoke(this, “toUpper”, types, args);  }  return s.toUpperCase();  }

55. Anatomy of APIs  What does an API do for an architect?  Compartmentalizes the code  Hides implementation details  Provides an abstraction layer  Provides a way to change implementations  Provides a specification mechanism  Provides a way to spec app as a service  Separates User Interfaces and services.

56. Anatomy of APIs  What does an API do for an programmer?  Provides a clear specification  Removes architectural detail  Isolates the implementation  Minimizes coupling between modules  Maximizes cohesion  Encourages writing for reuse

57. Anatomy of APIs  What does an API do for the dev manager?  Allows tracking of progress  Is the API done?  Is the Implementation done?  Is the Implementation ROMI-ized?  Who is working on the xyz implementation?  Provides a context for project metrics  How’s the performance of the abc Impl?  How many APIs/Implementations are done?

58. Anatomy of APIs  What does an API do for the CIO?  Provides tracking and metrics  Provides a way to cost integration  Provides a way to cost development  Provides a way to generate vendor requirements  “Your product must use this Authentication API”  “Your product must implement the api API”  Opens a path for multiple vendor product use

59. Anatomy of APIs  What does an API do for the Vendor?  Provides a way to create factored products  Provides a way to use existing customer services  Provides the customer with an upgrade path  Provides a way to way to work with other products

60. Interoperability and Conformance

61. Dimensions of Interoperability Data Definitions Technology Choices UI/Application Frameworks Service Definitions

62. Dimensions of Interoperability Service Data UI Tech Gov.CorpHESchool

63. Open Knowledge Initiative Service Data UI Tech Gov.Corp. H.E. School J

64. Data Agreement Among Profiles Service Data UI Tech Common

65. Interoperability Choice Service Data UI Tech Gov.CorpHESchool

66. Conformance Conclusions  Interoperability is not easy Therefore:  Conformance will not be simple However:  We can make our lives better through intelligent choice and the company we keep.

67. OKI Strategic Efforts  Core Initiative  CS and ES API Specs  Reference Implementations  Exemplar Applications  OKI-in-a-Box 1.0  Communications/Marketing  Sustainability Strategy

68. OKI Strategic Efforts (cont)  Spec. Maintenance and Conformance  IMS?

69. OKI Strategic Efforts (cont)  Developer Communities Initial Effort → Consortia (Web/Portal, Component, Vendor)  Outreach  Coordination  Consolidating Spec Change Requests  Voice for Maint and Conformance  Dev Support, Training, Doc, Forum  Conformance?  IDE?

70. OKI Strategic Efforts (cont)  OKI in a box V2 (Consumers) Initial Build → Consortia/Vendor Support  Product Management  Packaging/Installation  Distribution  Documentation  Support  Marketing

71. OKI Developer’s Network  Hosted by IMS  See http://web.mit.edu/oki for more infohttp://web.mit.edu/oki

72. End

73. Sustainability  Spec. Maintenance and Conformance  Development Community  Web  Client  MIT Infrastructure  Build (one-time funding)  Support  Operate/Maintain Consortium (IMS) Consortium (?) MIT

74. MIT-OKI Convergence  Libraries  DSpace  E-Reserves  “LMS”  Stellar  SloanSpace/.LRN  Educational Innovation Projects (e.g. iLabs, BCS, Teal, etc…)  Enterprise Applications  MITSIS  DSpace  Coeus MIT OKI Infrastructure

75. MIT-OKI Convergence  Libraries  DSpace  E-Reserves  “LMS”  Stellar  SloanSpace/.LRN  Educational Innovation Projects (e.g. iLabs, BCS, Teal, etc…)  Enterprise Applications  MITSIS  DSpace  Coeus MIT OKI Infrastructure Funding Internal External

76. End

77. Stellar OCW and Stellar: Fall 2002 OCW Int. Web OCW IP Restricted Content OCW IP Cleared Content Discussion Boards for OCW Internal

78. Other OKI Digital Repository Services Impact on MIT Initiatives DSpace OCW AFS+ Local Stellar OCW Ext. Web Bb “Madagascar Institute of Technology” = OKI “Content Management” API

79. Design Dimensions for Educational Applications Technical Specs (W3C, IETF Java, I2, etc) Interoperability Specs (IMS, ADL, OCLC, OKI, etc.) Learning Activity Design (?)

80. Philosophy  Service-based Infrastructure for Educational Software (Development and Delivery)  Driven Primarily by Higher Education Technology Requirements and Pedagogy  Open (low threshold for access/adoption)  Collaborative (H.E., IMS, ADL)  Enable Sharing of Instructional/Training Applications  Implementation Independent Service Definitions

81. Assumptions  Things Change  New Services & Functions  Method of Accessing Services  More Central Software Services  Authorization, Calendaring, etc.  Evolving Systems  Definition  Boundaries

82. More Assumptions  All Enterprises won’t have the same Technologies  All Enterprise Systems won’t use the same Technology  The need for sharing will grow  Differing “connectedness”

83. Goals  Better Integration  Allow data to be exchanged  Allow software to be integrated  Predictable Evolution  Allow for changing functionality  Minimize the negative impacts  Expanding Market Possibilities

84. EALP  Educational Activities and Learning Practices  LMS Summit – April 2001  Needs assessment/scenarios  Tool Definition Workshop – Oct 15, 16  OKIO  LMS (sic) Summit II

85. Architecture Group  Primary team is at MIT  Approximately 3FTE  Provide bulk of day to day effort  Core partner designers  Face to Face engagement every two months on average  Critical input and contribution  Competencies range from system design, instructional application design, library systems

86. End of Part 1

87. Deliverables  1.x Version of OKI Framework Spec.  Implementations of Framework APIs  Collection of Exemplar Tools/Applications (Including “LMS” Solution)  Developer Community Strategy  Sustainability Strategy

88. APIs  Definitions Example API

89. APIs  Definitions  Implementations Service API Implementation Infrastructure public class Factory implements org.okip.service.APIName.api.Factory { private static final blah blah bhal private static final yada yada yada } … Example

90. Service Based Architecture public class Factory implements org.okip.service.Example.api.Factory { private static final blah blah bhal private static final yada yada yada } … Example API … org.okip.service.shared.api.Thing things = myFactory.getSomething(); if (null != thingss) { for (int i = 0; things.length != i; i++) { out.println(things[i]); System.err.println(types[i]); } } … Application Implementation Infrastructure Service

91. OKI Services Course MgmtContent MgmtAssessment AuthN Etc… LUIDFileDBCAuthZRules User Messaging LoggingEtc… Shared Objects Educational Service APIs Common Service APIs Educational Service Implementations Common Service Implementations Educational Software “LMS” Institutional Infrastructure

92. Example public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal private static final yada yada yada } … Authorization … org.okip.service.shared.api.Type[] types = myFactory.getAuthenTypes(); if (null != types) { for (int i = 0; types.length != i; i++) { out.println(types[i]); System.err.println(types[i]); } } … public class Factory implements org.okip.service.authentication.api.Factory { private static final blah blah bhal private static final yada yada yada } … Authentication public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal private static final yada yada yada } … Assessment Admit One

93. Same Application Using Different Implementations Service 1Service 2 Application A Service 1Service 2 Application A

94. Two Back End Systems – Single Access Method Class Admin Enrollment App. SIS System HR System

95. Implementation Supporting Multiple Protocols API X SRMISOAP Infrastructure Service Supporting both SRMI And SOAP

96. Kerb5 One Application Using Multiple Implementations of One API X509 AuthN App

97. Independent or Tightly Coupled Implementations AuthNAuthZAuthNAuthZ Application A

98. End of Part 2

99. Dimensions of Sustainability for OKI Influence Evolution Conformance Sustainability Adoption Support

100. End of Part 3

101. Influence and Outreach  Related initiatives/projects  IMS/ADL  Digital Library  Interest and Adoption  Licensing Arrangements (IP)  OKIO

102. OKI in a Nutshell An Application Before OKI

103. Thank You  Moving Ahead…

104. OKI in a Nutshell An Application Before OKI An Application After OKI

105. Logical and Schematic Models API App API Implementation of API 1 App

106. Same Application/Different API Implementations (Modularity) API 1API 2 Application A API 1API 2 Application A

107. Different Application/Same API Implementations (Portability) API 1API 2API 1API 2 Application B Application A

108. Two Back End Systems Supporting Single API Class Admin Enrollment App. SIS SystemHR System

109. Example public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal private static final yada yada yada } … Authorization … org.okip.service.shared.api.Type[] types = myFactory.getAuthenTypes(); if (null != types) { for (int i = 0; types.length != i; i++) { out.println(types[i]); System.err.println(types[i]); } } … public class Factory implements org.okip.service.authentication.api.Factory { private static final blah blah bhal private static final yada yada yada } … Authentication public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal private static final yada yada yada } … Assessment QuizID = “Chem100Final” Assessment.getQuizElements(QuizID) Admit One Authorization. getAuths(myPerson,QuizID) myPerson = Authentication.getAgent()

110. OKI Service Framework  Specifications Course MgmtContent MgmtAssessment AuthN Etc… GUIDFileDBMSAuthZRules User Messaging LoggingEtc… Educational Component APIs Common Service APIs Common Objects

111. OKI Service Framework  Specifications  Implementations Course MgmtContent MgmtAssessment AuthN Etc… GUIDFileDBMSAuthZRules User Messaging LoggingEtc… Educational Component APIs Common Service APIs Educational Service Implementations Common Service Implementations Common Objects Institutional Infrastructure

112. OKI Service Framework  Specifications  Implementations Course MgmtContent MgmtAssessment AuthN Etc… GUIDFileDBMSAuthZRules User Messaging LoggingEtc… Educational Component APIs Common Service APIs Educational Service Implementations Common Service Implementations Common Objects Institutional Infrastructure

113. Data Exchange Enterprise System Enterprise System Enterprise System

114. Data Exchange SISLMS Digital Library

115. Data Exchange MITSIS Stellar 1.x DSpace

116. Service Framework SIS Educational Software Services Digital Library Common Services Tools Infrastructure

117. Service Framework MITSIS MIT Educational Software Services DSpace MIT Common Services Tools Infrastructure Stellar

118. Service Framework SIS Educational Software Services Common Services Tools Digital Library Services Infrastructure

119. Web Service Implementations? Web Service X SOAP Imp.of X API X WS Registry Server UDDI WSDL App. A

120. Web Service Implementations? Imp. of X API X Web Service X SOAP Imp of X API X JavaC++ WS Registry Server UDDI OKI Based WSDL Spec? WSDL App. AApp. B

121. Web Service Client Application SOAP API X Web Service X WS Registry Server UDDI WSDL Perl? C? Web Service Applications? Same OKI Based WSDL Spec?

122. Web Service Client Application SOAP Web Service WS Registry Server UDDI WSDL Web Service Applications?

123. WS Client App API X WS X Registry Web Service? WS X Registry

124. WS Client App API X WS X Registry Web Service? WS X

125. Stellar on OKI Stellar 2.0 HTML Web Server

126. Web and Client App Interoperability Stellar 2.0 HTML

127. API Implementations May Call APIs API 1API 2 Application X AuthNAuthZDBCLUID

128. “LMS” Varying Granularity of Service Exposure Assess Application Y AuthNAuthZ C.M.Etc. AuthZ Assess Application Z C.M.Etc.

129. API 1API 2

130. Generic Rule Model Subject Verb Predicate

131. Authorization Model Agent Function Qualifier

132. Digital Rights Model? Party Right Content

133. Learning Asset LA Authorization Workflow Rights Etc…

134. Stay Tuned http://web.mit.edu/oki

135. Client Objects Client Apps Client Objects Client Apps Client Objects Web Apps Browser Client Objects Web Apps Browser Client Objects Client Apps OKI ServicesOKI Clients Campus Infrastructure OKI Service Model

136. Multiple OKI Servers Serving Different Content, But Sharing Some Enterprise Services SIS Data Authentication/ Authorization Digital Repository SIS Data Digital Repository

137. Multiple OKI Servers Sharing Common Infrastructure Services SIS Data Authentication/ Authorization Digital Repository Messaging

138. OKI Processes Common Services OKI/LMS Services Pedagogical Tools User Experience Infrastructure EALP Architecture Sustainability Common Services LMS Services OKI Tools User Experience Infrastructure

139. SIS Educational Software Services Digital Library Infra- structure Tools

140. OKI Service Framework  Specifications  Implementations Course MgmtContent MgmtAssessment AuthN Etc… LUIDFileDBCAuthZRules User Messaging LoggingEtc… Educational Service APIs Common Service APIs Educational Service Implementations Common Service Implementations Shared Objects Institutional Infrastructure

141. OKI Service Framework  Specifications  Implementations  Localized  Modular Course MgmtContent MgmtAssessment AuthN Etc… LUIDFileDBCAuthZRules User Messaging LoggingEtc… Educational Component APIs Common Service APIs Educational Service Implementations Common Service Implementations Shared Objects Institutional Infrastructure

142. OKI Service Layers Course MgmtContent MgmtAssessment AuthN Etc… GUIDFileDBMSAuthZRules User Messaging LoggingEtc… Shared Objects Educational Component APIs Common Service APIs Educational Service Implementations Common Service Implementations Educational Software “LMS” Institutional Infrastructure

143. OKI Requirements for IMS Educational “Application” Services Common Services Class AdminContent Mgmt Assessment (Quiz and Test) AuthN Communication (Discussion Chat, Etc.) LUID “GUID” FileDBMSAuthZRules User Messaging LoggingSched. Etc… Work- flow Etc…

145. The Importance of an Architectural Framework IMS Quarterly Meeting April 29, 2002 Scott Thorne Senior Systems Architect, MIT

146. MIT Systems Which Keep Track of People LibraryParkingAccountsSportsRegistrarAlumniDirectoryLMSHR/PayrollResearchLincoln

147. Data Feeds of Person Information LibraryParkingAccountsSportsRegistrarAlumniDirectoryLMSHR/PayrollResearchLincoln

148. EmployeesStudents Library Users Parkers Medical Subscribers Learners People on Campus

149. Implications  Need for Integration  Differing Degrees of Integration  By Function  Authorization, but not Calendaring  Different Sets Ex: Employees & Students  Degree of Coupling

150. Group Functional Specification  Add a new group  Delete a group  Add a member to a group  Remove a member from a group  List all members of a group

151. Group Integration Group Function Group Service System ASystem B

152. Different Group Integration  Systems each maintain copy  Synchronization strategy  One system maintains groups, others only read  Differing timeliness  Systems both maintain common groups  Systems maintain different sets of groups  Read all sets  Common service

153. Group Integration Group Function Group Service System ASystem B Group Function System C

154. Group Integration Issues  Who should be allowed to maintain groups?  How does System A know how to use the new group system B defined?  The system of record deleted the group, what should the subsystem do?

155. Benefits of Architectural & Functional Specification  Perspectives; User, Vendor, Higher Education  Easier and better Integration with the Enterprise  More Choices  Better interoperability >> Best of functionality

156. How to Proceed?  Data Specification  Existing  Changes, Specific Profiles  New Areas  Functional Specification  Universal Definition (UML)  Multiple Bindings

157. Questions?

158. Possible Integration Goals  Allow enterprise systems to exchange & synchronize information  Allow different organizations to exchange & synchronize information  Allow systems to use enterprise services  Allow for modular software which plugs into a known framework  Single System Responsible for Information

159. Systems Exchanging Data System A System B 1 2

160. Data and Functional Specification  Data standards serve two goals  Data exchange inter/intra enterprise  Both Data & Function needed for all Goals  Data duplication and propagation  data specifications can’t address all issues  Both Needed for Interoperability  And more!

161. Systems Integrated Functionally System ASystem B 2

162. Deployment Possibilities  One system using another systems service  Framework & Component  System using enterprise service  Allow for system to use service to hide:  Functions performed different places  Different system responsible for data sets

163. Demo

164. Local File Implementation of API File Sync Demo