view printer-friendly version (opens in new window)
IMS presents public draft of Enterprise Services, reference implementation to follow soon
IMS Enterprise Services for Web Services is in effect a successor to Enterprise; IMS' venerable spec for person and group management. Where the old one was just a data format, the new provides a means to exchange, say, enrollment data between a VLE and student record system dynamically. A reference implementation was developed by CETIS at the same time, and will be available at the same time as the full release.
IMS Enterprise Services for Web Services (affectionately known as ESWS) is one of the first of the IMS next generation specifications. Following the broad outline of the IMS Abstract Framework document, ESWS is a major set of building blocks that can fit into a variety of Managed Learning Environments (MLEs).
The plural is significant, as that constitutes another major difference with the old Enterprise spec. Where the latter was a single definition, the new one is a set that defines both data, messages and a service definition (a machine readable outline of how to communicate) for person, group and membership data. That also means that ESWS is designed to work in environments that are equally component and service based.
The component basis means that not every programme or website that can make use of student record type information needs to implement the whole spec, just the bits that are needed. Coupled to the this is the service orientation, which means that all the hard work of processing person, group and management information can be done elsewhere. The upshot is that it becomes possible to create useful little desktop applications or website functions cheaply and easily. A reasonably skilled scripter can knock together a enrollment tracking application in an afternoon or so, since it all it needs to do is ask the enterprise service the right question, and display the response.
Conversely, ESWS can also provide a means of communication that is sufficiently robust for heavier data integration such as synchronising an FE college's Management Information System (MIS) with a partner institution's Student Record System (SRS). Provisions are there to make sure that systems can keep trying to get a transaction right in case of an error, and an audit trail can be constructed of what exactly happened.
The other advantage of component and service orientation is that it becomes much easier to replace the different parts of an MLE. Swapping out an SRS, library system, or that handy little program the techy made to create automatic course mailing lists, no longer requires changing everything else. The enterprise services are there, whichever system provides it or consumes it.
There are, however, a few obstacles to be overcome to realise this vision.
With regard to the spec, it should be borne in mind that the data model it uses is the same as the old IMS Enterprise spec. That makes it easier for Enterprise compliant systems to implement ESWS, but it also means that the weaknesses of that spec still apply. Chief of these is that it requires consensus about what things like 'course' or 'module' means. Either Enterprise or ESWS will happily let you group people together by any criterion, but that is only of use if the interoperating systems have the same understanding. An FE college, for example, might want to group students together by funding body, but that may not be meaningful to the SRS of an HE institution. For the UK, joining the CETIS Enterprise SIG can be a way of helping to build the necessary consensus.
Also, ESWS does not have a query function yet. Since IMS doesn't want to make lots of different query functions for its variety of specifications, that functionality awaits further requirements from other areas before it will be developed.
Other obstacles all have to do with implementation. If systems provide no means of talking ESWS to each other, we'll stay with the uncommunicative and monolithic systems most people have today.
To this end, a reference implementation has been developed by CETIS at the same time as the ESWS spec was drawn up. This has three advantages: it helps make sure that the spec is implementable, it makes it much easier for developers to understand what it means to get their application to talk ESWS, and, since the implementation is open source, the hard parts can be put straight into new or existing systems. We'll report on the ins and outs of the CETIS ESWS Java code library nearer the release.
Vendors like Sun and Microsoft have also been closely involved with the design of the new spec; Microsoft might provide a matching .net implementation to CETIS' Java library.
Ultimately, however, a sufficient amount of implementations is directly related to what colleges and universities want. If Enterprise Services proves sufficiently useful and the component and service vision sufficiently attractive, it becomes worth developers' while to include it in their offerings.
The public draft specification documents are available from the IMS website.