Skip to end of metadata
Go to start of metadata


This page:

Critical Architecture Topics

DMS as a framework

  • DMS "hosts" UI components, both written by us (Java, maybe JSF) and 3rd party (open-source tools that may even be in different languages).
    • So this hosting could be using DMS UI extension mechanisms, but also pure HTML means (eg IFRAMEs, one frame passing data to another... in which case XSRF refusal issues should be considered)
    • This will be the primary topic of the Alfresco and Nuxeo pilots in RS3.1 (see RS Plan 0), and evaluating the ease a primary factor for selecting DMS
  • DMS checks credentials and establishes security tokens (readonly/readwrite and which project) that must be passed to RDF and the Tools.

DMS-RDF integration

Contrary to popular belief , our DMS-RDF integration requirements are not so big, since all metadata is stored in RDF (the reason being that DMS carries only flat metadata):

  • Extract metadata from DMS, save in RDF
  • Extract text from DMS docs, copy & index in RDF

After we select the DMS (based mostly on the ease of using DMS as a framework), we'll design the integration.
We should research the approach and results of IKS and Apache Stanbol: integrating to CMS that have JCR, CMIS, or other API; mapping CMS content models to ontologies; APIs to various services (eg FactStore); passing data (JSON-LD)

Backend-Frontend Communication

How do the backend and frontend communicate? Eg if you need to show a painting and all its details, how will the data be represented? There are various options:

  1. domain object (eg Painting, Painter...) in Java. Pro: concrete easy to grasp implementation. Cons: inflexible, more effort-intensive
  2. CRM conceptual object (eg Physical Man Made Object, "was created by") in Java. Pro: flexible. Cons: complex, hard to grasp; impedance mismatch with RDF (eg there might be multiple "was created by" properties, do we make an array in Java?)
  3. graph (subject/property/object) in Java. Pro: faithful to the RDF store, flexible. Cons: frontend devs must interpret all the data, hard to grasp
  4. RDF store, data is fetched with SPARQL as needed. Pro: easiest for the backend devs . Cons: most work for the frontend devs, involves lots of querying round-trips.

Maybe Exhibit has the right answer: give me JSON, then tell me where to find the fields that interest me. That's a bit like 1 (domain objects), but the objects are not predeclared and are completely dynamic (whatever you put in a JS dictionary)

JSON/RDF format (used by rForms):

Light-weight ESB

This topic should answer these questions:

  • How to integrate
  • How to integrate a Tool into the overall system?

It should define the principles, methods and best practices. It should also document individual tool integrations as they happen.

It may or may not involve a separate software artifact (an actual ESB):

  • I am wary of going deep into SOA and ESBs: my impression from CollectionSpace is that they went too far that way, which produced sub-optimal choices (eg not using Nuxeo in a core way) and results (IMHO sluggish system)
  • we're not building a bank system that moves messages around, but (in one sense) a quilt-work of GUI components


  • we'll follow BM's principle that light-weight HTTP/XML/JSON/REST APIs should be preferred
  • some deeper operations may require integration between Java components
  • some Tools will likely involve integration at the GUI (HTML) level, such as a frame passing data to another
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 30, 2011

    On versioning: I agree with Mitac it is worth to consider keeping it in DMS. By defining a new type of document that would represent a Entity that we keep versions for? A couple of fields may be changes in a single version?