Forum .LRN Q&A: What is OKI, and what should dotLRN's relationship with it be?
I have been getting questions lately about what OKI is and how to make sense of it in the dotLRN context.
First off, the authoritative place to find out about OKI is the OKI web site. Quoting the General Overview on specifications page, "The OSID's are an abstraction layer between the programmer and the enterprise infrastructure systems of his or her campus".
If you hunt around and download the source code from http://sourceforge.net/projects/okiproject you'll discover that the OKI is implemented in Java. Hmm, does this mean that the only way to be OKI-compliant is to program in Java? Not necessarily. In face-to-face meetings and perhaps also on the web site (I can't seem to find it now), the OKI team has stated that their ideas are larger than Java, but for sake of concreteness they had to build in a specific language.
What would it mean to be "OKI-compliant" in a non-Java system? Here is my take. There are parts of OKI that are tied to the runtime environment and parts that are not. In a world with multiple runtimes, the OKI idea gets diluted because my Tcl code will not be "plug-and-play" with your Perl code or someone else's Java code. Fine. How about within a runtime? Can we benefit from standard interfaces that everybody follows? Absolutely. That's what OpenACS Service Contracts are all about.
So if we use Service Contracts everywhere, would that make us OKI-compliant? This is where things get interesting. My is answer is a qualified "yes". Because the OKI-team has been largely mum on non-Java implementations, there is probably room to establish ideas about what it would take for a non-Java version to get the OKI seal of approval, and then work with or lobby OKI to grant that seal. Whether or to what extent this community wants to undertake that work is up for debate. That's part of the reason for this post.
To make things a little more concrete, let's take a closer look at what OKI is about and consider the character of an implentation that might win approval:
(This following used to be a beautiful HTML table but forums nixed my TABLE tag. See the original version.)
OKI idea: A conceptual notion of architecture. Example: Access to authentication databases should be standardized; we will have an Authentication API.
Hypothetical dotLRN incarnation: dotLRN will have an Authentication API
Depends on runtime? No
OKI idea: A conceptual notion of what APIs apis will look like. Example: Users and groups will be encapsulated in an Agent class that contains a getDisplayName() method for accessing the display name of the user or group, and a getId() method for accessing the unique ID. Identities will be obtained by calling the authenticate() method of the AuthenticationManager class."
Hypothetical dotLRN incarnation: dotLRN will have an Agent data structure with DisplayName and Id members. dotLRN will have an AuthenticationManager service contract with an authenticate operation.
Depends on runtime? Sort of. We don't really have "classes" in Tcl, so we'll have to approximate them with data structures (e.g. Tcl arrays). We don't have "interfaces" either but service contracts are reasonably close.
OKI idea: There will be published, standard language-specific interfaces for the APIs. Implementors will build various implementations for applications and frameworks to consume.
Hypothetical dotLRN incarnation: There will be published, standard OpenACS Service Contracts for the APIs. Implementors will build various implementations for applications and frameworks to consume.
Depends on runtime? Yes. We can only inter-operate within the OpenACS realm.
Now, I think we'd all agree that following the OKI ideas in some form or another is a Good Thing. Hence we have the great work Collaboraid has done on the external authentication spec. The open questions are, whether to spend the energy to establish an interpretation of OKI-compliance for dotLRN, and then having that, to determine on a domain by domain basis whether and how to work toward that compliance.
If you made it this far, do you buy the above? If so, do you think we should invest in working with/on OKI? What about authentication specifically? With or without OKI, we have a good, mature spec. IMHO we shouldn't let it get bogged down. At the same time, we may be able to reach compliance fairly easily (that remains to be seen). If we could reach compliance with little additional effort, say with a few changes of variable names, would it be worth it?.
I would then say - can we think of some use cases? We at Cambridge would be pleased/impressed if we could use Stanfords Coursework for content management, but use dotLRN/OpenACS communities within and across courses. Stanford have not implemented all of the OKI API's, but they are using authentication. They are also working on implementing more.
So in Andrew's 3 'ideas' above, 1 & 3 may be useful to OpenACS, but do not serve the objectives of OKI that I have described so whether we use OKI to achieve them is simply a question of whether the OKI work helps the dotLRN/OpenACS project. Idea 3 on the other hand seems to suggest that interoperation is doable. I would strongly encourage looking at this.
Finally, as I understand it. OKI have worked with Sun (with the UK eUniversity architecture) to converge on the OSIDs and to put them up to IMS. I believe a web services binding as well as a Jave binding is expected at some point.
CETIS in the UK is charged with representing UK Universities at IMS and has a good web site explaining the various learning technology standards (http://cetis.ac.uk). There is a link on the home page to a report from the recent OKI/IMS Alt-i-Lab meeting that I attended.
We at Cambridge would be pleased/impressed if we could use Stanfords Coursework for content management, but use dotLRN/OpenACS communities within and across courses.
Hi John, I think this use case has a lot of value, but have you seen any indications from the OKI team that they are trying to support it? From everything I've seen and heard, I think not. I could be wrong, but my impression is that at best OKI intends to enable the creation of "islands of compatibility" in which you get plug & play within a particular language and platform.
I believe a web services binding as well as a Jave binding is expected at some point.
I've thought quite a bit about what it would mean to have Web Services bindings, and I don't see it working out. Or at least not without huge amounts of investment. OKI has made very specific assumptions which do not fit very well with Web Services. They favor method signatures that can accept and return behaving classes. Moreover, these classes are specified by their interfaces, such that the implementation can vary at run time. In Web Services, by contrast, you're typically dealing with method signatures that handle behaviorless data structures. There is no "passing by interface" in Web Services.
As one example of the problem, consider Authentication. A user is authenticated by the
AuthenticationManager.authenticate() method. If this method is running locally inside a GUI program, it can spawn a text prompt or login window. If it is running locally inside a web server, it can reach into a global context and grab cookies or security certificates. But if it is running remotely on some other server, it has no easy way to retrieve user credentials. Perhaps one could program elaborate session systems that maintain state between OKI consumers and OKI providers. But this will be complex and expensive, and maybe will never work.
It's a bit like the couple that has been dating for many many years. One of the couple asks: "When are we getting married?. To which the other replies: "In theory, I am not opposed to marrying you."
In the interim, one way to think about Sakai is as a collection Java frameworks for developing uPortal-compatible learning tools with some reference implementations along for the ride. (See http://weblogs.java.net/blog/simstu/archive/2004/09/sakai_open_sour.html for a developer's perspective on this point.) To the extent that the project continues to use OKI, then OKI will survive, whether or not MIT continues to support it. (In some ways, MIT is the last institution I would use to gauge adoption of anything--even stuf they have created themselves.) As the framework that is Sakai matures, we'll see what happens to OKI.