New Article on "Expresso Framework using Struts" Posted on TSS

Discussions

News: New Article on "Expresso Framework using Struts" Posted on TSS

  1. 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
  2. Can someone explain to me in what cases you are better of to choose expresso over ejb's.
  3. 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.
  4. 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
  5. 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





  6. 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 ?
  7. 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 !
  8. 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).
  9. 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
  10. 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