Discussions

Web tier: servlets, JSP, Web frameworks: how to design a business layer in Tomcat/Struts without EJB?

  1. We have decided to use Tomcat and struts for a project. instead of using entity bean, we use JDO for persistence. But , without session bean to host business services, we will have to write plain java code for business logic. We will need to develop our own transaction control, security control and others services typically provided by EJB containers. My question:
    1. it our decision for not using EJB at all a good one (for a relatively small project, we certainly don't need distributed computing, not a heavy user load that high end j2ee servers provides).
    2. I like to have a business layer that is outside of Strut and web app framework. How do I go about it? java beans? how to deal with declarative security? how about session pooling and transaction control?

    Threaded Messages (10)

  2. 1. Transactions: Use JDO to manage it.

    2. Declarative security: If you want this, you will have to build it yourself. Determine if this is something you really need. Odds are good that you can get by without it (using hard-coded security). If you absolutely must have this, define a custom security configuration file with application permissions and check against that file in your application code, or use JAAS.

    3. Use JavaBeans for your business logic. Use JDO objects in place of entities, and write plain JavaBeans in place of session beans for more complex logic and for transaction management. You will need to crank out the transaction logic by hand, but with JDO, it should not be too hard.

    4. I am not sure what you mean by "session pooling". If you mean "connection pooling", your JDO implementation should handle it. If you mean "servlet session pooling", Tomcat won't support that. If this is a small project, though, you probably won't need to cluster servers, so this is likely to servlet session pooling should not be required.
  3. Paul,
    Thank you for your timely and helpful insights. We have several related products that are of small scale (mostly for administrative departmental internal users). We are planning to migrate them to web-based, java-powered (J2EE standard) from legacy client/server architecture. The new system will still be used by limited intranet users while providing access to internet users (not a heavy load). I feel using EJB is unnecessary. so I pretty decided to use as you recommended java beans for business logic, JDO for persistence in addition to struts (and XSTL/Tiles/JFS for presentation). To leave room for future possibility of using session beans for business logic and using entity beans for persistence, I am thinking about define a business logic interface and a data access interface so that the actual implementation can be plug and play. thinking about using Factory pattern. I wonder:
    1. how to do it? any body does it ? any code example?
    2. is making implementation plug and play a over engineering?
    3. how about performance of adding additional abstract layers?
    Thanks in advance!
    Jay
  4. Well, you can use a Business Delegate pattern (which is a variation on the Gang-of-Four Facade pattern) to hide your processing logic from your UI layer. The extra work would not be that great, and the performance impact would be minimal. Do something like this:

    UI --> Business Delegate --> JDO

    Later, you can switch this too:

    UI --> Business Delegate --> Session EJB (or whatever)

    Your business delegates can be written as simple Java Beans. The only trick is that you have to make sure your delegates wrap your JDO errors with a more generic error (such as a custom BusinessException). That way, when/if you switch to session EJB, you can wrap the EJB-related exceptions in the BusinessException instead of the JDO exceptions, that way you don't need to rewrite the client.

    What I described above is pretty simple. If you want to use the Factory pattern and configuration files to dynamically switch between a JDO implementation and a Session Bean implementation, you are probably over-engineering.
  5. Jay,

    Please allow me to be part of this conversation. I currently have a situation similar to yours where I designed my application using the following:

    UI-->Business Interface --> Business Delegatge --> DAO -->Stored Procedures

    this is analogous to what paul is talking about except that my BD is not a session bean rather a regular java class. Transactions are managed via SP and Security is taken care of programmatically.
    My application is in testing phase right now it's working fine. However, I lack the experience that could help me forsee any issues with this design. May be Paul can shed some light on the this.

    Ahmed
  6. stored procedures?[ Go to top ]

    Ahmed,
    I would limits the use of stored procedures. I would put business logic in business service layer instead of DB layer. I wonder whatis the rational of using SP? performance gain?
  7. stored procedures?[ Go to top ]

    Paul, Jay

    Yes, The business logic takes place in the business tier. where stored procedures are mainly used to do transactions. I understand that my application will not be easily portable beteween different DataBases. However we are not planning on moving to a different database any time soon.
    I have one design concern if you don't mind to shed some light on.
    I am using the Value-Object/Transport-Object pattern, I have several actions that require a lot of data to be transported between tiers. what is not clear to me is wether I should map every action with its unique value object or create a big value object that holds all the needed parameters for all the actions, or use inheretence between value object to avoid code duplication.
  8. Thanks[ Go to top ]

    Paul,
    Thanks.
    Your advice is well taken. I will be using the delegate pattern. My architecture will look like this:

    web presentation layer
    |
    Business service interface (delegate)
    |
    business service implementation (plain java, java beans or session beans)
    |
    data access interface
    |
    data access implementation (JDO, entity beans or others)
    |
    DB

    what do you think?
  9. Try the Spring Framework. This will give you a good way of managing your business objects without EJB. It also provides declarative transactions without EJB. It integrates nicely with JDO.

    Your business objects will be JavaBeans (POJOs). Mostly they won't have any dependencies on the Spring framework, and will be very easy to test. They'll be configured by Inversion of Control via their JavaBean setter methods.

    You should program to interfaces rather than classes: define interfaces for your business objects and program to that. Spring makes this very easy.

    You can use Struts for the web tier if you want--you don't need to use the Spring MVC framework, although you might want to take a look at it.

    I think doing without EJB is the best choice for such a project. You can do custom security via Spring AOP if you need to.

    The basic design philosophy is discussed in my book, Expert One-on-One J2EE.

    Regards,
    Rod
  10. Behind your business interfaces, you can use POJOs or even local session beans. (Spring allows codeless business delegates via dynamic proxies.)

    You can use the DAO pattern with stored procedures if you want: I have one client who do this very successfully with Spring.
  11. a similiar situation:[ Go to top ]

    The flow of action class -> business logic - pojos -> DAO objects is clear to me. when i look for the pojos or the DAO objects should i use a singleton factory or create a new instances? Thanks in advance!