Mailing-List: contact chemistry-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: chemistry-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of fmueller@opentext.com
 designates 149.235.128.48 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CA7D9C.A41D5C61"
Subject: CMIS Implementation Experiences
Date: Tue, 15 Dec 2009 16:38:23 +0100
Message-ID: <56C255F88C54014E92512ED3E7848F9404679781@MUCXGC1.opentext.net>
Thread-Topic: CMIS Implementation Experiences
Thread-Index: Acp9nKMtpLl4fEUGSAmkNPj6Puq5ng==
From: =?iso-8859-1?Q?Florian_M=FCller?= <fmueller@opentext.com>
To: <chemistry-dev@incubator.apache.org>

------_=_NextPart_001_01CA7D9C.A41D5C61
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,

I would like to foster the technical discussion between the Chemistry =
team and the people behind the OpenCMIS proposal. If you think this is =
inappropriate on this list, please let me know.=20

In order to explain the rationale behind the OpenCMIS design I would =
like to talk about some of the experiences that we made with CMIS client =
and server implementations.

We also started with Abdera on the server side. It turned out to be more =
pain than joy. With a pure JAXB design we ran into compatibility issues. =
A good tradeoff between efficiency, correctness and maintainability =
seems to be StAX with JAXB. OpenCMIS handles all AtomPub related tags =
with StAX and all CMIS related data with JAXB. The JAXB objects are not =
exposed to the application. They are just interim objects. =20
The same StAX/JAXB design should work on the server side as well. The =
effort to implement AtomPub is manageable. I've done this in my CMIS =
FileShare project.

Another detail we learned is that implementing both bindings in parallel =
saves you a lot of refactoring later. Both CMIS bindings are really =
different. If you align your classes and flows to just one binding you =
might have to refactor a lot later  to make the other binding work =
smoothly. This insight is reflected in OpenCMIS in two areas. First of =
all, there is a strict decoupling of the binding implementation =
(Provider layer) and the nicer Java API (Client layer). If somebody =
would show up with a third CMIS binding we just have to touch the =
Provider layer. The second area is within the Provider layer. We tried =
to reuse as much code and concepts as possible between both binding =
implementations. For example, both binding implementations share the =
generated JAXB classes, the caching infrastructure and several =
utilities.=20

We introduced type (and repository info) caching based on our =
experiences with applications using a CMIS library. Applications need =
type information all over the place and it is expensive to fetch them =
over and over again. From a library perspective one can argue that =
caching should be done a level above the library. From practical =
standpoint it would be nice if it is done once and right. So we decided =
to put it into OpenCMIS. If an application doesn't want it, it can =
switch it off. The caching works implicitly. Whenever a type definitions =
runs through the library the data is cached or refreshed.
CMIS provides no mechanism to detect type changes. So there is a slight =
chance that the type cache holds outdated data. In an enterprise =
scenario (and that's what OpenCMIS is aiming at) type changes shouldn't =
happen often. They are usually interconnected with an update or =
re-deployment of the application. A paranoid application developer can =
switch off the cache (and accept the performance penalty) or clear the =
cache regularly (every hour or every five minutes or every 30 =
seconds...) or create a new session once a while. Since sessions are =
bound to logins there is a regular exchange of sessions and therewith =
caches, anyway.=20

Another aspect that we think is important are extensions. CMIS defines a =
lot of extension points and repositories will make use of it sooner or =
later. Application should be able to access and set extension data. =
Sure, it is against the idea of a standard but it will happen and the =
library should be prepared for that. The difficult part here is to make =
the binding invisible to the application since some extension points are =
very binding specific. Using JAXB in both bindings covers a lot but not =
everything. OpenCMIS has the infrastructure in place but is not perfect =
in this regard, yet.


I hope that's the beginning of a fruitful conversation,

Florian

------_=_NextPart_001_01CA7D9C.A41D5C61--