[ArchitectureV2] Model proposal

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

vmassol
Administrator

On Jun 4, 2007, at 9:34 PM, Sergiu Dumitriu wrote:

[snip]

>> * Our model classes should call the storage interface for any methods
>> requiring storage access (for example: Space.getDocuments()). If
>> other services are required they should be called out too. We still
>> need to define a rule for when a new method can be added to the model
>> classes and when a new component should rather be created. I have
>> some ideas but I'm not 100% sure here so I'd like to hear what you
>> think.
>>
>
> This requires less programming than writing our own lazy loaders, and
> is safer than using JPOX. I wish there was a better method to hide the
> storage, and still not load the complete database in memory.
>
> Btw, space.getDocuments() returns all the documents in that space,
> fully loaded?
Yes. We need to think about how many methods do we offer in the Model  
API. For example do we offer:

Space.getDocuments(DocumentFilter filter)
Space.getDocuments(Query query)
Space.getDocument(String name)
Space.getDocumentsForXXX(...)

or do we create some external Search components for each Model class?

I think we could get away with a single Space.getDocument
(DocumentFilter filter) + Space.getDocument(String), where  
DocumentFilter is a way to filter documents independent of the  
underlying storage mechanism.

And we can then have some other Query component that transforms free  
form queries (like hibernate queries) into DocumentFilter objects (or  
whatever we want to call it). I haven't thought much about the  
DocumentFilter API itself but we would need something pretty generic.

Anyway the question here right now is whether we think  
Space.getDocument(DocumentFilter filter) is enough or not?

If we agree it's enough then I wonder if Space.getDocuments() should  
stay. I would be in favor of removing it. It would be replaced by  
Space.getDocuments(DocumentFilter.ALL).

I really like minimal APIs and I don't think overloaded methods  
should go in the Model classes. But everything has pros and cons. One  
con: Someone may later create a SpaceHelper.getAllDocuments() helper  
method/component...

Other question: Transversal queries. Example: let's say we want to  
get the document named D in the S space. Do we offer a  
Wiki.getDocument(Space space, String docname) API? Or do we say the  
user has to traverse the object hierarchy: Wiki.getSpace
(space).getDocument(docname)? (the latter is my preference). We may  
need some transversal APIs though but I think these should go in some  
other component (not sure though).

> space.getDocumentsNames() loads the list of documents,
> or just retrieves the names?

Ah that's another API for getting documents which I haven't listed  
above... :)

