incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: Graffito status followup
Date Mon, 05 Feb 2007 12:06:27 GMT
Hi Jukka,

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.


br,
Christophe

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message