view printer-friendly version (opens in new window)
OKI releases first batch of specs
The Open Knowledge Initiative (OKI) publicly released the first of the long awaited Open Service Interface Definitions (OSIDs)- the connecting bits for the OKI managed learning environment architecture. With these OSIDs, adopters can string together student records systems, virtual learning environments, management information systems and other enterprise applications with a minimum of customisation.
Unlike other elearning interoperability specifications such as those by IMS, OKI's focus is not so much on data, as it is on services. To simplify greatly, OKI seeks to define things much like you would gas, water, phone and electricity connections in a house. As long as the services are provided in a standard way, then anything that could make use of it, can connect to it.
The kinds of services that can be provided or tapped into with the OSIDs that have been released now include things like user authentication and authorization, filing, database connections, user logging, a multilingual dictionary, and more abstract services (hierarchy and shared) that can be used to build other services.
Enterprise integration is slightly more involved than just agreeing on the number of pins and a plug's shape, however. So in practice, the OSIDs are APIs that allow programmers to connect to the services and manipulate them from within another program by sending standardised commands.
Should there be such a thing as an OKI compliant authentication service on an institution's network, for example, then any other OKI compliant system that needs authentication could hook into that service internally rather than force a user to set up yet another username and password just for itself.
As always, of course, there are some trade-offs with such standardised goodness. First, the APIs are necessarily a bit language and thereby platform specific. So the good news is that today's APIs can be dropped almost straight into java applications. The bad news is that there aren't any bindings to other languages such as C# yet. Not that this is impossible, but it would be quite a job of work.
Other trade-offs are slightly more fundamental. In order to provide a useful service, you have to have some idea of the kinds of functions that need to be fulfilled on a institutional network, which systems fulfil them, and how they relate; i.e an architecture. OKI has defined one based on layers of services (from the very fundamental enterprise services to more educational ones) some time ago now, and it is a sensible one. Provided that the systems on the network you've already got can fit into it, that is.
But today's releases are just the start. There are more OSIDs to come for services like Workflow, User Messaging, Scheduling, Digital Repository, Class Admin, Assessment and Grading. On top of that, there will also be reference implementations of the services, as well as two complete MLEs that make use of all these services.
The OSIDs that have been released now are not final releases: they have release candidate four status. Developers are therefore invited to comment on them within the next sixty days on the OKI page on sourceforge. The OSID package can be downloaded from there as well.
More information on the OKI project is available on the OKI website at MIT.
No responses have been posted