O.K.I. Overview

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…

...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…

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.

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

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)

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 … http://sourceforge.net/projects/okiproject

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

Example: Digital Repositories of Educational Content

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

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

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

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

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

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

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

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

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

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)

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

Enterprise Applications - Monolithic

Enterprise Applications - Factored

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

Integration Effort as a Function of System Complexity

Ease of Application Portability and Infrastructure Transition

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

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]

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.

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.

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.

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!

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

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.

A single application with a module of functionality Group

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

The module is outside the application, but still local Group

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

Integration of two applications with a single service Group

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

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

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

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