1. O.K.I. Overview

2. Motivation: from Extensible, Web based LMS…
Interoperable with campus infrastructures and other educational software
Flexible to meet a variety of Educational Needs
Scalable and Maintainable
to…

3. ...Architecture for Sustainable Ecology
Open specifications that
describe how the components of a learning technology environment communicate with each other and with other campus systems.
clearly define points of interoperability to allow the components of a complex learning environment to be developed and updated independently of each other
leading to…

4. Architectural Specification Benefits
Ability of learning technologies to be integrated together into an educational infrastructure.
Easier sharing of applications and educational services among institutions that can be a catalyst for cooperative and commercial development.
Lower long term cost of software ownership and development, as well as increased stability and reliability because discrete components, rather than entire systems, can be replaced or upgraded.

5. O.K.I. is: Service based architecture specifications
Open Service Interface Definitions (OSIDs)
Open source implementations
Open source exemplar applications
Educational Development Community
Funded by Andrew W. Mellon Foundation, CMI, MIT
First and foremost, an architecture physically realized through O.K.I. Service Interface Definitions
Open source implementations and applications that demonstrate the use of the architecture and provide examples of learning management components
A community of higher education innovators and developers, including school based developers, researchers, and commercial product vendors

6. The O.K.I. Solution
Focus on Service Based architecture specifications (data/metadata specifications are “doing fine”)
Identify software infrastructure services critical to eLearning applications
Define interfaces to them. Don’t define how to implement them!
Open Service Interface Definitions (OSIDs)

7. OSID development funded by Mellon Foundation
Common Services
Authentication
Authorization
SQL
Logging
Filing
Dictionary
Hierarchy
Agent
Shared ID
User Messaging
Scheduling
Workflow
“Educational Services”
Course Management
Repository
Assessment
Grading …

8. OSIDs… Provide Architectural Model for software interoperability
Allow for easy mobility of application tools among enterprise infrastructures
Provide software developers with common, yet flexible, specifications for collaboration
Define boundaries between “user facing” applications and critical services (“MiddleWare”)
Help to “Future Proof” against changing technologies
Enable “marketplace” of software components
Are about Architecture, NOT Technology

9. Example: Digital Repositories of Educational Content

10. Many Repositories… Remote Institutional Local i M a c I D C I D C I B

11. Many Repository Related Protocols…
Remote I D C
SOAP
SRW
Institutional i M a c
Local I D C
DRI
Z39.50
HTML I B M
File System

12. Many Data Specs/Standards…DC
Remote
Mark I D C
METS
SOAP
SRW
Institutional
IMS CP i M a c
LOM
Local I D C
DRI
Z39.50
HTML I
SCORM B M
File System

13. Service Abstraction for Interoperability
Application Client
Servers
Applications
OSID
Implementations
Protocol A
Network Service A1
Imp. A – Protocol Connector (plus Local Business Logic)
Data
App. 1
Data
Data
Imp. B – Protocol Connector
Network Service A2
App. 2
Data
Imp. C - Local Connector
Protocol B
Network Service B
Local Service C

14. Federating Repositories with OSID Plug-ins
Application Client
Network Repositories
Tools
DR OSID
Plugins
Fedora
VUE
LOBSTER
Celebrate
Clouseau
Celebrate Broker
OCW
Other
ECL
Local XML
Edusource Gateway
iTunes
iPhoto
Local Repositories

15. O.K.I. Community Original Institutional Partners
MIT, Stanford University, Dartmouth College, North Carolina State University, University of Michigan, Indiana University, University of Pennsylvania, University of Wisconsin-Madison, University of Cambridge
IMS Global Learning Consortium Members
Assorted Institutional Projects

16. OSID Based “LMS” Projects
Stanford University
MIT
Course Work – a set of applications around quiz and test
Stellar – Content aggregation and management
Chef – Community model – Learning, teaching and research
Tufts – Visual representation of learning paths, link tool to environment using O.K.I.
University of Cambridge – Learning object tracking, effectiveness
Digital Library Open Source Community
University of Michigan
Indiana University
The Sakai Partners

17. Other OSID Based Projects
Sakai – Umich, Indiana, Stanford, MIT
VUE -- Tufts University
Navigo/SAM -- Stanford, Indiana
Lionshare - Penn State University
Segue/Harmoni - Middlebury College
Digital Library Systems -- Fedora, EduSource (CA), DSpace, Celebrate (EU)
Course Work – a set of applications around quiz and test
Stellar – Content aggregation and management
Chef – Community model – Learning, teaching and research
Tufts – Visual representation of learning paths, link tool to environment using O.K.I.
University of Cambridge – Learning object tracking, effectiveness
Digital Library Open Source Community

18. Vendor Engagement Through IMS Global Learning Consortium Blackboard
Cisco Learning Systems
Giunti Labs
Learning Objects Network
Microsoft Corp
Sun Microsystems
WebCT

