Alex Little

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