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

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

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

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.

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

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

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

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

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

What Next Evolving API’s MIT Implementations Development Community