Skip to end of metadata
Go to start of metadata

The Services Team Home

Nuxeo EP exposes three kinds of APIs according to "Using Nuxeo APIs". These are:

  1. REST APIs - In Nuxeo 5.2 M4 these APIs are implemented using Restlets. There is also a RestPack that provides additional APIs for vocabulary, query model, syndication, workflow task, etc.
    1. We could use these APIs from CollectionSpace service war files. However, this could be a less efficient approach considering HTTP/XML communication/marshalling overhead within the same JVM.
    2. One of the advantages of RESTful APIs is that the context has to be supplied with each request, i.e. RESTful services are not conversational. This might also make it difficult to use these APIs in cases where browse or drill-down (of repository) scenarios are involved.
    3. Nuxeo RESTful APIs is a work in progress. In 5.2 M4, there are REST APIs and REST pack extensions to access platform APIs. However, these offer limited functionality for some crucial operations such as Read and Query.
    4. URI: Nuxeo generates UUID for each artifact (domain, workspace, note, schematype, etc.) stored in its repository. One can easily retreive the artifact by providing the name of the repository and the artifact id ({repo}/{id}, e.g. /nh/1231). This is good for various reasons, most importantly, it offers permalink and short URIs. However, it lacks hierarchical information available from URI Path indicating where the document resides (e.g. /nh/bnhm/collectionobject/1231).
  2. Web Service APIs - These are SOAP-based Web Services providing functionality such as browsing of repository, getting document meta-data, etc.
  3. Java APIs - Although, there seems to be no distinct documentation (including Javadoc) describing the APIs, there are two kinds of Java APIs. Nuxeo Java API's

    ERROR

    Gliffy is unlicensed. Please install a license to draw diagrams in your wiki.

    1. Local - Local APIs are using from components that are deployed under the umbrella of nuxeo.ear. There are two issues:
      1. For CollectionSpace to use this approach, it would mean CS is extending Nuxeo instead of using it. This means that CS services operate within the Nuxeo environment (security, deployment, configuration, management, etc.) instead of the other way around.
      2. Nuxeo Local APIs seem to be more of Nuxeo "private" APIs instead of public APIs. Applications built using these APIs could be more prone failure due to (frequent) changes made by the Nuxeo developers. To access these APIs, application has to inherit the same class loader hierarchy that nuxeo.ear uses.
      3. Other implication is that namespace might not be appropriate. For example, if CS services are deployed as Nuxeo Restlets, the path to URI would contain "nuxeo" keyword. This is not desirable as CS service consumers would be exposed to implementation details of the service infrastructure.
      4. During the development and testing phase, building and deploying whole Nuxeo ear (or CS-customized Nuxeo), will slow down the cycle considerably. We are not confident that hot-deployment (without restart of the server) works fine for Nuxeo especially when document types are added or modified. On a quad-core machine with >3G memory, it takes approximately 8-9 minutes to start the server with Nuxeo.
    2. Remote - These are EJB3 interfaces published in JNDI to be accessed from a client. This would be ideal APIs to interface with Nuxeo from the CollectionSpace stand point. However, there are some problems.
      1. According to our investigation, it appears that the Remote Java APIs are packaged with assumption that these would be consumed by a client running in a separate JVM, e.g. OSGI runtime of Eclipse. In other words, we find that these APIs are not packaged such that a client running in the same JVM where Nuxeo is also deployed could access these APIs from JNDI.
        1. If we package the nuxeo-core-apis.jar with the client (in war),  ClassCastException appears while trying to cast after lookup.
        2. If we put the nuxeo-core-apis.jar in the system classpath assuming both the client and server could use the same class instances of API, Nuxeo fails to deploy.
      2. One drawback would be that XML would be un/marshalled over RMI/IIOP even within the same JVM. However, this is no different than paying the cost of XML un/marshalling over HTTP within the same JVM.
Icon

We have asked the Nuxeo team to share with us a working example of using Java Remote APIs from a war that is deployed in the same JVM as nuxeo.ear.
.
Here is a link to a discussion about the Pro's and Con's of our CS-to-Nuxeo runtime environment options: RTE Options for CollectionSpace Services to Nuxeo API

Recently Updated