Alex Little

Here are some diagrams of how we currently have things set up, and where we might go…

Current set up:

This is how we currently have things working, unfortunately it’s not using IMS Enterprise Services in the communication between modules, it is just returning strings which are IMS Enterprise XML

Option 1 (see posting below):

This is how we would ideally have the system set up, with an Enterprise Server in the centre, with a PHP library handling the interaction between Moodle and Enterprise Server.

Option 2 (see posting below):

This is how we’re most likely to end up, with another java application inbetween Enterprise Server and Moodle. This Enterprise Client would be a client to the enterprise server, but it would be a server in Moodles eyes. We’re still undecided yet as to whether this would have a SOAP or REST interface provided out to Moodle.

As I’ve been going through the IMS Enterprise and IMS Enterprise Services spec, I’ve got a number of questions as to how they should be used, or more what they should actually return (this is just a random collection of my queries!)…

1) Should the readPerson method return the persons’ group membership too – or should it only  be the person record?
2) Should the methods which return group memberships return records of people who are implicitly in the group too? By this I mean if there is a parent Group P which contains a child Group C and person A is a directly listed as a member of C (but not of P), if I request all the members of group P, should person A be included? Or should it be up to the requesting system to make iterative calls to get this sort of information?
3) Some of the methods in the Ent Service spec appear to do very similar things, eg the readGroupsForPerson and readMembershipsForPerson both appear to return the same information, admittedly the XML format is different, but essentially the information you are getting from each is the same.
4) It seems a little odd that the formatted name is mandatory, but the component parts of the name are not, I would have thought it ought to be vice versa – as storing and using the component parts of the name is much more common and sensible!
5) There seems to be the potential for the group relationships to get into a loop (I’ve not seem anything yet in the spec that refers to this potential problem), as it seems possible (according to the spec), to have Group A being a member of Group B and GroupB to also be a member of Group A.

The answers to these are probably out there somewhere….!

And some more comments from Juliette regarding the grouping aspects within Moodle….

"Moodle has a concept of courses, members of a course and groups within a course. IMS Enterprise of course just has generic groups. This means that if we get an XML file of IMS Enterprise data we don’t automatically know which groups are courses. If you’re only trying to transfer information about course enrolment then you’ll have your data set up so the groups correspond exactly to courses and you don’t have any other groups, so you can ignore this problem. However as we’re dealing with groups within courses then we might need to worry about this type of thing. We could assume that all top level groups (i.e. groups that aren’t members of other groups) are courses, but I wonder how valid this assumption is with the sources that data is likely to come from.

If we’re only doing stuff through the IMS Enterprise Services API it doesn’t look like we’ll actually need to worry about this at all as we’ll assume that our systems are already synced with the course and enrolment info, but it still bothers me as a potential source of unforeseen problems!   "

Some more comments from Juliette regarding the IMS Enterprise specs…

"The first thing that is a bit confusing about IMS Enterprise is that there are actually two specs – IMS Enterprise (latest: version 1.1) and IMS Enterprise Services (latest: version 1.0). They both deal with the problems of how we communicate information about people, groups, who belongs to which groups and which groups belong to which other groups between systems. The IMS Enterprise spec essentially tells us how to write all this information in an XML document whereas the IMS Enterprise Services gives us a web services API with calls that let us do things like create people and groups, put things inside groups, update and delete things and get information about groups and people given their ids within the system. The two are independent but designed in a fairly compatible way so you could use them both with the same data in a fairly sensible way I think. I did notice a list of differences between the two in the IMS Enterprise Services spec though.

So the IMS Enterprise spec is good if you want to transfer all the information about your system somewhere but is a bit clumsy for making any changes to that data while the IMS Enterprise Services spec is good for manipulating the data but doesn’t give you any way of finding out what is actually out there to manipulate. The specs suggest that IMS Enterprise Services supersede IMS Enterprise, but it looks like in practice you’ll need IMS Enterprise to get both your systems in sync somehow unless there’s some magic solution to this that I haven’t spotted.

I also had a look at Dan Stowell’s IMS Enterprise module for Moodle (look under Dan Stowell’s posts on the moodle.org forums – the latest version seems to be 0.6). It appears to very helpfully take an XML file in IMS Enterprise format and puts that information into the Moodle database in a sensible way. It doesn’t provide any sort of web services client for IMS Enterprise Services, so if we need one it looks like we’ll have to write one ourselves.

I need to look a bit more closely at Scott Wilson’s IMS Enterprise SDK too. At first glance it consists of some libraries and documentation to make it easier to attach an IMS Enterprise Services web service to your software. You still need to write your own backend of to actually do something with the calls rather than return ‘unsupported’. I suspect that what we and the MINTED project need here is probably fairly similar. "

Had almost an all day meeting with Ernie from LAMS today which was very productive, and I now have a much clearer idea as to what we are doing within the scope of this project, especially for the coding that we need to do, the architecture, the APIs etc. I need to get the notes from this meeting written up into a proper document and include the whiteboard diagrams (scrawls?!) we came up with. Once I’ve got this written I’ll post a link up so everyone can have a look.

These are some of the areas we should be able to get started on next week:

• Sorting out which IMS Enterprise Service to use – need to contact Sam Easterby-Smith about this
• Set up a project on Sourceforge to store our code for the Moodle Group Module
• Find out more about how to create modules with Moodle
• Install the LAMS module for Moodle so we can have a play with this
• Define more use cases
• Start thinking about how the user interface for setting up the groups would look
• Contact the MINTED group (another JISC funded project under the demonstrator strand) at Sussex Uni, as they are looking at doing very similar work, and we don’t want to duplicate effort.