Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Project organization / architecture proposal

Discussion topic

Back to topic list

Project organization / architecture proposal


Author =?ISO-8859-1?Q?Jean-Fran=E7ois_El_Fouly?= <jean-francois at elfouly dot nom dot fr>
Full name =?ISO-8859-1?Q?Jean-Fran=E7ois_El_Fouly?= <jean-francois at elfouly dot nom dot fr>
Date 2007-04-04 08:33:50 PDT
Message I'm trying just to write down what I have in mind -- little if any is a
firm decision at this stage so about everything is open to discussion.
I attached a small architecture drawing (already a version 2 if you
count the first proposal)

- JDK 5 seems the way to go.

- Persistence layer: I haven't seen in the thread any objection against
EJB3/JPA/Hibernate instead of Torque. The code currently in
scarab-persistent-om is a (quick) generation from the Torque schema
using an ad hoc tool I wrote in an afternoon and did not care to commit
(not a masterpiece of software engineering). So the classes that are
there are the equivalent of the Base*.java classes generated by Torque
-- except they are not abstract.
I don't feel we need to make it the ancient way -- take these classes as
generated artefacts and extend them with some "stable" hand-written
classes. The compatibility with the current schema is a must, and that
schema is pretty stable so I definitely would prefer that we keep it
simple and add code and annotations in these classes.
Status: all the scaffolding code (the code that manages the relations
between entities) is missing, because I could not find a simple way to
generate it from the Torque schema, though some of the required info was
obviously there.
Some "physical" information, such as index information, has not been
generated neither.
TODO also: write the Maven tasks that will generate the DDL with
Hibernate. Not top priority since we can test on an existing Scarab
database, but would certainly be useful for unit tests and such.

Where do we go from here ?
I see two different "architectures" and this is definitely to be discussed.

1) Mick Semb Wever and Jon Scott Stevens both made a short plea for Seam.
We consider using Seam at work and I've played with it, I like what I've
seen but I would certainly not consider me a Seam expert. This is not
the framework I had in mind because it is much more a revolution than an
evolution: Seam is a full stack, it uses its own way of doing things so
we can achieve *compatibility* with the existing Scarab if we build the
app bottom up from the current schema but we probably cannot achieve any
*commonality* : it's definitely going to be a full rewrite.
I'm tempted but I'm not sure I'd like to jump in myself right now
(meditating, though).
Yet if someone else, right now, is willing to create a sub-project and
play with Seam for a while until we see what gives the best and fastest
results and make a choice, I'm not going to dissuade him or her.
Obviously if we commit ourselves in developing a new version of Scarab
another way, it's probably going to be too late in six months (unless
the current way of doing it sucks, of course).
Another thing to take into consideration about SEAM is that -- at least
at the moment -- we would get married with JBoss.

2) What I had in mind in the first place looks more like an evolution /
a reorganisation of the current code base.
Apply the "Divide and conquer" strategy and cut the existing code into
several modules.
- A service layer that would use Spring as its framework. I wholly agree
with the proposal Peter Ledbrook had made slightly more than a year ago
in the Scarab wiki:
so I'm not going to comment much here. Except for one thing: we need to
have somewhere the "services" that are currently exposed via XML-RPC;
that is a point where I would not like to break compatibility, even if I
would like to have them exposed with SOAP (as true WS) too.
- A UI layer that would deliver the current UI (Velocity templates and
i18n -- that is quite a lot of work that I'd definitely prefer not to
re-do) with Spring MVC -- which has render classes for Velocity templates.
- If someone is willing to develop another UI on top of the service
layer, that would certainly be possible some day (hints: Ajax, JSF, ...)

Having a service layer that we could expose in XML-RPC or in WS would
allow additional UI's such as IDE plugins, and custom applications that
can converse with Scarab.

Again, all this is open to discussion !

Have a good day,

Jean-Francois El Fouly

« Previous message in topic | 1 of 3 | Next message in topic »


Show all messages in topic

Project organization / architecture proposal =?ISO-8859-1?Q?Jean-Fran=E7ois_El_Fouly?= <jean-francois at elfouly dot nom dot fr> =?ISO-8859-1?Q?Jean-Fran=E7ois_El_Fouly?= <jean-francois at elfouly dot nom dot fr> 2007-04-04 08:33:50 PDT
     Re: Project organization / architecture proposal juriarte Jorge Uriarte 2007-04-04 08:41:53 PDT
     Re: Project organization / architecture proposal =?ISO-8859-1?Q?Jean-Fran=E7ois_El_Fouly?= <jean-francois at elfouly dot nom dot fr> =?ISO-8859-1?Q?Jean-Fran=E7ois_El_Fouly?= <jean-francois at elfouly dot nom dot fr> 2007-04-12 07:38:34 PDT
Messages per page: