Professional Documents
Culture Documents
Moodle Web Services
Moodle Web Services
System Architecture
Over the years a number of systems have been adopted to fulfill business needs Integration is either via ODBC, CSV Extract, LDAP ..etc Some systems do not integrate and manual process is required to import/export
System Problems
Complex communication networks Duplication of information which is at varying levels of validity Duplication of functionality (e.g. LDAP Authentication) Maintenance and change management problems
User Problems
From a users point of view Inconsistent interfaces Multiple passwords required Not a seamless environment No one stop shop for information Scalability hindered
Answer
Web Services and the ESB (more on this later)
AV System Analogy
(non-service oriented architecture)
Proprietary connections (similar to ODBC types) Lack of universal standards means addition of new functionality is difficult Purchasing a new items requires that it is compatible with the proprietary connections limiting you to one brand
? ?
AV System Analogy
(service oriented architecture)
Universal RCA connection Addition of new functionality easy due to adherence to standards Purchasing a new items just requires that it is RCA compatible
RCA
RCA
Development
XSD Schema
WSDL is King
time spent here will save time in the future The WSDL and schema is the most import part of the structure Aids in compatibility Documents functions, purpose Outlines structure of request and response error Can be used by developmental Web Service abstractions to self write most of the code (VB script Web Services toolkit 2.0)
XSD Schema
http://pear.php.net/package/SOAP
http://sourceforge.net/projects/nusoap/
Implementation
In moodle
Initial Problems
Lack of crucial classes in Moodle User, Course etc And their associated functions e.g. getMyCourses(); etc Some functions areas are tightly coupled with the interface $USER is only an object
$USER $CFG
Solution
Creation of entity classes for User, Course, Quiz, Assignment Creation of Moodle-API-S service Creation of moodletypes.xsd mirror object properties Creation of Moodle-APIS.wsdl to describe service
The Future
Fedora has no interface All interaction with the Core is via web services The application is just a collection of web services Architecture finally allows for design patterns to be followed (e.g. Bridge, Faade) Interfaces decoupled from core API
ESB
The Enterprise Service Bus A Web Service of Web Services Forms a backbone within the institution Provides routing promoting efficient usage and allowing for redundancy Change management applied from one place flows through to all attached
ESB Controller
Fedora
HR
Moodle
Moodle
Conclusion
Web Services enable this by allowing developers to use other systems Business Logic thereby reducing the replication of their functionality poorly in your application Enables stepwise refinement of components outside of the main system split authentication module out of core Shortens product development leverages off previously developed APIs Concentrates development on what is new not doing what I have already done . Again!
Some Examples
Further Reading
Programming Web Services with Perl (OReilly)
Although not about PHP it does have a great section on WSDL and Perl is a great language anyway to learn