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

One of the things that is a constant surprise is finding clients with slow Java systems that spend a tonne of cash on new hardware but don’t configure their systems to make full use of it.  A classic problem is leaving the application server settings as per first install, with very low JVM heap size and a poor garbage collector, another problem being running only one instance of a JVM, a situation where you may have a new server with 4GB of RAM and a quad-core CPU but running the software in only 512MB RAM with threading likely to be tied to a single core.

Sceneric consultants are experts at optimising our clients platforms to ensure the hardware is properly utilised.  Our consultants have deployed applications on clustered IBM Websphere, Weblogic, Oracle iAS and JBoss servers, and have created Coldfusion Enterprise clusters on JRun 4.0 leading to significant performance and stability gains.

The key thing to remember is that Java runs within a virtual machine which has limits ordinarily significantly smaller than the avialable hardware.   Without explicit tuning expertise applied, the applications running within the virutal machine will not be performing to their optimum potential.