A few months ago we created a proof of concept to access the Magnolia JCR container using Webservices so that a PHP based site we were building could access new items within an Enterprise Class CMS.  It turned out to be remarkably easy:

To integrate Axis 1.4 into Magnolia:

1. Download the Axis distribution
2. Copy the jars into the magnoliaAuthor and magnoliaPublic WEB-INF/lib directories
3. Copy the servlet declarations from the axis web.xml into the magnolia web.xml in both auth and pub
4. Open AdminCentral and browse to Configuration
5. Open server/filters/servlets and copy log4j node, rename to AxisServlet
6. Open AxisServlet/mappings/–magnolia-pages–/patten and change to /services/*
7. Change AxisServlet/servletClass to org.apache.axis.transport.http.AxisServlet
8. Change AxisServlet/servletName to AxisServet (to match the web.xml servletname)

If you now deploy a class through jws or wsdl methods (by coping the classes, wsdl and .wsdd files) into Magnolia you will be able to access it through <host>/<maginstance>/services/ServiceName?wsdl

You might want to bypass Magnolia security during development, to do that:

1. Open AdminCentral and browse to Configuration
2. Open server/filters/uriSecurity/bypasses
3. Create a new content node “services”
4. Create 2 new data nodes; “services/class” with data info.magnolia.voting.voters.URIStartsWithVoter and “services/pattern” with data /services

For our demo, we simply queried the API for a “text” content node based on a path that was passed into the method:

public String getContent (String name) throws Exception {
String returnContent = new String();
returnContent="";
try {
//get the current context
Context context = MgnlContext.getSystemContext();
//get a hierarchy manager and lookup the content node
HierarchyManager mgr = context.getHierarchyManager(ContentRepository.WEBSITE);
Content uriContent = mgr.getContent(name);
if(uriContent==null){
//oops
returnContent+=" content is null";
} else {
//get the data collection and return the text node
for(Iterator i = uriContent.getNodeDataCollection().iterator(); i.hasNext();) {
NodeData nodeData = (NodeData) i.next();
String nodeName = nodeData.getName();
if (nodeName.equals("text")) {
returnContent=nodeData.getString();
}
}
}
} catch (RepositoryException e) {
throw new Exception(e.getMessage());
}
return returnContent;
}

Axis presents this with the following WSDL:

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://test.sceneric.com" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://test.sceneric.com" xmlns:intf="http://test.sceneric.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.4
Built on Apr 22, 2006 (06:55:48 PDT)-->
 <wsdl:types>
  <schema elementFormDefault="qualified" targetNamespace="http://test.sceneric.com" xmlns="http://www.w3.org/2001/XMLSchema">
   <element name="getContent">
    <complexType>
     <sequence>
      <element name="name" type="xsd:string"/>
     </sequence>

    </complexType>
   </element>
   <element name="getContentResponse">
    <complexType>
     <sequence>
      <element name="getContentReturn" type="xsd:string"/>
     </sequence>
    </complexType>
   </element>

  </schema>
 </wsdl:types>

   <wsdl:message name="getContentResponse">

      <wsdl:part element="impl:getContentResponse" name="parameters"/>

   </wsdl:message>

   <wsdl:message name="getContentRequest">

      <wsdl:part element="impl:getContent" name="parameters"/>

   </wsdl:message>

   <wsdl:portType name="TestWebService">

      <wsdl:operation name="getContent">

         <wsdl:input message="impl:getContentRequest" name="getContentRequest"/>

         <wsdl:output message="impl:getContentResponse" name="getContentResponse"/>

      </wsdl:operation>

   </wsdl:portType>

   <wsdl:binding name="TestWebServiceSoapBinding" type="impl:TestWebService">

      <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

      <wsdl:operation name="getContent">

         <wsdlsoap:operation soapAction=""/>

         <wsdl:input name="getContentRequest">

            <wsdlsoap:body use="literal"/>

         </wsdl:input>

         <wsdl:output name="getContentResponse">

            <wsdlsoap:body use="literal"/>

         </wsdl:output>

      </wsdl:operation>

   </wsdl:binding>

   <wsdl:service name="TestWebServiceService">

      <wsdl:port binding="impl:TestWebServiceSoapBinding" name="TestWebService">

         <wsdlsoap:address location="http://localhost:8800/magnoliaAuthor/services/TestWebService"/>

      </wsdl:port>

   </wsdl:service>

</wsdl:definitions>

and an example of this in action is:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope>
−
<soapenv:Body>
−
<getContentResponse>
−
<ns1:getContentReturn>
<p>yadda yadda yadda</p>
</ns1:getContentReturn>
</getContentResponse>
</soapenv:Body>
</soapenv:Envelope>

Of course, a twist to this approach would be to wrap the JSP rendering with Axis to take advantage of the tag libraries. We tested this with PHP 5’s SOAP Client and successfully read data from Magnolia.  In a production environment we would obviously use XPath or the Query Builder in order to search the repository, and return more complex results.

You can see a video demonstration of this here: http://www.sceneric.com/index.php?page=magnolia-web-services

As a Java teccy who has spent a significant proportion of the last few years designing, building, specifying, analysing and frequently criticising CMS solutions it was pleasing to watch the development of the Java Content Repository (JSR 170 and JSR 283) Specification – It felt as though it was a significant step towards standardising what up until now (and remains so) a fractured and frustratingly immature technology sector.

I’ve just finished working with a government department that was looking to further utilise the large volume of content (running to millions of items) stored in their internal web based knowledge system (essentially a glorified web CMS). However, this department was hamstrung by the fact that the repository was built on a well known, Java based, proprietary CMS solution with a nearly non-existent API, meaning that we either exposed the information via the CMS’ own portal product (a non-starter, bearing in mind we were trying to move away from the proprietary nature of the system) or, as happened implement our own interface…

…Which is how we get to CMIS, which simply put is a specification to define a set of protocols allowing CRUD like operations in order to interact with a Content Repository via web services – This has the potential to make Systems Integrators lives easier, and therefore offer better value to customers.
CMIS could be seen as moving the ideas of JCR further along – Indeed, the groups looking to make this happen are the same as those who worked towards the JCR specs. However, on this occasion, Microsoft are also along for the ride.

EMC have already released a version of their flagship Documentum product that complies with the CMIS standards and others are already looking to do the same.

CMIS is by no means an accepted standard, however it potentially promises solve a number of core business requirements (seamlessly linking apps. to multiple repositories, enabling the decoupling of management apps from the content repository etc.) However, it still has a long way to go, but we will be watching closely to see how it develops.

Some things in life are just the “right” thing to do.  Take implementing a content managed website.  In the early days of content management systems (CMS), there was often no division of content from presentation.  This meant that changing branding & look and feel or re-using content across trading divisions was difficult and costly.  Also, the content was only available as HTML, there was no ability to make the content available through any other mechanism without considerable extra work.

However, even these systems could be implemented correctly, separating content from presentation and utilising content tagging to allow web experiences to be personalised.  Sceneric has built a number of award winning websites forcing this separation and providing the content as discrete, tagged items of information.  This very much the building blocks of the semantic web and can be demonstrated by Friends Provident’s news items being made available as an RSS feed with only 1 hours development, the first FTSE100 company to offer this service. Sceneric have published these guidelines as best practice which can be downloaded here.

This approach has been formalised by all modern CMS projects, in the JSR170 Java standard as used by Magnolia, LiveRay, Alfresco and Oracle CMS, and in the templated approach of Joomla, Drupal, CMS Made Simple in the PHP and Python arena.  In fact, Microsoft’s Sharepoint is also an excellent implementation of this idea.

The key point is that project implementation can be just as rapid and cost the same to produce a platform that seperates content and presentation as to rush something into production that will cost orders of magnitude more to fix in future.