Composit Spring Content Services with CMIS

[mcalster]

Hi Paul,

First of all, GREAT project!

I work in an enterprise with multiple ECM's and one of them is scheduled to be EOL'ed, and therefore a candidate to be replaced by a Spring Content alternative. I'm pretty sure that this can be done with the current feature set, and the release of the upcoming "Versioning" support.

I still see mentions of CMIS in the docs, can you say anything about how far away the support/implementation of this standard is?
The reason that I'm asking, is that we would like to expose all our ECM's as one, and be able to search across them via Elastic Search(ES).

So basically, I thinking two layer setup:
1 FRONT END:
A ECM Facade Service based on Spring Content, Writes metadata to ES, Stores Content to multiple ECM backends. (Spring Content CMIS)
2 BACK END:
Pure ECM backend A (soap services, CMIS) Fronted by Spring Content "proxy service"(Spring Content CMIS)
Pure ECM backend B (stored procedures) Fronted by Spring Content "proxy service" (Spring Content CMIS)
Pure Spring Content Service (ES, File system or RDB) (Spring Content CMIS)

So the facade would be the single entry point for all queries, and the "only" one to call the backend ECM services.

Do you see anything alarming in this setup? We should have have a common interface between the Facade and the backends (both proxies and Spring Content services) - here I'm thinking "Spring Content CMIS" could play a role?
Also the repository abstraction in CMIS could play well in terms of controlling which backend actually stores the content data.

That said I'm pretty new to CMIS so any thoughts you have are welcome.

[paulcwarren]

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.

[mcalster]

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".

[paulcwarren]

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.

[mcalster]

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? 🙂

[paulcwarren]

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

[paulcwarren]

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.

[paulcwarren]

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