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:[EMAIL PROTECTED] Sent: 07 September 2006 10:00 To: [email protected] 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/[email protected]/msg01496.html [4] http://www.day.com/o.file/spi-arch.jpg?get=0a1a63a2a86ab7041a6bce2e0f55b 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/
