| [corona-dev] More on... Corona Collaboration Context to JCR Mapping |
|
Should we just expose the JCR Session interface and
the Workspace interface using the Corona SOA support as web services? It is true that JCR api is similar to our
repository interface but I would not go into direct exposing subset of JCR
interfaces instead of corona-specific repository interfaces. Why would we want some façade? 1. Let’s say we expose JCR methods like getItem or getNodeByUUID
instead of our specific resource getters. In such case some client will receive
instance of javax.jcr.Item or javax.jcr.Node – not too convenient. Client
would have to take the effort needed to recognize what type of node he received
(node.isNodeType), what properties such node has (node.hasProperty) etc. ***We have this issue today with
Repository Interface the only thing you know is you get an Object. The nice
addition that JCR provides is a Type definition for the object. In addition you
can get a list of registered type from the JCR. 2. In some cases it would be better to expose some “more
corse-grained” services e.g. openRepositoryWorkspace that will cover set
of steps needed (e.g. if workspace doesn’t exist, create new one,
establish new session, create initial node set etc.). ***I agree with this and today we have put
this type of “course-grained” api into the proxy which I think is
where will continue to put it. However, I think we may need to add the concept
of a RepositoryManager and RepositoryManagerProxy. At least for something like
exposing an XML file as a repository 3. We should have some mapping layer between JCR nodes and our
specific object (Sandro mentioned that in his email). In our initial
corona-jackrabbit approach I created some DTOs like document, directory but it
would be better to use more generic mapping framework. Such specific object
should be exposed externally instead of jcr nodes. *** Do you think it would be possible to
extend the Eclipse Adaptible approach to JCR container objects? |