Let's start to grasp the underlying idea of Graffito. I agree with you to
clarify this point. Maybe this is not yet defined.
When we will be agree on the Graffito goals, we can try to review together
the architecture and see later if we have to split the project or review
some parts to be more attractive.
I would like to see Graffito as a series of components/services to build ECM
applications. that's all :-)
In my point of view, we need the following layers :
a. "Graffito Core" : all necessary low-level services to define, store,
manage, audit, request and search content. If needed, it can give an access
to different heterogenous content servers (JCR and propriatary servers).
Graffito core have to be extensible. For example, a workflow service could
be added into "Graffito Core".
b. "Graffito Runtime" : it should be possible to deploy the "Graffito Core"
anywhere and customize the components to use. Generally, the "Graffito core"
is matching to a content server or a cluster of content server.
c. "Graffito Applications" : a series of applications which access to
"Graffito Core" to manage a specific kind of content application. Some
basic applications can be a simple document management, a forum or a wiki
application. Advanced web content management can be also a good example. I
think Graffito applications are also components/service based.
d. "Graffito portlets" : a series of portlets used to integrate "Graffito
applications" into portal like Jetspeed.
Is it make sense ? Do you see some point to improve ?
If we are agree on the underlying ideas, let's start the technical details.
Just one word in point of view of architecture, I'm not the SOA expert but
I'm wondering if we can go into this direction.
I've been lurking on this list for a while, trying to better grok where the
Graffito project is and where it's going. I was working on my own Object<->
JCR mapping project, so Graffito is of great interest to me. So here's my
I agree that the underlying idea of Graffito and consensus on this is
On point a I mostly agree - with the exception of the workflow comment. Via
listeners etc I think there are ample places to hook workflow into JCR in
general, and there are a number of workflow engines out there. As such,
tying anything other than the most bare workflow notions into Graffito
limits its use, or at least has users ignoring a bunch of the work in the
core. Yes, the core has to be extensible, but spending too much time on
extensibility prior to an actual release just pushes the release farther and
On point c - couldn't agree more. This gets you to, essentially, a series
of clients that each manages a particular domain model and a series of use
cases. This is where extensibility is key, as folks will always want "one
more property" that you haven't thought of. In this arena there is
something of an interesting need too related to extensibility, and that is a
common node definition lang. Several other jcr backed applications have a
node def lang (ie: CND for Jackrabbit, whatever-it-is for alfresco, etc),
and a wonderful extension point for Graffito to allow and promote domain
specific node defs etc would be a more common way to express the
node/property structure. This could be similar to how Hibernate uses the
notion of dialects to generate RDMS specific DDL for db creation from its
On point d - I've liked the notion of portlets for a long time, but I think
the too tightly coupling the notion/power of Graffito (general Object<->JCR
mapping tool) to portals has stalled its appeal to a larger audience of
developers. This goes along with the sentiment that Graffito could/should
be more properly aligned beneath Jackrabbit than the portals project.
Portals and portal content are a specific domain that JCR is good at
managing, but not the core reason the spec was defined. If the focus is
narrow - Object<->JCR, then building applications on top of that to address
specific domains should be much easier.
So, I've certainly dumped my opinions - I apologize if I've offended or
stepped out of bounds.
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.25/669 - Release Date: 2/4/2007