I'm currently working on various Open University (UK) Virtual Learning Environment (VLE) projects; principally developing an e-Portfolio system and a Content/Document Management system (CMS/DMS) (that will be the base technology from which our e-Portfolio system will depend upon). Both components will be built as pluggable components into Moodle.
The Open University development will provide a generic "Repository System" that will offer both CMS and DMS functionality.
We would like to offer this solution as the potential answer to the "Repository API" itemised in the Moodle development roadmap for Moodle Version 1.7.
I've followed the discussion in this forum (especially the disucssion on the DMS development) and also in the "CMS extensions and integrations" forum (http://moodle.org/mod/forum/view.php?f=811).
I think what I'm propsing is not too far from people's thinking to date... but if I'm wrong, I'm certain you will all tell me. Also there will be probably be debate about harmonising this proposal with past and current development.
Anyhow, the remaining post will present a rough sketch of what the Open University is proposing and I welcome your feedback and analysis of the proposal.
Repository System Proposal
--------------------------
1.0 Our Objectives:
---------------
a) to provide a "Repository Component" that can be plugged into Moodle for usage by Moodle core code or Moodle modules;
b) the "Repository Component" will offer support for CMS and DMS requirements;
c) the "Repository Component" will be provided as optional functionality; i.e. developers can choose to use it or not; i.e. we're agnostic as to whether the component is a Moodle core library;
d) the "Repository Component" will leverage international trends in the specification and standardisation of ECM/CMS/DMS solutions (ECM=Enterprise Content Management);
e) the "Repository Component" will offer an abstract interface that allows Moodle developers who uses it to connect with any number of ECM/CMS/DMS implementation (open source or commercial solutions) without knowing anything about those implementations; if that was desired;
Hopefully it's self-evident that our objectives is to provide a "strategic repository" component that will allow the Open University to connect to any number of CMS/DMS whether Open Source or commercial.
2.0 Some definitions:
-----------------
DMS: the Open University considers a DMS as a system that offers features and functions to manage documents; features include metadata support, version control, auditing, content hierachy organisation, content manipulation (edit, copy, move, etc.), etc...
CMS: the Open University considers a CMS as a system that offers features and functions to manage content; features include metadata support, version control, auditing, content hierachy organisation, content manipulation (edit, copy, move, etc.), etc...
When one manipulates documents (Word, text, spreadsheets, etc) as the lowest "content object", they are working with a DMS system.
When one is interested in manipulating the structure within documents (e.g. read templates styles in MS Word, read the XML structure within an XML document, etc.), they are working with a CMS system that offers features and fucntions to navigate from a document into the structure of a document. Note: you can imagine XML plays a big part in the CMS world.
A Web CMS is a specialised application of a CMS for web site management.
An Enterprise Content Management (ECM) system is a glorfied umbrella name that includes CMS, DMS, Workflow systems, Web CMS, Portal technology, etc. So for this proposal, I restrict the discussion to CMS and DMS.
3.0 The Proposed Solution
---------------------
The Open University is developing a "Repository Component" that is principally a CMS system that can be used as if it was a DMS system.
The "Repository Component" has three parts:
1) A Repository Object Data Model;
2) A Repository API for processing the Repository Data Model;
3) A Development Framework that describes how one can develop plug-in CMS/DMS implementations that can be accessed seamlessly through the "Repository COmponent";
4.0 Solution Implementation
-----------------------
The Open University is proposing the adoption of the JSR-170 specification (http://www.jcp.org/en/jsr/detail?id=170) for both the Repository Object Data Model and API.
Note: I won't delve into the details of the specification in this posting but will point readers to download the PDF specification and read sectin 4 and 5 only. I'm happy to explain the spec if people are interestd in another posting.
JSR-170 offers a powerful data model that provides a seamless bridging between CMS and DMS and has a comprehensive set of API interfaces for manipulating the data model.
The specification was created by a consortium of people of who have developed the major commercial CMS/DMS systems and has great support from the open source community (i.e. Apache with their Jackrabbit implementation).
In taking this approach, the Open University satisfies its objectives B, and D above.
One criticism is that JSR-170 is commonly seen as a Java specification. But with web services technology one can easily abstract the Java interfaces into web services calls to be activated in PHP.
In Considering this criticism, the Open University is proposing to implement a PHP interface equivalent to JSR-170 such that PHP/Moodle developers can make use of JSR-170 without knowing Java. How the PHP JSR-170 will talk to CMS/DMS is upto the implementation of the PHP JSR-170. So one implementation may be purely PHP. Another implementation may communicate with a Java CMS via web services call in PHP with everything mediated by the PHP JSR-170 interface.
The PHP JSR-170 interface approach satisfies the Open University's objective E.
Our choice of actual coding and implementation of this solution will hopefully satisfy the Open University's objective A and C.
In making the "Repository Component" light-weight and completely optional plug-in into Moodle, we hope that this will ease the discussion as to whether this component can be the basis for the Repository API proposed in Moodle version 1.7.
5.0 Architectural View
------------------
The following diagram depicts the architectural view of what is being proposed....
Box 2 is the PHP JSR-170 interface that will offer the Repository Data Mode, API and Development framework that all Moodle core code or Moodule modules will communicate with. This is pure PHP.
Box 2 is only an interface and requires an implementation to connect the interface to an actual CMS/DMS implementation.
Box 3 is the proposal for a "pure" PHP implementation that interprets PHP JSR-170 calls and map them to an implementation of a CMS/DMS that talks to a server file system and database.
Box 4 is the proposal for a JSR-170 implementation that connects an implementation of a JSR-170 Repository to the PHP JSR-170 component (e.g. Apache Jackrabbit, Alfresco CMS, etc.).
Box 5 is the proposal for a OKI Repository (OSID) implementation that connects an implementation of an OKI Repository to the PHP JSR-170 component.
Box 6 is the proposal for a IMS Digitital Respotiory implementation that connects an implementation of an IMS Digitial Repository to the PHP JSR-170 component.
Box 8 suggests that if the CMS/DMS implementation is not PHP, then the means for connecting PHP to anotehr platform technology (e.g. Java) is PHP web services/soap.
The diagram below demonstrates the JSR-170 data model:
Note:
A workspace is equivalent to a drive letter in MS Windoes file management or can be partition into personal workspace, group workspace, enterprise workspace. Anything is possible, the concept is simply that a workspace equals the "Root Node" in a repository node hierarchy.
A Node can be a document or it can be (for example) a root of an XML document. Child elements of an XML documents are child nodes.
Property is the metadata of a "content object" applicable to any content granularity.
6.0 Proof-of-concept
----------------
We have a working proof-of-concept codebase that demonstrates this proposal and the architectural thinking. This prototype connects Moodle/PHP to the Alfresco CMS. I'm happy to share this if people are interested.
The proof-of-concept makes use of a PHP interface translation of JSR-170 called phpCR which can be found at http://www.phpcr.org/.
Taking this PHP JSR-170 interface, the proof-of-concept code has mapped the PHP JSR-170 API calls to those provided by Alfresco web services implementation (http://dev.alfresco.com/downloads/).
The bridging of PHP JSR-170 to Alfresco (which is Java) is through the PECL SOAP module as the base web services communication layer.
I've explored alternative PHP/Java bridging, but I suggest web services is probably the best communication layer.
7.0 Closing notes
-------------
This has been a long posting, but I hope I seeded enough info for people to explore the proposal and to ask me directed questions to focus in more detail about this proposal.
I've been mindful of not overloading the posting with too much detail, so depending on interest, I will be happy to expand on issues.
Thanks,
Thanh Le.