Linking research & learning technologies through standards

In a previous blog post we discussed a demonstration of the emerging IMS Learning Information Services (LIS) specification. The demonstration used IMS LIS to share learner and course information between a student information system (Campus Solutions) and learning environments (SAKAI, facebook, beehive):

LIS demonstration

In this post, we’ll reflect on the architecture Oracle used to implement the demonstration, and compare it with how the Schools Interoperability Framework might solve the same problem.

LIS demonstration architecture

The Oracle demonstration used web services following the LIS specification for direct communication between Oracle’s Campus Solutions and the Sakai learning environment (using an open source Sakai LIS web services extension built by Unicon). To access the other non-LIS-enabled environments, Oracle deployed an Enterprise Server Bus to translate LIS service calls into REST calls used by facebook and Beehive.

LIS demonstration architecture

The Enterprise Server Bus has to do a bit of work converting the LIS SOAP service calls to REST calls: the mapping between SOAP calls and the REST calls is not always one-to-one.

Based on the experience gained from the demonstrator, the LIS working group is considering a REST binding for LIS. This represents a new direction for IMS, which has traditionally specified messages using SOAP and WSDL. The LIS working group sees REST bindings as important enabler for integrating with web oriented services like Facebook, for which SOAP is a non-starter. For that reason, IMS is devoting a session at its upcoming February 2010 quarterly meeting to the topic of REST bindings.

SIF architecture

We’ve blogged previously about the Schools Interoperability Framework (SIF) that

brings together the developers and vendors of school technology with the federal, state and local educators who use that technology … to define the rules for data movement between applications—efficiently, accurately and automatically—in the SIF Specification.

In Australia and the UK SIF has deliberately deliberately been rebranded SIF to the Systems Interoperability Framework to reflect the generic architecture afforded by the specification. In Australia, the SIF AU project is leading a joint effort and commitment by all Australian school systems to develop an Australian implementation of SIF. The project is progressing well, currently involving a mixture of pilot implementations and specification development that resulted in the release of version 1.0 of the SIF Implementation Specification (Australia) in November 2009.

The first diagram in the Australia specification hints at what a SIF architecture supporting the Oracle demonstration might look like.

SIF architecture

SIF Infrastructure is built around a

a message queue for reliable delivery of asynchronous SIF messages and related synchronous administrative functions—the Zone Integration Server (ZIS)

A ZIS is fulfilling a similar function as an Enterprise System Bus in a service oriented approach: it mediates between disparate systems, ensuring interoperability by formulating messages in a common framework and structure, and routes messages according to business logic. SIF is nowadays being presented as a heavily-profiled SOA; so a ZIS is consistent with a service-oriented architecture approach, and one could easily imagine a ZIS replacing the Enterprise Server Bus in the Oracle diagram.

Comparison

This post isn’t going to recommend one approach over another. Rather, the aim is to reflect on the commonalities and differences between the approaches. It is, after all, interesting that these two approaches are so similar: both approaches define service oriented infrastructure for data synchronisation, both define XML data models for the data being synchronised and both use a messaging queue (ZIS and ESB) for transport and to encapsulate business rules.

An interesting difference between the approaches is that SIF is more “web oriented”, whereas LIS is more “enterprise web service oriented”. That is, SIF transports plain old XML over HTTP or HTTPS, whereas LIS transports XML in SOAP packages over HTTP or HTTPS. This difference largely reflects the web service orthodoxy around when each of the specifications was written. The SIF specification was written in 2003 when XML over HTTP was considered standard practice. LIS was written in 2009 when SOAP was the orthodoxy, but REST was gaining ground. Your mileage may vary on which is a better approach: enterprise architecture folks like WSDL and SOAP because there are tools that support it (you can generate code from WSDL), and it is (allegedly) more secure; web folks think that SOAP messages are bloated and add unnecessary overhead for most simple applications. In a way, IMS LIS support for a HTTP REST binding for LIS would let them have a it both ways: SOAP if you want that, RESTful HTTP otherwise. It is also worth noting that SIF is considering SOAP versions of some of their services to ease integration with SOAP only systems. It is unclear, however, whether SIF will (or should) move to a REST style architecture, or just stick with XML over HTTP.

Another interesting difference is that in SIF, all messages must go through a ZIS. This is not an assumption in the LIS approach: the Oracle demonstration showed Sakai and Campus Solutions communicating directly without an intervening ESB. The common specification of service under LIS allows point to point integration. SIF, on the other hand, specifies an entire web service framework where all integration happens through a ZIS. Whether this architectural difference is significant remains to be seen. I suspect the ZIS approach makes it easier for SIF to write conformance tests that test the whole infrastructure; something that IMS LIS is just grappling with now. It would also certainly be possible to implement a trivial ZIS that just transparently passes messages between two applications, essentially negating the need to go through a full ZIS intermediary.

A major difference (and similarity!) between the approaches is their data models. Much of the specification development time in both approaches has been spent defining the data that gets passed around. The SIF data model reflects six years developing an understanding of information applications need to swap. Similarly, the data model in LIS is a refinement of the existing IMS Enterprise data model, which has been in development for 10 years. Both of the resulting data models are huge and are usually profiled for easy use: the SIF AU data working group has spent many months refining the international SIF data model to meet Australian needs; the IMS LIS working group has created a Higher Education “base profile”.

The relationship between these significant education data models is an open question. Given they support very similar requirements, one would hope they are similar (at least conceptually) and could be (physically) mapped to each other. As a whole the mapping task would be huge, but might be tractable for some specific use cases: it is pretty easy to imagine a scenario were student information transmitted from a school into a university enrolment process).

Summary

Hopefully the comparison above shows that there isn’t much conceptual difference between the LIS and SIF approaches. They are ultimately solving similar problems: ensuring interoperability between disparate systems (including legacy systems), through messages between systems relying on a common semantics. The differences lie in the underlying web technologies they use and the sectors they (originally) focussed on. Perhaps having two specifications in the space shows that service oriented approaches to education system integration are finally coming of age.