Discussions

EJB design: EJB Server - why/when

  1. EJB Server - why/when (4 messages)

    I have had a good look round theserverside.com, and have read a lot of very interesting information regarding server-side design.

    My question relates to the use of EJB’s and when they are appropriate...

    In both An Approach For Building Scalable Available and Recoverable Applications (http://theserverside.com/resources/np_approach.jsp) and Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition (http://java.sun.com/j2ee/blueprints/) reference is made to scenarios where no EJB server is specified.

    In Designing Enterprise Applications (1.3.3 Web-Centric Application Scenario) the authors say “There are numerous examples that one could concoct where an EJB server (at least initially) could be deemed to be overkill given the problem being tackled.”

    Under what circumstances would the introduction of an EJB server be considered appropriate?

    Additional information:

    * low expected usage (5000 user sessions a day)
    * Busiest hour accounts for 10% of usage (500 sessions)
    * Average <10 transactions per session
    * Servlet/JSPs/Java Beans access CICS Cobol transactions for data
    * Transactions include all data validation etc. so raw input data passed direct to them

    Threaded Messages (4)

  2. EJB Server - why/when[ Go to top ]

    Are you saying that the transaction handling is done in the Cobol portion of your system (such that you don't need transactional integrity between the Servlet/JSP layer and the back-end)? In other words, are you looking at EJB as glue to an existing transactional system or are you implementing a new transactional system? In the former case, EJB may be overkill, in the latter they could be helpful.
  3. EJB Server - why/when[ Go to top ]

    Nathan, thanks for the reply...

    We have an existing transactional system however the actual transactions required for this system are new ones.

    This decision based on skillsets, access to legacy data/systems. The data we require access to is single source.

    To confirm, we would not need transactional integrity between the Servlet/JSP layer and the back-end.

    Any other possible reasons for introducing EJB?

  4. EJB Server - why/when[ Go to top ]

    + an EJB container would give you resource pooling to the back end

    - this is not hard to do in the Servlet/JSP layer

    + an EJB server would separate the business logic from the presentation logic, allowing you to maintain and execute the business layer separately

    - you may get enough separation just with a good architecture at the Servlet/JSP layer

    + an EJB server could provide high availability

    - the existing transactional system might be a single POF

    Where is the system headed in the future? If you will ever need a separate business layer in the future, it will be a lot easier if you start now.
  5. EJB Server - why/when[ Go to top ]

    Thanks again Nathan... in reply to your comments...

    1) Resource pooling at the Servlet layer does not concern me.
    2) We are trying to place as much functionality as possible in the Cobol transactions, we do not even carry out data validation in the Servlet layer. Basically we fire data straight to the Cobol transaction and display the results. I accept there is a level of functionality in deciding if and how to display the result set but I would refer to this as presentation logic (comments?). The Cobol transactions are being written as components that could be re-used by another channel (WAP, iTV etc.). Again I am happy that I can get enough separation in the Servlet layer.
    3) The environment running the Cobol transactions is a serious mainframe environment that can be trusted to be available, if anything, adding an EJB server would reduce availability due to added architecture complexity.

    Hope I am not sounding to negative re EJB route. I just feel that some people are jumping in with both feet without looking for genuine benefit. I can see the benefit with a clean slate, disparate data sources etc. I am just looking for a sanity check that in this case it would probably be overkill. I am a great believer in simplicity and will happily bend the theoretically correct solution to ease implementation, support and maintenance functions which, from experience cause the most problems!

    cheers,