I think we should only have one API: Space.getDocuments
(DocumentFilter filter). However this will NOT load the metadata of  
documents. These will be only loaded when Document.getMetadata() is  
called. Thus retrieving documents or just their names will be about  
the same in execution time (it'll only load data in one table).

WDYT?

Are there cases where this is not true?

> Regarding the latter issue, we should try to make the components as
> stable as possible. After we all agree on a component, we need strong
> reasons to introduce something new.

Agreed. I'd like to use something like Clirr later on to ensure the  
build fails
(see http://blogs.codehaus.org/people/vmassol/archives/ 
001324_ensuring_binary_compatibility.html)

In any case we need a consensus that changing something in the Model  
requires a vote.

> Another issue, as far as I remember, components should be interfaces.
> Will the model be an interface, too, with a default implementation? Or
> will it not be a component?

They shouldn't be components as we need to be able to do new on them  
and pass them around in method calls, etc.

>> * I think it would be a good idea to have our model defined
>> independently of the language (for example in XML - Here's for
>> example the Maven model defined in xml:
>> http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/
>> src/main/mdo/maven.mdo
>>
>
> +1 on that, as I'm a total adept of XML. But, what language should we
> use for the definition? I'd go for XSD, as I know nothing about
> Modello.
It's just a build time tool to easily generate stuff. It's pretty  
powerful, has lots of cool features, integrates supra well with  
Maven. XSLT transformation is a major PITA and I wouldn't want us to  
touch that as much as possible ;)

Modello can use velocity templates for the generation, java code, etc.

[snip]

Thanks
-Vincent





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [ArchitectureV2] Model proposal

Stéphane Laurière-6
In reply to this post by vmassol
Hi Vincent, hi all,

I tried to explain below which advantages I see in reusing JCR concepts
as much as possible.

Vincent Massol wrote:

> ok I'll try to summarize my current thinking after all the exchanged
>  emails:
>
> * I don't think we should model our Model classes using a similar API
>  as the JCR one. I much prefer we have an expressive Model with a
> strongly typed API, with objects like Document, Space, MetaData,
> Farm, Wiki, etc. Stephane, I keep turning this in my head and I can't
>  figure a good reason to have a JRC like API for our model. Maybe
> you're seeing something that I don't see? Ludovic also said "[...]
> quite a few benefits to have our objects comply with the JCR model".
>  I don't see them so maybe someone could enlighten me.
I agree we need in any case an expressive model that will capture the
specific features of XWiki. However, since a significant part of XWiki
features are already quite well expressed by the JCR API, we could take
into account the well thought and well accepted JCR content manipulation
concepts and APIs such as Node, NodeDefinition, NodeType, Property,
PropertyDefinition, PropertyType, Workspace, Session, for adopting the
following methodology: we could consider the current version of the JCR
as a set of services to be supplemented with services that we're missing
for building XWiki features, introducing specific concepts only when
necessary. In that sense, I agree with Luis for saying that the JCR is a
possible "metamodel" for our specific XWiki model. As Ludovic also
pointed out earlier in this thread, we should not reduce the JCR to a
storage API, since it is is a general API for representing operations on
content, and is, as such, an API that models well part of our
application behaviour.

Note about Session: Session is not part of the data model indeed, but I
think it's a handy class to be present at the model level, avoiding to
pass the context to each method of the data model classes, as opposed to
the current XWiki API.

However, the JCR has drawbacks as well, and it is obviously missing
important features needed for XWiki:

- the JCR is too monolithic: all the services live in the same API, and
new services cannot easily be added. Moreover, the API provides several
identical functionalities from different places (redundant API
example: a node can be moved from different classes: Session and Workspace).

- the JCR is lacking a service for advanced management of properties:
for instance, it's not possible with the JCR API to get all the
back-references to a Node.

- the JCR is obviously missing other services that we need for XWiki.

Following a discussion with Mikhail, my proposal would be the following:

Step 1: we split the JCR into the following services(to be possibly
submitted as a JCR evolution proposal later on):
- StorageService for atomic types including binaries
- ContentMonitoringService
- LockService
- IndexingService
- RepositoryAccessControlService
- QueryService
- XMLExportService
- VersioningService
- TransactionService
- TypedPropertyService
- DirectReferenceService
- [...] probably others

Step 2: implement those services using an existing JCR implementation,
and also possibly using our own implementation, reusing the
XWikiHibernateStore and the surrounding classes.

Step 3: supplement these content services with the property management
services we're missing for dealing with our XClass functionalities,
but not introducing any specific XWiki concept at this stage. The
advantage of having those services as extensions to the JCR instead of
having them at the XWiki level is that the services would remain as
generic as possible while providing easy interoperability with the JCR.
Complementing the JCR with services providing advanced management of
node properties is a topic that is currently of high interest to several
communities. Participating in that effort may lead to a sound
and standard API, implemented by several vendors, XWiki among others,
and may make our community a strategic one among the emerging semantic
web content repository initiatives. The needs for these supplementary
services are well captured by the idea of a "Semantic Web Content
Repository" in the slides below by Max Völkel [1],[2] and are mentioned
in a recent email to the jackrabbit-dev list [3].

[1] http://swecr.googlecode.com/files/2007-03-12-SWECR-2.pdf
[2] SWECR project: http://code.google.com/p/swecr/
[3] http://www.mail-archive.com/dev@.../msg05524.html

The services we're speaking about are typically the following:
- ReferenceService (for manipulating object properties)
- SparqlService (if we go for RDF for representing our classes and
instances)
- IdentityService (ID/URI mapping)
- InferenceService
They should in particular cover the use cases described by
Sergiu in a previous post, which are of great relevance indeed [4].
Cognium Systems has expressed interest for co-developing such services
with us, in an Apache License-like.

[4]
http://www.nabble.com/Re%3A--ArchitectureV2--Model-proposal-p10865097.html).

Step 4: specify the specific XWiki services for dealing with structured
and unstructured data as complementary services to the SWECR, and design
an expressive model describing XWiki specific artifacts on top of the SWECR.

Step 5: implement these services on top of an SWCR implementation

Step 6: design and implement the other XWiki services (i.e. all those
that do not directly relate to content manipulation).

As a summary, here are two schematic stacks of models and services for
comparing the two approaches we're discussing, as I understand them.

Approach 1 stack
================

XWiki services
---------------------------
XWiki type model:
XClass, XProperty
---------------------------
XWiki document model:
Document, Space, Attachment,
Wiki, Farm
---------------------------
XWiki persistence service:
Data Access Objects
---------------------------
JCR impl.|Relational impl.|...

Advantages:
- we can quite easily implement several storages (JCR, relational
storage) using Data Access Objects
- the model is quite close to the existing one
- we don't modify the JCR
Cons:
- the management of types and properties is not generic
- people used to the JCR concepts have a complete new model to learn,
without clear correspondance between XWiki concepts and JCR concepts
- we have no obvious reason to participate in content management
standardization efforts

Approach 2 stack
================

XWiki services
--------------------------
XWiki document model
---------------------------
SWCR services:
- Type/Property services
- JCR services splitted into
serveral ones
----------------------------
JCR document model, JCR type model
---------------------------
JCR impl.|Relational storage impl|...

Pros:
- genericity of the property/types services
- we embrace the JCR movement, and take part in its evolution
- we take part in the emerging area of semantic web content repositories
and the design of standard Semantic Web APIs complementing the JCR
Cons:
- larger effort
- probably harder to implement a compatibility layer with XWiki 1.0 API
- bigger performance risks

Stéphane


>
> * Our model classes should call the storage interface for any methods
>  requiring storage access (for example: Space.getDocuments()). If
> other services are required they should be called out too. We still
> need to define a rule for when a new method can be added to the model
>  classes and when a new component should rather be created. I have
> some ideas but I'm not 100% sure here so I'd like to hear what you
> think.
>
> * I think it would be a good idea to have our model defined
> independently of the language (for example in XML - Here's for
> example the Maven model defined in xml:
> http://svn.apache.org/repos/asf/maven/components/trunk/maven-model/src/main/mdo/maven.mdo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The reason is that this will allow us to generate lots of things from
>  this model: - Java bindings - XSD - Documentation - Any other
> language bindings - etc
>
>
> We could use Modello for doing this. It's well integrated into Maven2
>  and is easy to use.
>
> * I don't think we should use JPOX. Jason, whom I trust, says it's
> been a bad decision for Continuum (they use jpox) and that there are
>  only 2 active developers for jpox which makes bugs take time to fix,
>  etc. In addition, I'm not sure what this would buy us as I think we
>  should have storage interface and a JCR implementation of it that
> would map to whatever underlying store is configured. Not sure where
>  we would fit JPOX in there.
>
> WDYT?
>
> Thanks -Vincent
>
> On May 28, 2007, at 9:38 AM, Vincent Massol wrote:
>
>> Hi,
>>
>> Starting from today I'm going to spend some time every week on the
>>  V2 Architecture/Redesign. Today I'd like to start at the heart of
>>  the topic with the domain model. Here's my proposal:
>>
>> * Model classes are classes representing the XWiki model. The main
>>  classes are: - Farm - Wiki - Space - Document - XObject - XClass -
>>  (probably lots of others) * As you can see I'd like to introduce
>> the Space and Farm objects * We create a model/ build module in
>> trunks-devs/xwiki/model for storing model classes * Model classes
>> cannot access other classes outside of the model/ module. They are
>>  meant to be used by components to provide services but they
>> shouldn't provide services themselves. They can methods to
>> manipulate their fields and they can call each other but they
>> cannot call outside of their model. * We use the org.xwiki.model
>> package for storing Model classes * These model classes are all
>> user public (API)
>>
>> WDYT?
>>
>> Barring any negative feedback I'll start implementing this today
>> and in the coming days. One question that remains unanswered in my
>>  mind is how do we integrate back these model classes into the V1
>> architecture. I think we should be able to retrofit the existing
>> classes to use these classes by composition. For example the
>> Document object could have 2 fields: one org.xwiki.model.Document
>> and one org.xwiki.model.Space. The XWiki object could have 2
>> fields: Wiki and Farm, etc. I'm not sure how this would work out
>> though. Any idea is welcome.
>>
>> Thanks -Vincent
>>
>>
>>
>>
>> -- You receive this message as a subscriber of the
>> [hidden email] mailing list. To unsubscribe:
>> mailto:[hidden email] For general help:
>> mailto:[hidden email]?subject=help ObjectWeb mailing lists
>> service home page: http://www.objectweb.org/wws
>
>

--
Stéphane Laurière
[hidden email]

XWiki Research
http://www.xwiki.com
http://concerto.xwiki.com
http://nepomuk.semanticdesktop.org
























--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
12