[jboss-dev-forums] [Design of JBoss Portal] - Re: WANTED: Input from administrators & developers
Antoine_h
do-not-reply at jboss.com
Fri Aug 17 07:34:05 EDT 2007
Hello,
back to this post, when looking at the JBoss ON monitoring features...
I noticed something : about the xml export/import of the portal description.
I think the whole thing may be seen an other way.
Situation :
Since the begining, I understand it is an easy way to provide admin interface.
and I understand very well it is important that new people that want to give a try to JBoss portal can play around with the portal. Out of the box.
and even for dev, the admin GUI is very usefull for prototyping.
Since the begining, I don't like this database ;-)....
I don't understand why "all this"...
Problem :
1) no use of it, for portal that goes to prod
For a portal in prod : the new pages/windows/portlets will go through a intensive integration and testing work.
No "dev to prod" team will use the admin interface to modify anything.
They will work on the War/Sar given by the dev (after testing), and so every thing rely on the xml descriptor.
in a "simple portal" in prod : minimum integration and testing are done : if there is a problem, it goes back to the dev team for resolution.
in big portal, in big companies : huge integration and testing process, with at least a step into a stagging environement, etc...
So relying of War/Sar (with xml descriptors in it) is much more easy than [War/Sar + database]
(that's why I don't use the database... never... just playing with the GUI, once in a while, when a new version comes out... just to see "what's new"...)
2) the database is a problem in dev to prod cycle
dev to prod is a cycle, going back and forth till the new things works fine.
so having each time to "carry a database" is a burden
3) no database to run a portal
the users in a LDAP
the cms in a... cms legacy or other choice of the company (open source... or vendors).
... and no database for running a portal.
Out of 3 portal I worked on, 2 where from the start on this architecture.
one : users in legacy system, cms = Filenet
second : users in ldap, cms = legacy + choice for a new one going on
third : my own... will use ldap and a cms like Alfresco or Nuxeo, as soon as I can
so, I guess having a portal that avoid to ask for a special "one more database" is a good thing.
4) a burden for HA and admin to monitor this "one more database"
For dev, having a "one more database" is easy...
for prod, it has a cost : one more thing to care at
- architecture of system
- install, integration tests
- monitoring
- writting procedures for SLA, case of failure management
when it comes to HA and clusters of database ... work and cost is increasing :
- multiplication of database server
- multiplication of things to monitor on every day supervision
a lot to take care of every days
Resolution proposal
To consider the database way of working as an option.
Make the portal work only with the descriptor
Admin GUI on files (the war/sar files) :
- read only, for checking things (debug, etc...)
- write : on a special storing place, to then get the files (or a part of one file) and integrate in the dev working files.
- write can be done later... not fundamental... and quite complicate for storing somewhere and then impact the dev files
Admin GUI on database :
- optionnal (separate package for easy installation and desinstallation)
- for out of the box and discovery : what a nice portal !
- prototyping : working with marketing/operationnal on the design, for a proof of concept when "selling a project", etc...
As far as there is a export/import feature... make the database an option is an interesting "next step".
For prod and big portal in companies : it is a good thing.
ok, that's a long post : you understand that "since the beginning, I don't like this database".
now, after a few portal and real prod situation in companies, with cluster for HA, I know why I don't like it.
I don't like it, but I agree the Admin GUI is a major feature for "out of the box" portal. This is very important as for any open source project.
The idea is to find a way to comply to both needs : out of the box, and a portal that is built for prod
hope it helps (whatever is my personnal "I like")...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075168#4075168
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075168
More information about the jboss-dev-forums
mailing list