jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Nuclear Fission, Splitting the core: The SPI Effect [was: Improving the accessibility of the Jackrabbit core]
Date Thu, 07 Sep 2006 07:59:37 GMT
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=0a1a63a2a86ab7041a6bce2e0f55b4a0
[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/

Mime
View raw message