These sorts of decisions are being faced by many of our customers as well.
In this case I think I would lean towards #1, since it seems you would be
writing code that would be re-useable in other situations as well. e.g.
The two new server implementations you would build could likely be used for
other purposes and an openCMIS server for a ECM provider that does not
currently support CMIS, would likely come in handy later if you will
continue to use that system in production. Not to mention all of the other
customers that use that system. (if you were to post your implementation on
github this may encourage the vendor to step up)
In the case of the federating bridge. If you did produce a CMIS Bridge
based server that would dynamically (based on a list of CMIS server service
URLs in a config file) federate CMIS 1.0 and 1.1 services. This would be
something that would be a welcome contribution back to Apache Chemistry.
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|"BUTTERWORTH, Casey" <casey.butterwo...@suncorp.com.au>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|"'dev@chemistry.apache.org'" <dev@chemistry.apache.org>,
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|07/01/2014 07:01 PM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|OpenCMIS Server or Bridge or Both
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Hi all,
Looking for some architecture guidance based on what people have found to
work best in their environments / what the community considers best
practice.
(Hypothetical) situation:
---------------------------
* The ECM ecosystem consists of multiple ECM providers:
(a) A well known ECM product with CMIS v1.0 support
(b) A lesser known ECM product without CMIS support (but heavily
integrated into other off-the-shelf core business applications via
proprietary APIs)
(c) A bespoke Amazon S3 centric solution without CMIS support (but the
applications owners are trying to determine whether to add CMIS 1.1 support
to this)
(d) An external SaaS ECM provider with CMIS v1.1 support
(also use Sharepoint for general team sites and project collateral, but
do not consider this part of ECM)
* Across these providers, there are different numbers of repositories and
degrees of utilisation:
- Well known ECM vendor with CMIS = 16 repositories; 15 million content
objects
- Well known ECM vendor without CMIS = 3 (big) repositories; 1.5
million content objects
- S3 centric solution = 32 repositories; 320 million content objects
- External SaaS provider = 7 repositories but ever growing; 400,000
content objects
* Our architectural objective is to have a single CMIS endpoint to provide
a federated view across all of these, so that we can provide (amongst other
things):
- A single point of truth for our "list of ECM repositories" - i.e. we
want the "getRepositories" CMIS service to return all ~58+ repositories
across all providers, and interact with any of these, through the same API.
- A single integration point for our image capture and doc gen systems
to store the content they create
- A single integration point for all content centric applications to use
to interact with ECM
- A single viewer to roll out across our internal user community,
hopefully using an existing CMIS viewer
- A single mobile client for staff to interact with ECM (lets assume via
VPN into internal network... but keen to hear other approaches) hopefully
using an existing CMIS mobile viewer
- A single external portal implementation to expose content from ECM
- A generic file system syncing component to interact with all ECM
repositories that can be rolled out to all of our staff (hopefully using an
existing CMIS file sync tool)
- A generic sharepoint web part for surfacing content from ECM
repositories as required in team sites (hopefully using an existing CMIS
webpart)
- A mechanism to isolate systems and users from any details of
independent providers, to allow for subsequent consolidation behind the API
(please feel free to add your own uses cases to the conversation as
well)
My Question:
-----------------
Would you recommend:
(1) separate OpenCMIS Server implementations in front of the 2 non-CMIS
providers, and then a single OpenCMIS Bridge implementation in front of all
4?
(2) implementing a single OpenCMIS server to act as a bridge to all 4
(and not use the OpenCMIS bridge whatsoever)?
(3) implementing a single OpenCMIS bridge to act as a bridge all 4 (and
not build any custom OpenCMIS servers whatsoever)?
(4) something else entirely?
Other Conversation Points:
---------------------------------
* Any thoughts on using something like as part of this (
http://www.mulesoft.com/cloud-connectors/cmis-integration-connector)
Look forward to the discussion!
________________________________
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of
its related entities "Suncorp".
Suncorp may be contacted at Level 28, 266 George Street, Brisbane or on 13
11 55 or at suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and
does not necessarily reflect the view of Suncorp. The content, including
attachments, is a confidential communication between Suncorp and the
intended recipient. If you are not the intended recipient, any use,
interference with, disclosure or copying of this e-mail, including
attachments, is unauthorised and expressly prohibited. If you have received
this e-mail in error please contact the sender immediately and delete the
e-mail and any attachments from your system.
