[jira] [Resolved] (OAK-162) Oak Layering / Remoting architecture

["Jukka Zitting (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting resolved OAK-162.
-------------------------------

    Resolution: Not A Problem

Resolving as Not A Problem, as the overall architecture has evolved from the originally proposed one due to goals and constraints that couldn't be achieved with the original design.

Let's follow up with more specific issues in case there still are outstanding concerns about the current architecture.

> Oak Layering / Remoting architecture
> ------------------------------------
>
>                 Key: OAK-162
>                 URL: https://issues.apache.org/jira/browse/OAK-162
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>            Reporter: Stefan Guggisberg
>
> i had the impression that we started the oak project with a shared view of the layering architecture (roughly based on the jackrabbit spi abstraction/partitioning model).
> the jcr api already implies 2 layers (client/server):
> - session-related operations (transient space etc) 
>   -> javax.jcr.Session
> - workspace-related operations (versioning, locking, node types etc) 
>   -> javax.jcr.Workspace
> the jackrabbit spi represents the abstraction of the workspace-related functionality and obviously lends itself to be remoted.
> here's my understanding of how the oak layering model should look like:
> 1. jcr client (oak-jcr):
>    exposes the jcr api and implements the session-related functionality
>    (transient space!); delegates workspace-related operations to the 
>    spi (oak api)
> 2. server-side repository (oak-core): exposes the spi (oak api) and 
>    implements the workspace-related operations; delegates 
>    persistence-related operations to the mk (oak api)
> 3. persistence layer (oak-mk): exposes the mk api and implements
>    persistence operations
> the oak api and the mk api are the obvious potential remoting points.
> i see the following issues with the current oak code base:
> - the 3 layers are not properly isolated, transient space operations
>   e.g. reach through all 3 layers. workspace mgmt e.g. is 
>   handled on the client. if either the oak or the mk api is
>   remoted this is serious potential performance problem.  
> - there's a mismatch between the spi and the current oak api
>   in terms of scope/functionality; several workspace operations 
>   (such as versioning, ns mgmt, node type mgmt) don't seem to 
>   be reflected in the oak api.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)