J2EE design help needed!

[Brian Styles <gi...@hotmail.com>]

Hi all,

I'm trying to develop an extensible architecuture to add new services to my 
existing website. I want this to be similar to www.salesforce.com, where 
each service is accessed via a main tab, and each service is essentially a 
mini-application in itself.

I have an existing struts app which uses EJBs. I have the whole application 
packaged in a single ear, containing a single war (which has struts and 
jsps) and a single jar for the ejbs.

I want to extend this application to have more functionality and services. 
Each service I want to be accessed via a tab from the index jsp. So i want 
an easy way to add new services. It would be nice to allow individual 
developers to work separately on each tab - ie to make each tab or service 
an individual component. I know that struts has the modules configuration, 
allowing several config files, however I think that these still are 
generally packaged in the same war (correct?).

I need some advice on packaging.

I see the following options:

a) Application gets packaged as is, in a single ear containing a single war 
and jar.
pros - simple build, current architecture
cons - monolithic, not component based, not modular

b) individual war file for each new service
pros - modular, possibly more understandable
cons - will get into dependancies between the modules anyway; may have 
issues sharing session objects between wars

there are probably other options.

I'd really love some advice from people who have had these problems in the 
past. They must be out there!

thanks very much indeed,
Brian

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

RE: J2EE design help needed!

[Navjot Singh <na...@net4india.net>]

hi,

>I see the following options:
>
>a) Application gets packaged as is, in a single ear containing a single war
>and jar.
>pros - simple build, current architecture
>cons - monolithic, not component based, not modular
>b) individual war file for each new service
>pros - modular, possibly more understandable
>cons - will get into dependancies between the modules anyway; may have
>issues sharing session objects between wars
>
>there are probably other options.
>
>I'd really love some advice from people who have had these problems in the
>past. They must be out there!
>
>thanks very much indeed,
>Brian

Assume you have multiple wars. Lets think about the ways we can deploy.

1. As Multiple wars in 1 host. That also means more than 1 context.

-- One war might be accessing model casses from other war. Then you decide
about plugging all the model classes into 1 big common jar file. Now, that
jar should be available to all of your wars. So you will deploy that
common.jar to <tomcat>/common/lib OR <tomcat>/endorsed/lib or whatever your
container requirements are. In the end what your war files will contain?
actions/views?

-- How would you forward from one war to another war? Redirects have their
own limitations.

2. As 1 war per host. Say A.war under a.dom.com and B.war under b.dom.com.
Think about passing control.

Struts allows the module functionality so as to help with the development
process so that teams/people can divide the modules among themeselves and do
parallel development.

Generating WARs is the deployment issue.

>From my experience, 1 WAR should be generated for 1 business application.
Generating wars for each of modules within a business application is not a
good idea.

my 2 cents
<navjot/>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org