19. Ed-Tech Architectural Requirements
Make it easy for software developers to utilize enterprise infrastructure, otherwise they won’t.
Make it possible for institutions to share and collaborate on educational software
Provide ability for integration requirement to be more clearly specified in RFPs
Mitigate technology change
Support both Web and Client based applications
Driven by sustainability concerns NOT research (Pioneers not Trailblazers)

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

21. Enterprise Applications - Monolithic

22. Enterprise Applications - Factored

23. Core OKI Deliverables Open Service Interface Definition (OSID)
“Common Services”
Infrastructure systems critical to most enterprise applications
(AuthN; AuthZ……Logging, Messaging….Workflow)
“Educational Services”
(Course Management; Assessment; Digital Repositories, Grading)
Reference Implementations
Direct value to ed apps
Exemplar Applications
Sustainability Strategies

24. Integration Effort as a Function of System Complexity

25. Ease of Application Portability and Infrastructure Transition

26. Time to Integration with OSIDs Today
Creating a new OSID Plug-in for an existing exposed Repository
Getting it to work with your first O.K.I. App
Getting it to work with the next O.K.I. App
2 Weeks
2 Hours
2 Minutes

27. Assumptions Things Change New Services & Functions
Method of Accessing Services
More Central Software Services
Authorization, Calendaring, etc.
Evolving Systems
Definition
Foremost, O.K.I.™ does not assume a static environment. On the contrary, O.K.I.™ recognizes that things change. Rather than address the needs of institutions only at one point in time, the architecture is designed to last.
Institutions change, and as they do, there is a demand to deliver new services and functions. If all the ways in which a system will be used and all the support it will provide could be known fully, a system could be developed that would serve the needs of an institution indefinitely. Unfortunately, the uses and roles of technology are quite fluid and only an architecture that recognizes this dynamic nature is likely to survive more than one technology cycle. One pervasive area of new function is the rise in self-service applications. In place of intermediaries that arranged services or production, more and more of this kind of work is done directly. A simple example is authoring, wherein we have gone from typing and production services to a mode where people produce copy themselves.
Not only are services and functions likely to change, but the methods of accessing these services will change as well. The devices through which people interact with systems are continuing to broaden. Similarly, there are new modes of connectivity and patterns of access. For example, there was a time when services were available to the minority of stakeholders in an institution that were computer specialists. Now everyone needs to interact with certain systems. Similarly, in place of a single application for accessing information, now there is a demand to have access from the desktop, the web, mobile and handheld devices, and so on. Expectations about flexibility of format, degree of usability, and level of customization continue to rise.
Against this background of change, is a strong trend towards centralization of software services that underlie collaboration and communication. Two illustrative examples are Authorization and Calendaring. Authorization is the means by which we define and enforce who can do what, when. This is a security function akin to authentication and serves an institution best when it is under central and well defined control. Calendaring is less an issue of security and control than it is of enabling collaboration. One’s own calendar can be quite useful. A valuable dimension is added when, through a centralized service, one can schedule activities for and with others, view common events, and so on. Variety in the ways in which one participates and the modes for delivering information are growing, while essential services are centralized to afford scalability, reliability, security, standardization, and support.
Systems are evolving as their user’s needs and technology alternatives evolve. O.K.I.™ was designed in full recognition of this evolution underway and addresses the present as well as the future. [not certain what was meant by definition sub-bullet]

28. 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
O.K.I.™ is intended to foster intra- and inter-institution application and implementation reuse and interoperability. Enterprise systems are not guaranteed to be the same from one institution to another. Even if the systems are from the same vendor, the version, modules, or policies used may differ. O.K.I.™ OSIDs assume this heterogeneous environment and permit Service implementations to cover whatever systems are in place. Similarly, the same systems may not be used within an institution. The benefits derived from being able to reuse and interoperate better, while not having to rip out and replace infrastructure, will be of particular interest when examining the entire range of computing activities at the institution.
The need to share within and among institutions is part of the overall trend of doing more with less. In addition, digital interconnectedness through medium such as the web has accelerated the pace of collaboration and increased the demand for institutions to provide seamless access to information, everywhere. What it means to be connected is both evolving and broadening. As new devices proliferate in form and features, from terminals, to desktops, to mobile laptops, to handhelds, tablets, and phones and as the boundaries of where work can take place widen from office to home or dorm, to lecture hall, and mobile, any enabling architecture has to accommodate this dynamic environment.
The Web has become a key channel of communication, but it is not nor is it likely to be the sole channel for the foreseeable future. It is reasonable to expect the Web to be one of several modes of communication much as we continue to have distinct print, radio, and television media.

