Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Nuclear Fission,
 Splitting the core: The SPI Effect [was: Improving the accessibility of the
 Jackrabbit core]
Date: Thu, 7 Sep 2006 09:48:55 +0100
Message-ID: 
 <FE311A9864CF7940A736054B52211A62066FC249@THEXCHBE2X.services.byworkwise.com>
In-Reply-To: <eb7e2190609070059k6e7999f6vfb4a33db0e63d49f@mail.gmail.com>
Thread-Topic: Nuclear Fission,
 Splitting the core: The SPI Effect [was: Improving the accessibility of the
 Jackrabbit core]
Thread-Index: AcbSU36xYOXPtdKzRJuDrcuRk131KwABmwxw
From: "Miro Walker" <miro.walker@cognifide.com>
To: <dev@jackrabbit.apache.org>

David,

Agreed regarding use of "client" and "server" as terminology - I think
this leads to some fuzzy thinking as the "client" and the application
that uses the "client" get confused.

Could we borrow from JDBC and call them the "JCR Driver" and "JCR
Server"? That to me gives the right sort of thinking in terms of having
a Driver that is used by a client application. The JCR Driver can handle
calls to the JCR Server either locally or remotely (via whatever actual
transport is required). The JCR Server exposes the SPI as a low-level
interface and the JCR Driver "translates" this into a
standards-compliant API.

Miro

-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@gmail.com]=20
Sent: 07 September 2006 10:00
To: dev@jackrabbit.apache.org
Subject: Nuclear Fission, Splitting the core: The SPI Effect [was:
Improving the accessibility of the Jackrabbit core]

Hi All,

I would like to use Jukka's initiative as a starting point to discuss
a couple of high level architecture topics around the SPI initiative
and its potential effect on the overall Jackrabbit architecture.

Please consider all of the following comments as my
personal views which I would like to put up for discussion.
Nothing should at any point be considered "set in
stone". I would like to trigger a design discussion on a
potential revision of the Jackrabbit architecture.

Looking at the current core architecture of Jackrabbit [1] we
have a relatively tightly coupled, heavily interdependant,
monolithic and compact core architecture, which really has
no additional public interface between the JCR API and the
Persistence Manager Interface.

Over the course of the last months (even years) we encountered
new requirements that people wanted to re-use portions of the
Jackrabbit core code or that we wanted to support deployment
Model 3 [2] in a "reasonable way" from a network perspective.
This lead to the "SPI" initiative [3] which was first intended to be
developed as part of JSR-283, but was decided to be out of
scope for this spec.

Generally, the idea of the SPI (Service Provider Interface) is
to create an interface that separates the transient
space (I will call it the "client" for the lack of a better name)
from the persistent portion of a repository (which I will call
the "server" [better naming would be very welcome]) of
Jackrabbit. Not only should this allow to better componentize
the Jackrabbit core and re-use the client and the server
independantly but it also should allow for "meaningful" remoting.

I think a resulting architecture could look something like this [4]
showing a clean split into a client or server portion.

As mentioned above the introduction of the SPI should allow for
meaningful remoting, this involves a somewhat stateless and
"flat" (service oriented) interface that lends itself to remoting.
The SPI should also provide an abstraction for people to "plug
in" any remoting layer be it RMI, WebDAV, SOAP or a
more efficient binary protocol that is specifically designed
for that layer. The SPI should also work without a remoting
layer alltogether to still support the deployment models
1 and 2 [5] in an efficient way.

Providing such a more suitable remoting layer will also
allow people to write clients in non-java environments more
easily [6][7] (I am also aware of .NET and Javascript
clients that are at early stages of the development)

The SPI also has triggered the interest of (commercial) developers
who want to implement a JCR layer on top of their existing "legacy"
repository, without having to re-implement all the "client" portions
needed in the transient space. Those developers would look at
implementing the SPI (the server) and leverage the common
Jackrabbit "client" to reach JCR compliance quicker. I think this
could lead to a more widely used Jackrabbit client and therefore
to a very well tested and scalable implementation.

In my mind the introduction of the SPI would lead to a clean
split of the Jackrabbit core architecture that allows for
much better re-use and better transparency. Essentially
the "core" could be reduced to the "server" which should
siginifcantly reduce the complexity.

Please let me know what you think, as mentioned before
this should be the starting point of an architecture discussion.

regards,
david

[1] http://jackrabbit.apache.org/images/arch/jackrabbit-ism.jpg
[2] http://jackrabbit.apache.org/doc/deploy/howto-model3.html
[3] http://www.mail-archive.com/dev@jackrabbit.apache.org/msg01496.html
[4]
http://www.day.com/o.file/spi-arch.jpg?get=3D0a1a63a2a86ab7041a6bce2e0f55=
b
4a0
[5] http://jackrabbit.apache.org/doc/deploy.html
[6] http://search.cpan.org/~hanenkamp/Java-JCR-0.07/
[7] http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/phpcr/