1. Scott Thorne & Chuck Shubert
OKI – Common Services
ITAG Lunch
Scott Thorne & Chuck Shubert
March 13, 2002

2. What is OKI? Infrastructure for Educational Software Mellon Funded
Collaborative
Higher Education Partners
Standards Groups
Open Architectural Specification

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

4. OKI Service Layers “LMS” Educational Software
Course Mgmt
Content Mgmt
Assessment
AuthN
Etc…
GUID
File
DBMS
AuthZ
Rules
User
Messaging
Logging
Common
Objects
Educational
Component
APIs
Service
Educational Service Implementations
Common Service Implementations
Educational Software
“LMS”
Institutional Infrastructure
The end goal of all of this is to encourage and support a wide range of pedagogical tool and educational application development activity and to allow these tools to be shared more easily among our campuses. These pedagogical tools and applications are what the end users of OKI based systems will see and interact with. In other words, users will never need to know about the framework underneath, they will simply reap the benefits of this infrastructure integration though interoperable applications.
Among activity we envision at the application layer is the development of traditional web-based “Learning Management Systems” like MIT’s Stellar or Stanford’s CourseWork. Such application suites may present added value through integrated user interface (perhaps via a web portal) and UI developer toolkits.
But the OKI learning framework is being designed to support a far more diverse world of tools and application suites. The notion of “one size fits all” has quickly proven false for those in higher education who would like to experiment with applications that really push the boundaries in supporting pedagogy. In fact, it is clear that web-based applications alone, while important for supporting perhaps 80% of our technology enhanced teaching and learning needs today, do not adequately address a number of growing requirements. Desktop applications and other means of providing rich user experiences will be necessary as we move forward.

5. Why use API’s Integration Independence Code Reuse
Development Discipline
Protocol vs API?

6. Campus Infrastructure
OKI Service Model
Campus Infrastructure
OKI Clients
OKI Services
Client
Objects
Client Apps
Browser
Client
Objects
Web Apps
Browser
Client Apps
Client
Objects
From the perspective of the OKI architecture, the world is made up of either infrastructure or clients. Clients include “stand alone” applications as well as complete suites of web-based learning and course tools (ala Stellar or Coursework) The services we are describing don’t know or care about the user level graphical environment. In other words, we are not limiting this to a web based thing.
Defining and promoting a single approach for user experience design is not in OKI’s scope and indeed we have come to believe that it is not in the best interests of Higher Education or the market. As an infrastructure service spec OKI is better positioned to support a diverse and competitive marketplace, including both contributions from open-source activities as well as proprietary vendor solutions. This philosophy is critical especially as we are seeing that “one size fits all” is no longer a viable notion with respect to educational technology.
However, through further development of its “Stellar” web-based integrated learning/course management system, among other projects, MIT intends to provide open-source exemplars of the kinds of applications the OKI architecture is designed to support
Another key element of OKI is the server to server protocol. While, in the future, we my expect cross domain authentication and authorization schemes to allow fluid access across multiple OKI based applications (allowing, say, a student at Dartmouth to directly access resources at MIT) the near term OKI solution assumes that users will be authenticated only with their “local” OKI sites, and that sharing of resources will be possible through site to site communications likely based on out of band authorization agreements between sites. However (see next slide)…
Browser
Client Apps
Client
Objects
Browser
Client
Objects
Web Apps

7. Applications Sharing Some Enterprise Services
Digital Repository
Authentication/
Authorization
The OKI approach does not preclude multiple service sites sharing some services while keeping others local. The diagram above shows two OKI sites sharing a security infrastructure while keeping others local. This may very well represent the type of set up that could be common at institutions with a highly resourced professional school that simply wanted to share the institutional security scheme while leveraging local resources like library and student information data.
This might also represent how institutions might begin to share cross-domain security schemes as they become viable.
Digital Repository

8. Common Services Authentication Authorization Logging DBC File
User Messaging
Local Identifier
Calendar & Scheduling
Workflow
Rules

9. API Design Balancing Act Generic & Flexible Specific & Precise
Stable & Simple
Full Function

10. What Next
Evolving API’s
MIT Implementations
Development Community