Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Received-SPF: pass (athena.apache.org: domain of
 Casey.BUTTERWORTH@suncorp.com.au designates 216.82.254.107 as permitted
 sender)
From: "BUTTERWORTH, Casey" <Casey.BUTTERWORTH@suncorp.com.au>
To: "'dev@chemistry.apache.org'" <dev@chemistry.apache.org>
Subject: RE: OpenCMIS Server or Bridge or Both
Thread-Topic: OpenCMIS Server or Bridge or Both
Thread-Index: Ac+VkoO9fp7MeX+LQnm1TCVm3JtF5wAMxH6AACVfLkA=
Date: Thu, 3 Jul 2014 01:16:28 +0000
Message-ID: 
 <C598586168CD8B45B7F51BD429EC638284176499@PBNEMBMSX4101.int.Corp.sun>
References: 
 <C598586168CD8B45B7F51BD429EC638284176071@PBNEMBMSX4101.int.Corp.sun>
 <OF840B8DEC.32C05E40-ON88257D09.005D5ABB-88257D09.005EEBF1@us.ibm.com>
In-Reply-To: 
 <OF840B8DEC.32C05E40-ON88257D09.005D5ABB-88257D09.005EEBF1@us.ibm.com>
Accept-Language: en-GB, en-AU, en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_C598586168CD8B45B7F51BD429EC638284176499PBNEMBMSX4101in_"
MIME-Version: 1.0

--_000_C598586168CD8B45B7F51BD429EC638284176499PBNEMBMSX4101in_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

Thanks for the response Jay

I was leaning towards #1 as well, as it makes each of those independent pro=
ducts 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 o=
f failure, more infrastructure, possible performance impacts, etc) so it=1B=
$B!G=1B(Bs not a decision I=1B$B!G=1B(Bd make lightly. In general my prefer=
ence would be for the product specific CMIS layer to run =1B$B!H=1B(Bin pro=
cess=1B$B!I=1B(B within the product for these reasons. That being said, it=
=1B$B!G=1B(Bs not uncommon to add mediation layers, so we=1B$B!G=1B(Bd just=
 need to work through this (I=1B$B!G=1B(Bm thinking CMIS on an API gateway =
rather than a separate java application layer, might be more palatable in t=
he longer term - if we do any work here I=1B$B!G=1B(Bll contribute it back)=
.

Re the federating bridge=1B$B!D=1B(B 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=1B$B!G=1B(Bt looked in any detail yet. We would abs=
olutely 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 w=
riting code that would be re-useable in other situations as well.   e.g. Th=
e two new server implementations you would build could likely be used for o=
ther purposes and an openCMIS server for a ECM provider that does not curre=
ntly 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 th=
is may encourage the vendor to step up)

In the case of the federating bridge. If you did produce a CMIS Bridge base=
d server that would dynamically (based on a list of CMIS server service URL=
s in a config file) federate CMIS 1.0 and 1.1 services.  This would be some=
thing 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.BUTTERW=
ORTH@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 w=
ork 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 integra=
ted into other off-the-shelf core business applications via proprietary API=
s)
   (c) A bespoke Amazon S3 centric solution without CMIS support (but the a=
pplications 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 d=
o not consider this part of ECM)

* Across these providers, there are different numbers of repositories and d=
egrees of utilisation:

   - Well known ECM vendor with CMIS =3D 16 repositories; 15 million conten=
t objects
   - Well known ECM vendor without CMIS =3D 3 (big) repositories; 1.5 milli=
on content objects
   - S3 centric solution =3D 32 repositories; 320 million content objects
   - External SaaS provider =3D 7 repositories but ever growing; 400,000 co=
ntent 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 wa=
nt the "getRepositories" CMIS service to return all ~58+ repositories acros=
s 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, hopeful=
ly 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 u=
sing 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 reposi=
tories that can be rolled out to all of our staff (hopefully using an exist=
ing CMIS file sync tool)
  - A generic sharepoint web part for surfacing content from ECM repositori=
es as required in team sites (hopefully using an existing CMIS webpart)
  - A mechanism to isolate systems and users from any details of independen=
t 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 pr=
oviders, 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 no=
t 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.muleso=
ft.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 i=
ts 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 d=
oes not necessarily reflect the view of Suncorp. The content, including att=
achments, is a confidential communication between Suncorp and the intended =
recipient. If you are not the intended recipient, any use, interference wit=
h, disclosure or copying of this e-mail, including attachments, is unauthor=
ised and expressly prohibited. If you have received this e-mail in error pl=
ease contact the sender immediately and delete the e-mail and any attachmen=
ts from your system.
=1B$B!!=1B(B


________________________________

This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of i=
ts 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 d=
oes not necessarily reflect the view of Suncorp. The content, including att=
achments, is a confidential communication between Suncorp and the intended =
recipient. If you are not the intended recipient, any use, interference wit=
h, disclosure or copying of this e-mail, including attachments, is unauthor=
ised and expressly prohibited. If you have received this e-mail in error pl=
ease contact the sender immediately and delete the e-mail and any attachmen=
ts from your system.
=1B$B!!=1B(B

--_000_C598586168CD8B45B7F51BD429EC638284176499PBNEMBMSX4101in_--