29. Goals Better Integration Predictable Evolution
Allow data to be exchanged
Allow software to be integrated
Predictable Evolution
Allow for changing functionality
Minimize the negative impacts
Expanding Market Possibilities
At the core of O.K.I.™ is the goal of better integration among applications. This integration involves both allowing data to be exchanged in a structured way and allowing software applications to operate with each other. O.K.I.™ does not provide data exchange formats or data specifications, rather it provides a means for exchanging data without knowing about or being restricted by the format. O.K.I.™ does not provide a protocol, rather it provides Service abstractions that permit different systems to arrive at a common channel of integration without limiting the systems themselves.
Concomitant with integration is the goal of predictable evolution that allows features and function to change while minimizing negative impacts. By holding the Service abstraction fixed, other change is more manageable and less disruptive than when all elements can vary. The particulars of implementation and back-end systems are free to evolve while communication crossroads are constant.
It is a goal of O.K.I.™ to expand the market possibilities for applications that consume Service implementations and for the implementations themselves. The market is both within the institution and without. This fosters best-of-breed solutions and permits specialization and focused investment. A wide market for each product increases the customer base over which to capture the return on investment in developing the product.

30. 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
O.K.I.™ has additional goals for integration. These are refinements on the general goals of data exchange and software integration. Enterprise systems should be able to exchange and synchronize information. As the access points for information proliferate, so do the challenges of ensuring data integrity and control. By providing a single Service abstraction, implementations can centralize and manage information flow while offering flexibility with regard to where and how the information is consumed. Similarly, beyond exchange and synchronization within an institution is similar integration among institutions. This can be very valuable as individuals collaborate and participate across campus boundaries and as institutions seek to lower the barriers to exchanging and exposing digital assets.
Enterprise systems are designed with the scale, efficiency, security, manageability, and maintainability of large operations in mind. The burden of understanding how to integrate with these systems can far exceed the resources of small projects. The O.K.I.™ Service Definitions hide all of enterprise system detail and complexity, thereby allowing all applications, large and small, to benefit from a common infrastructure.
Applications do not want to have to invent services for each solution nor write to a shifting set of basic infrastructure. O.K.I.™ allows applications to build atop stable and well-defined Services and to focus exclusively on higher-level features and human factors.
Throughout these goals is the theme that there are benefits to having a single system responsible for preserving information. The modes of delivering and presenting information vary, while the information itself is effectively managed through a single point of control. This strikes the vital balance between the needs of applications and their users for flexibility and the needs of operations for scalability and security.

31. 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!

32. Interface and Protocol Specifications
Interface specifications make life easier for the Application Beveloper
Protocol Specifications make life easier for the Service Provider
Both are required, and both make life easier for the Systems Integrator

33. The OSID Approach OSID are Interfaces only, not Implementations
Code Reuse
Can Achieve Real-time Integration
Clean Separation or Boundaries
Minimizes Impacts of Changes
Interfaces facilitate reuse of application source code since the same application can be used with more than one implementation. Implementation source code can also be reused to serve more than one application. With stable interfaces, development resources can be focused on perfecting applications and implementations and do not need to address as many integration issues.
The expression of the OSIDs in Java™ and other languages can be used to achieve real-time integration. Specifically, the OsidLoader for Java™ dynamically loads a class that implements a specific Manager interface. Since applications work with interfaces and uses Managers to create object instances, the decision as to which implementation to use can be deferred until runtime. One implementation can replace another without the need to recompile or close the current session.
Another virtue of interfaces is that they separate and structure the flow of instructions and information between an application calling the interface and the implementation supporting it. It is not important for the application to know the internal workings of the implementation, except in the general sense that it faithfully supports the intent of the interface and possibly some other characteristics.
Stable interfaces minimize the impact of application or implementation change on each other and on other elements in an integrated solution. Known integration points allow for less disruption when new applications and implementations are substituted for old. Similarly, investment in development training, testing, and tools can be preserved when interfaces are constant elements in complex systems.

34. A single application with a module of functionality
Group

35. An application using an OSID internally, but with no real benefit
Group

36. The module is outside the application, but still local
Group

37. A client-side OSID and a remote service
Remote Machine
Group
Data Store

38. Integration of two applications with a single service
Group

39. Introduction of a common tool for Group management
App 1
Group
Mgmt
Tool
App 2
Group

40. Group maintenance can be removed from applications
Mgmt
Tool
App 2
Group

41. Goals of Interoperability Enterprise Information Systems
Data Exchange/Synchronization
Enterprise Integration
Application Portability
Tool/UI Integration
Language Integration
Inter-Enterprise Resource Sharing
Etc…

42. Goals of Interoperability Enterprise Information Systems
Data Exchange/Synchronization
Enterprise Integration
Application Portability
Tool/UI Integration
Language Integration
Inter-Enterprise Resource Sharing
Etc…
O.K.I. OSIDs