Composit Spring Content Services with CMIS about spring-content HOT 7 CLOSED

Hi @mcalster. Thanks for creating issue. I think this is a great use case and interesting discussion.

So, in general, we believe that some sort of federation support is useful/required to help create a single view over multiple Spring Contents and/or multiple legacy ECMSes. We also believe that the Spring Content programming model could be useful for legacy ECMs (although there are some caveats there). We haven't done much, if anything, in either of these areas beyond conversations with Customers. Also if you watch the most recent SpringOne video you'll see we are actually looking for community involvement so your issue is well-timed.

On the CMIS front we also haven't done anything yet either. Whilst it has been on the roadmap for a while - its kinda been in the icebox - we have only ever had one other customer express an interest in it so there really hasn't been a signal that we should built it.

So I can be sure I understand what you are proposing let me paraphrase (and expand) it back to you. It would look like this:

                                                              |-> CMIS -> SC CMIS -> ECM A
                                                              |
Client -> REST -> Spring Content Facade (Custom Store Impl)   |-> CMIS -> SC CMIS -> ECM B
                                                              | 
                                                              |-> CMIS -> SC CMIS -> SC FS 

1. I am assuming that the Spring Content Facade is net-new code in your organization and therefore you want to take advantage of the Spring Content programming model and REST APIs here. Client (Web/Mobile UI) will talk Spring Data/Content REST here
2. The Spring Content Facade has a custom store implementation that aggregates mulitple ECMs together
3. Custom store implementation will talk CMIS to the real backends
4. Each backend either already implements CMIS or has a Spring Content CMIS Proxy in front of it. If it is the case that the ECM backends dont support CMIS (is this really the case for you) the Spring Content CMIS Proxies will also have custom store implementations that can talk to the real backend; Documentum, Alfresco, Opentext, Filenet, etc

Does that look right? If not, let's clarify and then we can go from there.

from spring-content.

Hi Paul,
That seems just about right. I'm expecting Facade to use an Elastic Search based repository for storing the metadata. This would give a quick way to search across all the repositories.

The only thing that attracts me to CMIS is that it is a proven model, which seems better than any attempt at a common data model that I could throw together.
I'm hoping for something along the lines of this: http://docs.alfresco.com/6.0/pra/1/concepts/cmis-basics.html
The good thing about a common data model, would be that it will allow us to exchange the backends with pure SC services, and still be confident that the model still holds.

That said, I would expect it to be possible to build CMIS'ish data model, with just the stuff we need.
Top of mind items: Repository, folder, query, versioning.

In CMIS terms, I would like the Facade service to be able to list all repositories (ECM's and SC services) that it knows of. And then keep the repository at the top of all following interactions.

That said, CMIS might be over shooting the target a bit.

We are not looking at using some sort of default integrations between ECM that require a CMIS compliant interface, so it is primarily to avoid "reinventing the wheel".

from spring-content.

When I was looking at this previosuly I was looking at this project. From a Spring Content perspective, Spring Content CMIS (JSON) would replace Spring Content REST, providing a CMIS JSON-based REST API instead of the usual Spring Content REST API. I think we would try to create a bridge layer between Apache CMIS Server and the Spring Content object model through additional annotations that we would create like @CmisDocument, @CmisFolder, etc. The CMIS operations would operate on the appropriate object through the relevant Spring Data Repository or Spring Content Store.

One more question. The facade layer is your "index". I think you mentioned that in your org it is ok for all access to go through this new facade. Fine. But what about indexing the existing content in the existing ECM platforms? Not really a Spring Content concern, but I can think of other solution architectures that may be more appropriate if you cant force you users through the new facade (doesnt sound like it here) or if you need to index existing content.

from spring-content.

Hi Paul,

Thanks for spending time on this.

I've looked a bit at the Apache project, but it seems quite big and feature rich, which was why I found this project to be more interesting :-)
But I guess the CMIS part could be leveraged.

I'm not sure what you mean by "not a spring-content concern". Do you mean the external ECM indexing part? Or the facade all together?
Currently we expect to have daily exports from the ECM imported into the index, to handle the few documents not passing the facade.

I'm open to suggestions if you have a better solution architecture? 🙂

from spring-content.

Hi @mcalster, I've started working on the spring-content-cmis library this week. So far I have been able to pretty easily re-use the apache chemistry servlet that provides the json bindings and able to use their test workbench client to make calls through into what will be the Spring Content bridge/integration.

I think it makes sense to try and use new annotations (@CmisRepository, @CmisFolder, @CmisDocument) on either the repository/store interfaces or on the entities or both but it would be quite useful to understand, or get a sense of, your object model for the new Spring Content FS service that we talked about above and that you want to export as CMIS bindings.

Thanks in advance

from spring-content.

Hi @mcalster ,

I just wanted to let you know that v0.8.0 has added (alpha) support for CMIS through the new module Spring Content CMIS. This will allow you to annotate your Spring Content domain models with CMIS-related annotations and export then using the browser bindings.

You can find the documentation for this feature here.

from spring-content.

Closing due to inactivity. Give me a shout if you try the new CMIS support and need a hand with it.

from spring-content.