Re: choices in J2EE architecture

["Burr Sutter" <sutter@bravepoint.com>]

To EJB or not to EJB? That is the proverbial question...

As others have already stated Struts and EJB are not competiting
technologies.  They are typically complimentary. One in the presentation
tier and the other in the business logic/integration/data access tiers.

For me the EJB question is fairly simple, some thoughts:
- EJBs are for distributed computing where one machine is physically
separated from another machine but they both need to talk at the application
level.  A distributed component model like DCOM, RMI or CORBA (and now Web
Services/SOAP).  A way to think of this is that less than 18% of software
applications need distributed computing or a transaction monitor like CICS
or Tuxedo.   Most business systems basically read data from a datastore,
display the data to the end-user, allow updates and put the data back.  And
don't forget about reports!
- If you are building a normal web application then EJBs are rarely
necessary.  If, however, your JSP/Servlet/Struts code runs on server A but
you want your business logic code to run on server B then you have a
distributed computing model.
- If you are building a client/server style (not web but rich client)
application then you need a mechanism for the remote clients to speak to the
server.  Java/Swing on client then RMI or RMI/IIOP (ejb) to the server.   VB
on the client then SOAP to the server.

When uncertain if you need to EJB or not EJB in the futre, build all your
business logic components as POJOs (plain 'ol java objects) since POJOs can
run with JSPs (usebean) in the web container or with a Swing client.  When
the need for distributed computing shows up then you can throw a stateless
session bean wrapper/facade in front of the POJOs.

There are some products that require the use of EJBs. BEA's Workshop
generates them automatically.  Some portal, work-flow and rules engine
products expect to have EJB support.

Perhaps there were too many points here to make the decision easy but here
is the real showstopper - is it politically correct to not use EJB?  EJBs
are very, very popular and most applications need at least one just for
internal political issues .  Many people believe that EJB is J2EE, they are
one in the same.  Many also believe that you can't build a scalable
application without EJBs.  Both are just urban legends but very popular
myths.

Burr

----- Original Message -----
From: "Charles Coombs" <ccoombs@attbi.com>
To: "ajug-members" <ajug-members@www.ajug.org>
Sent: Monday, June 16, 2003 10:25 AM
Subject: choices in J2EE architecture


> I'd like to foment a little discussion regarding what I consider a key
> choice in architecture for a J2EE based system.  I have not found
> specific literature that addresses this.
>
> Given that you can choose to use Struts or EJB or some combination of
> the two, what factors drive your decision?  What are the advantages of
> using EJB at all when Struts can probably get the job done?  My feeling
> on this is that a lot of architects are pounding away on EJB
> implementations that are generally more expensive and complex to develop
> and maintain than a good JSP MVC framework.  A clear delineation of when
> and why EJBs need be used over Struts would be real helpful to budding
> architects here.
>
> Thanks.
> Charlie
>