chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <f...@apache.org>
Subject RE: OpenCMIS Server or Bridge or Both
Date Fri, 04 Jul 2014 11:04:04 GMT
Hi,

Consider the OpenCMIS Bridge a framework with a default implementation. The
default implementation forwards requests to one backend system. That is, it
doesn't do federation out-of-box, but adding federation is fairly simple.
You somehow have to map the repository IDs to backend systems. Because that is
really specific to the use case, the backend systems, and the way how this
configuration is stored and managed, this is not part of the default
implementation.
Additionally, you also want to some optimizations here. For example, caching the
repository infos of the backend systems is a good idea. When a client calls
getRepositories, you don't want to contact all 58 backend systems every single
time before you return the list of repositories. So, you need some sort of
persistence here.

The bridge framework itself is build on top of the OpenCMIS server framework.
You can mix the bridge functionality with CMIS server implementations within the
same webapp, if you want. The key is the service factory, which has to direct
requests to the right CmisService implementation. So, even if you build
independent OpenCMIS servers first, you can later deploy them together with the
bridge on the same server in the same webapp. All your options are not that far
apart.

Your scenario certainly needs some extra bridge coding. But that is doable. We
are running a scenario comparable to your option #1 with a customized bridge and
it's working pretty well.

There is certainly code that we could contributed back to OpenCMIS, which would
make scenarios like this easier to implement. But cleaning the code up and
removing all our specific code takes time and effort and is not our highest
priority at the moment.

- Florian

> 
> Re the federating bridge…
> 
> I have not had the need to use the CMIS Bridge code yet, but I was under
> the impression that it allows for bridging one CMIS server at a time.
> That may be an incorrect assumption, and if it is, someone else on this
> mailing list will certainly jump in an correct me. :)
> 
> 
> Jay Brown
> Senior Engineer, ECM Development
> IBM Software Group
> jay.brown@us.ibm.com
> www.linkedin.com/in/parityerror/
> 
> 
> |------------>
> | From:      |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |"BUTTERWORTH, Casey" <Casey.BUTTERWORTH@suncorp.com.au>
>                                                                                     
     |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | To:        |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |"'dev@chemistry.apache.org'" <dev@chemistry.apache.org>,
>                                                                                     
    |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Date:      |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |07/02/2014 06:17 PM
>                                                                                     
                                         |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Subject:   |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |RE: OpenCMIS Server or Bridge or Both
>                                                                                     
                       |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> 
> 
> 
> 
> 
> Thanks for the response Jay
> 
> I was leaning towards #1 as well, as it makes each of those independent
> products more internally complete (i.e. CMIS compatible) rather than
> cobbling them all together at the single integration layer.
> 
> Of course, this approach would create additional layers (potential points
> of failure, more infrastructure, possible performance impacts, etc) so it’s
> not a decision I’d make lightly. In general my preference would be for the
> product specific CMIS layer to run “in process” within the product for
> these reasons. That being said, it’s not uncommon to add mediation layers,
> so we’d just need to work through this (I’m thinking CMIS on an API gateway
> rather than a separate java application layer, might be more palatable in
> the longer term - if we do any work here I’ll contribute it back).
> 
> Re the federating bridge… I had assumed that the OpenCMIS bridge already
> does this? i.e. I thought that was the point of using the bridge :) Have to
> admit I haven’t looked in any detail yet. We would absolutely look to
> contribute back any enhancements we make.
> 
> Thanks! Hope the ideas keep flowing!
> 
> - Casey
> 
> From: Jay Brown [mailto:jay.brown@us.ibm.com]
> Sent: Thursday, 3 July 2014 3:17 AM
> Cc: 'dev@chemistry.apache.org'
> Subject: Re: OpenCMIS Server or Bridge or Both
> 
> 
> 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.
> 
> 
> 
> [Inactive hide details for "BUTTERWORTH, Casey" ---07/01/2014 07:01:55
> PM---Hi all, Looking for some architecture guidance based]"BUTTERWORTH,
> Casey" ---07/01/2014 07:01:55 PM---Hi all, Looking for some architecture
> guidance based on what people have found to work best in their
> 
> From:
> 
> 
> "BUTTERWORTH, Casey" <Casey.BUTTERWORTH@suncorp.com.au<
> mailto:Casey.BUTTERWORTH@suncorp.com.au>>
> 
> 
> To:
> 
> 
> "'dev@chemistry.apache.org'" <dev@chemistry.apache.org<
> mailto: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.
> 
> 
> 
> ________________________________
> 
> 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.
> 
>

Mime
View raw message