One of the challenges facing us when we adopt a learning management system (LMS) is handling staff roles and student enrolments in an efficient and scalable way that keeps pace with late enrolments and registration changes. This requires a robust solution to integration between the enterprise database and the LMS, preferably one that is standards-based, so that once the integration work has been done, it can be re-used in a number of different contexts.
The IMS Enterprise specification describes a way of representing Person, Group and Membership data - or Learner/Teacher, Course and Enrolment - and is an open technical specification for interoperability. Using this specification seemed to move us closer towards the E-Framework model for learning technology of small, agile services loosely coupled with standards-based exchanges of data.
So a team from the University of Sussex have been working on a JISC-funded project to explore how the IMS Enterprise and IMS Enterprise Services specifications can be used to integrate our enterprise database with the Moodle LMS. We have called our project Minted - Moodle Integration with Enterprise Data.
PJN Notes
Basically, this project consists of a couple of components.
1) Bridge - This is an object which talks webservices out of one end, and makes use of the 'Data Access Layer' to talk database out of the other end. So In other words, if I issue commands to the webservice, it will do some stuff in the database.
2) Client - This is the other end; a java application which presents some of the methods in the 'Data Access Layer' and then turns them into webserrvice calls out of the other end.
3) Moodle plugin - This is, in effect, another client. It does some processing of the results. (Source code is available)
In e-fw terms, we've got a service interface, with 2 bindings. The underlying spec is IMS Enterprise. Now it looks like what these guys have done is less then service end, and more the "implement this interface so that the service can use your data" end. I cannot document IMS Enterprise as a service expression.
The DAL isn't really a service. So I can't really document that.
Plan is to write up a SE based on SOAP, and an SE based on REST. I 'think' that the project has done readonly stuff; not sure if they implemented all of the commands in IMS-E. (Certainly for the REST one; SOAP might be more complete).
Have mailed the project for more info.
Useful links
WK notes
You're right that it makes more sense as Manage Group/Person/Membership Service Expressions than a SUM. You're also correct in thinking that they've done read only.
I don't quite understand this bit:
"Now it looks like what these guys have done is less then service end, and more the "implement this interface so that the service can use your data" end. I cannot document IMS Enterprise as a service expression.
The DAL isn't really a service. So I can't really document that."
Is there a difference between a "service end" and a "'implement this interface so that the service can use your data' end"?
Is the reason you can't document IMS Enterprise Services as an SE the fact that it is too lax (i.e. always needs profiling)?
What's the DAL?
