Alex Little

Now that I’ve got most of the webservices etc sorted out for the JoinIn enterprise database, I started to look at creating the standalone interface for doing the grouping. I started off by creating a blanks struts application (on Tomcat 4.1- as I had been using for the JoinIN enterprise database), but soon noticed that I can’t use the filters in the servlet 2.3 spec that I’d have liked to have used for the page layout (header & footer), the reason being that the struts framework uses a forward to map the action in the URL to the actual jsp page. This functionality is only available in servlet spec 2.4, which then also means upgrading to Tomcat 5.5.

So, after a bit of ‘fun’, I’ve got both the JoinIn enterprise database/webservice and the standalone grouping interface now running on tomcat 5.5 on my tablet PC. I now need to make sure that I update the tomcat on our dev server and get both the apps running correctly on that too.

How a datasource is configured in tomcat 5.5 is slightly different to tomcat 4.1 too. Rather than creating a joinindb.xml file in the webapps folder to store the context data, this file must now be within the META-INF directory, called context.xml.

Getting on well with the development of the webservices for the Enterprise databases, and ought to have this about finished later this week. Then next week I can look at seeing how this maps across to the Enterprise SDK – I can use the same database and should to be able to reuse a lot of the code too (esp the parts that make calls to the database to retrieve data).

Another thing we’ve been looking at at is how we’ll do the XML parsing in Moodle using php. Most Moodle installations run on PHP 4 which doesn’t have built in XML functions, whereas PHP 5 does. There are libraries available for PHP 4 to do the XML parsing, but these (I think) would mean rewriting the code if we (and/or Moodle) moved to PHP 5. The alternative (so code didn’t need to be rewritten for different versions of PHP) would be to use regular expressions on the XML string – but that seems like a bit of a kludge to me!

Eventually figured out what the problem was when I was trying to register the service with axis on the Enterprise minimal deployment example. It turned out that I needed to add ‘.’ to the axis class path so that the current directory was also included in the class path. See the full background on the IMS Enterprise SDK SF forums

I also started a new thread on the IMS Enterprise SDK SF forum regarding being able to ‘get at’ the wsdl for the web services generated, as I was getting error messages when I tried to view the wsdl. The solution appears to be to use the es-client.jar for the communication between the client and server. However for our project we can’t the es-client.jar because the client will be Moodle (written in php). So we’ve got a couple of options (unfortunately Scotts option of using the SOAPless approach won’t work as we need read & write access)….

1. Try to figure out how to read the output from the webservice in php – I’m guessing this is what Scott means when he says that we could construct the SOAP + XML messages and deal with them.
2. Create the client in java, then write a wrapper around this to provide a simpler webservice, and we could then let Moodle & LAMS commmunicate with this stripped down version.
3. Create our own basic webservice (which passed out IMS Enterprise XML, rather than using IMS Enterprise Webservices), but this would mean not using the Enterprise SDK at all

My feeling at the moment is that (1) would take up too much time in this short project, and we wouldn’t get chance to do the grouping stuff that we’re meant to be doing! Option 2 would be a good compromise given the time we have, with option 3 as a fallback option so we could actually deliver something that worked, just not exactly in the way we would have liked.

Need to have a bit of a think about all this and the best way to go