Hi, I don't want to spark any grand debate here but I feel it necessary to rebut Patrick's comments – “at SUNY we found that Moodle was not designed with service integration and interoperability in mind, and the Moodle community was not interested in undertaking the development to make SOA possible”. That is quite an extraordinary statement on two front 1) given Moodle's architecture which is fundamentally about application programming interfaces, and 2) the value judgement on what is a huge and diverse community of users. Firstly the architecture. The M in Moodle stands for Modular. It was most certainly built with interoperability in mind and it was this criteria that helped win the day back in 2004 when we selected it. Follow the link if you want to read our architecture assessment at the time (although being May 2004 it needs updating!) https://eduforge.org/docman/view.php/7/18/LMS%20Technical%20Evaluation%20-%20May04.pdf
Since then we've done many integrations both at the application level and with dataflows, including many beastly student management systems. We've used a variety of web services with Moodle, just recently SRU/SRW creating an interface with the Fedora institutional repository system. Interoperability, open standards and web services is also explict with Moodle's roadmap.
So I struggle to understand how your evaluation cam to these conclusions? I'm also a little curious how a SOA architecture sits with the selection of proprietary Angel?
regards, Richard Wyles
- 925 reads
