In this article, Peter Pilgrim looks at the best practice of using a popular web application toolkit, The Expresso Framework. It now integrates Struts, further reducing the amount of code that developers need to write. As well as having an MVC framework, Struts also has its own powerful custom tag actions. Custom tag libraries and their powerful bean introspection core further reduce the total amount of Java scriptlets in Java Server Pages.

Read article here

Can someone explain to me in what cases you are better of to choose expresso over ejb's.

The question boils down to: why choose anything else than EJB, especially for DB-driven applications?

This depends on a number of parameters, and I'm sure I'm not the final expert on this, but I think the main one is:
can you get your thing rolling in a single-process deployment, or do you really need those multi-server, load-balancing, cluster,... configurations?

If you don't, a full-blown EJB server is probably overkill,
especially since it solves only the combination of persistence/distribution. For the rest you need to build/find/purchase a lot of extra components anyway.

And then, frameworks such as www.jcorporate.com's Expresso , or www.tuple.be's Passerelle are much handier
and much less costly. They make some compromises on persistence/performance scalability (although you'll find that they often out-perform EJB in single-process deployments), but give you much higher efficiency in your development work.

Cheers,

Erwin.

Assume that EJB is out of the question, what are the alternatives? Expresso (include Struts) vs. Turbine? I know that turbine mainly depend on template technology and Expresso is more closed to J2EE. What I really want to know is the overall productivity and performance

The question not one of expresso vs EJB?
It is to EJB or not to EJB?

If you take a step backwards, the question
is really to go J2EE or not J2EE? I would
say J2EE has at its "heart" Enterprise java beans,
but you do not have to use EJB if you do not want
to. You can go with JMS, Servlets, RMI/IIOP.
If you want to have component transaction
management with full transaction control,
replication, and scalability then for Java
server project your best choice is to use
a J2EE application server. If you have
database table rows that must be
mission critically protected ( crediting
and debiting a bank balance ) then you
have to go Entity EJB at this moment in
time.

However people are changing their minds
here. They are starting to question the amount
of programming work that must go into
accessing the simplest employee row tuple.
The question is an easy and age-olde
"There surely must be an easier way to
do this?"

This is where exactly people are looking
for new answers, possibly JDO, Castor and XML
binding to alternative Entity EJB solutions.

To wrap up, Expresso DBObjects are alternative
way but it was not meant to be a entity EJB
challenger, just a simple way to generically
access database table row tuples.

Confused? You will be during 2002

Peter Pilgrim March 2002

I am not sure whether I should post this question here. Actually our application is heavily driven by CORBA. Can CORBA business objects be used in conjunction with Expresso and Struts to built up an Enterprise Application ?

Good article thank you!
IMHO the part that is missing in Struts is one solide State Engine. That is a pain to work with independant Action and save State in HttpSession because the developer forget to clean it when he has to and Session grows, grows, ...
This level should collect different Action in one piece. Expresso seems to handle that. Good :)
The bad thing is that Expresso is linking itself too much to DB objects :( While Struts only works with Form object.
I guess many people hacked ActionServlet from Struts to do this in different ways.
The workflow proposal Struts have currently is going too far, too complex imho. We all need a simple engine.
I agree the war is over one part, Struts won on their Tag library, nested properties handling, Form (validation,...)
But on this State Engine, I would really like to see one winner... The nominees are Turbine, Struts, Expresso, WebWork,... (for sure an open source project).
Let the best wins !

I skimmed the article. It seems to me that any framework that does not make use of a decoupled middle tier (jndi/rmi/rpc/anything) is taking a scalability risk.

The option of moving the middle tier to another box should be preserved - basically because there are loads of architectures out there that let you do this with little pain.

I prefer:
Struts for Gui
Value obj mimic of form obj to middle tier
Stateless session beans at middle tier
Talking to local interface EJB's
Who do data persistance.

When running on the same box you DO take a performance hit, you muster data into value objects about 3 or 4 times more often, and you do JNDI lookup and pass by value semantics to the session bean. BUT, its still fast, and means you can easily move the middle tier off.

And, if you place the session beans on the database box (for a small site) then you actually get less network traffic as only required fields are transferred from the session beans to the web tier. When load increases you shift session beans to a mid tier and take the network hit to free up the database resource.

i.e. I don't buy into a framework that doesn't buy into RPC. The entire industry loves RPC/EJB/RMI/whatever.

Jonathan
ps LowRoad with local EJB's out tonight (and it generates all the code I mention above).

Sigh.

Well I did develop a very nice workflow engine for webapplications using a single workflow.xml to wire up the whole application, fixed the URL/content asynchronity, and introduced a use-case approach instead of form based approach. Which again allows for reuse of individual JSP pages in multiple use-cases (using an exit status instead of "hardcoded" links).

Oh and of course validating HTML tags which CAN use form beans but can also write directly into the BM (less code!) or use-case beans.

And ah international handling, but with regexps, so you can morph your error messages (include parts of the original message, like an "how to write a date" example).

Problem is... I did this for a commercial client. I can't publish them...

Tom

Thanks you, you're welcome.

Yes state engine is desirable in pure Struts.
In Expresso this is solved with the use of
database to store the FSM.

If Pure Struts were to use a state engine of its own
it would imagine use XML and Commons Digester
to implement the solution portably and widely.
Struts would also have to look at the security
of the actions and their state; who can access
what action and whose states ?

What won me to the Expresso was the way
database access is handled by mapping. It remains
me of Perl's hash data types. It made handling database
table generically far easier. The only sticking point
is that Expresso does not handle callable statements
of any kind generically. Stored Procedures. For some
organisation this is a tough brick wall, because
they are typically business that have an invest
in stored procedures and transactions. In other words
they do not want to the change their application.
Therefore the vendor must adapt to them.

I am not sure what your complaint against database
object is, really but I guess it possible to have
a DBObject act as an Struts ActionForm. Even
better architectural is to make the ActionForm
contain DBObjects themselves. Struts has to the
ability to access nested properties so this
is simple except for the fact that mapped
properties attributes are forthcoming feature
in Struts 1.1 (and Expresso 4.1+ ).

As with all frameworks your mileage will vary.
Last year the debate was about WebMacro and JSP
and MVC? Now look how much we moved onwards.
Struts-User mailing list has more mail
than the official JSP-Interest mailing list
per day. Thats show you the power of small
framework such as Struts. As I said the power
of the framework is it genericity, quality,
easy-of-use, architecture, and applicability
to tasks that developers want to do today.

Peter Pilgrim March 2002