Menu
▾
▴
#1 Pluggable architecture
It should be possible that new features in jeteam can be
added without any changes to the existing deployable
code.
This means that adding new beans to the system can
be done seemlessly by deploying a new package.
In order to do this succesfully it will be required that the
tables in the database do not have foreign keys into the
plugin tables
On the otherside it should also be possible to undeploy
plugins, there fore invalidating the associated tables
(what this exactly means is an open question, maybe
they are dropped, maybe the data is only logically
deleted)
It would be nice to be able to deploy new features
through the JMX interface
The implementation of this architecture may not be
immediate, however, we must bear it in mind.
Logged In: YES
user_id=599649
Indeed, this is going to be a great challenge and something
we must go for.
The major issue will be probably on the client side where
new functionnalities must be reflected too. Either by being
smoothtly integrated in the pre-existing pages or by new
functionnalites that appear in a toolbar, for instance (most
easiest). As you said, it must be discussed.
There's a good tool for JMX management. It's called EJTools.
Logged In: YES
user_id=599592
we should define what this concretely means, do we write a
core first with thinking about this and integrate it
afterwards, or do we start with a micro-kernel and plugin
features one at a time ?
I am not sure this is possible because some features might
go through the complete implementation stack
as an example: how can you plugin security (application
specific roles etc...) if you want to maintain compatibility
with JAAS on the backend (security roles) and on the
front-end (roles referenced from Struts), what I mean is:
won't changing a plugin have too much effect on the rest of
the app.. isn't the app's business always closely tied by
construction ?
with JBoss it is different as this is the purpose of their
software, furthermore they follow standards that are
designed to provide exactly and only just that: middleware
software
for an application this lies a little different, so for
these reasons we might consider abondoning this feature
also: is it really a desired feature ? how does it affect
release times ? will it overcomplicate design ?