Common Behaviour: IMS and OKI consider architecture issues
At the IMS Open Technical Forum in San Francisco, a panel of representatives from Carnegie-Mellon, MIT and IMS discussed using layered architectures to simplify the process of developing software and content for learning.
This was in many ways the 'sequel' to the IMS architecture panel in Ottawa earlier this year. After Ottawa, there were subsequent intensive discussions by the panellists in Pittsburgh, some of the outcomes of which informed the San Francisco presentations.
The panel once again comprised Dan Rehak of Carnegie Mellon, Scott Thorne and Jeff Merriman from MIT, and IMS's Mark Norton.
According to Norton, "IMS traditionally focussed on defining data interchange specs, but as we've started to reach for more powerful and sophisticated interoperability have to come up against the need not just for common data but common behaviour."
"This is a new thing for IMS. Maybe we can capture behavioural concepts. An API is one way to capture some of behaviour in a specification. This panel represents several different constituencies, all working together to move the whole community forward."
Dan Rehak of Carnegie Mellon University expanded on his layered view of learning systems architecture, with common system services at the 'base' supporting tiers of more specific services: "The simple view says we got some infrastructure. On top of that we have programs and commercial products; learning services in a service-based architecture."
"This [architecture] is motivated by current working web services."
Rehak envisions user agents - either people or programs - interacting with a set of tools that use application services for tasks such as searching for learning objects, retrieving learner information and submitting exam results.
Below this application services layer is a set of low-level services and protocols. For example, transport protocols for moving messages and data, discovery and resolution technology for locating other services, and so on.
"Down in the infrastructure you have basic connectivity. On top of that we have emerging web services; which are the tools and [...] the services required. The tools [...] talk to basic services. But will stop at the infrastructure boundary. User agents will not drill down (into that layer)."
There are certain advantages in this layered approach. One is that a user interface can make use of the facilities in the tools layer without the programmer - or the user - needing to know about the deeper supporting infrastructure, which could be changed underneath without - in theory at least - affecting these higher-level applications.
Another key advantage is that many of the low level 'infrastructural' technologies are developed by cross-domain organisations. So instead of inventing a new communications protocol just for education, it is possible to use an existing standard protocol, and concentrate on providing the services in the layer above that are unique to an educational setting.
Existing cross-domain technologies, such as TCP/IP and SOAP, have advantages of being already well known by developers, with existing toolsets and documentation. It also lessens the workload for educational technology standards bodies, as Rehak notes: "from IMS's point of view we want to maximise what other people do for infrastructure. [...] We want to move the boundary up and use existing standards where possible."
By 'moving the boundary' it becomes clearer where the responsibilities of specification bodies begin and end. And using a layered services view makes some IMS tasks, like sequencing, possible to conceptualise in a loosely-coupled fashion: "sequencing is a workflow built from a workflow process. Rather than thinking of tightly integrated process, think of it as loosely coupled under the control of workflow mechanism."
Although Rehak hasn't modified his basic approach greatly since Ottawa, there are now more specific technologies in his layered architecture, and the technological underpinnings are clearer.
To some extent parts of the picture have been filled in by developments outside the learning field, with the provision of web services technology in Microsoft's .NET platform and the rapid pace of development in SOAP, WSDL, UDDI and other open service 'pieces'.
Although these technologies were present six months ago, it is only recently that critical momentum has been achieved, and make Rehak's vision an achievable one.
The API approach: The Open Knowledge Inititative
Jeff Merriman and Scott Thorne joined the panel from MIT, where they are working on the Open Knowledge Initiative. The OKI is a project intended to yield free, open source tools for education.
Although Dan Rehak is using Microsoft's .NET at Carnegie-Mellon, and the MIT OKI project is using Sun's Java technology there is a lot of convergence of ideas, particularly on the layering of services at different levels.
As Merriman explains, one of the key drivers for the OKI project is a "growing awareness that interesting educational development going on and were not doing a good job of providing infrastructure to support these activities."
By providing the infrastructure layers, the OKI project intends to free up effort by its member institutions to concentrate on teaching issues. Merriman also notes the short lifespan of many grant-funded institutional projects; by providing an open framework, intellectual capital expended on such projects may be better retained.
MIT is currently working with a small number of participating institutions to drive development. "We're not architecting by committee; we're using the expertise of these folks to keep us on track. As we expand we'll include many people - many people in this room perhaps."
The first deliverable from OKI will be the release in the "middle of 2003" of 'Version 1.0' of the OKI framework, but said that the project will "have usable versions before [then]".
This framework will consist primarily of definitions of service API's for the 'middle layer' of the architecture. These services include authentication, authorisation, database management, generating unique identifiers (GUIDs), logging, and 'rules'.
"What's emerging as important is the rules API. There are lots of different rules that apply to different components. Rules on sequencing, rights, preferences. There's a whole suite of things and some commonality in how we might manage these things."
Rather than define all the business rules for applications, Merriman is instead envisaging a common set of APIs and tools for defining rules. "The idea is [that] these APIs are available to developers. We can't predict all the kinds of rules with respect of learning applications."
API's - application programming interfaces - are a way to define the 'hooks' that programmers can use to gain access to functionality provided by programs.
So when a programmer wants to build a program that makes use of the Authorisation service, all they have to do is read the API documentation for the service, and put the appropriate calls in their code; it isn't necessary for them to understand how the service makes those calls work. In fact, service developers can make changes to their code without affecting the applications already using the service, provided they adhere to the API specification.
Although the primary deliverable for the OKI is the API definitions, there is also an intention to provide 'exemplar applications' and also to integrate some existing pieces of infrastructure, such as MIT's Roles database. Merriman also didn't rule out the involvement of commercial organisations to supply 'black-box modules' to provide functionality for the OKI, although Merriman admits that at this stage OKI "don't have a lot to say" to Vendors.
Perhaps a key concept in OKI is diversity; Merriman admits that MIT cannot provide a single Learning Management System (LMS) as individual schools will want to choose their own solutions. By concentrating on providing common services the OKI project hopes to foster and support this diversity and allow individual learning systems to be evaluated on their functional benefits in respect of faculty needs.
By isolating tools such as the LMS from core services, the OKI project hopes to protect investment in systems from being devalued by changes in fundamental technologies. For example, if a new common authentication system is developed, the new system will implement the existing OKI API's, requiring no changes to existing tools.
In the immediate future, Merriman predicts that 'very soon' there will be a "draft specification of common services layer for public comment. Early 2002 we will have APIs fairly well baked - 0.8 or 0.9 - so we can start developing against them with the hope that they won't change significantly."
The Open Knowledge Initiative is clearly gathering momentum. It will be interesting to see how the draft specifications measure up to the expectations raised in the education community.
Do the architectures support the needs of lifelong learners?
CETIS Director Bill Olivier, among the delegates at the event, made a plea on behalf of the lifelong learner: "Current architectures don't serve lifelong learners needs. All have an institutional viewpoint. Lifelong learners pass across multiple institutions across their life: at the moment the fundamental problem is that each institution have a portion of the lifelong learner's progress."
Noting a mention by Dan Rehak of the idea of student 'smartcards' providing access to personalised learning experiences, Olivier commented that "[the smartcard] model is the first glimmer of a Personal Learning Management System that complements the web LMS. We have to find a way to let learners have their own information."
"The advantage of functional models is that they don't specify the boundary between servers and the learner's system. This is the lesson of peer-to-peer: not to conflict with client-server systems, but to find out how they can work together."
Olivier warned against designing with "dumb browsers" in mind, noting that for many learners around the world access to Internet services is expensive and unreliable. In developing services for learning providers need to be careful not to assume an 'always on' environment for the learner.
Rehak responded to Olivier's comments by saying "What we've been doing has been to have those very thoughts in the back of our minds all along. What we want to do is push those things down as far as possible in the stack. If I want to find out if [the learner's system] is connected or disconnected I can find out, but I shouldn't have to worry about it."
Jon Mason, of Australia's Department of Education, Training and Youth Affairs asked the panel about the pedagogical aspect of the proposals: "Achieving technical elegance is one thing; validation pedagogical soundness is another. How [is OKI] going about this?"
Jeff Merriman responded by outlining some of the work of the EALP, a committee of educational specialists that provide requirements and scenarios to the technical team working on the OKI project. Despite initial 'culture clash' the two groups were now making constructive efforts and converging in their viewpoints.
IMS CEO Ed Walker commented "the outcome of this [effort is to] put the onus on those with a pedagogic intention to concentrate on that and get away from [concentrating on] the inadequacy of the technology. Their previous experience is frustration with the tools."
This event underlines the serious intent of IMS and other organisations to come to a common agreement on the way the learning systems of the future could be built. The discussions of architectures and service layers should complement the development of 'behavioural' specifications in future IMS releases.
What began earlier this year as a 'blue skies' vision is very rapidly turning into something concrete that vendors and institutions could implement.