3 Replies Latest reply on Mar 8, 2003 1:42 AM by kdread

    To EJB or not to EJB

    tomyoung67

      Hi all:
      I’ve been using TomCat, JSP, JavaBeans to talk to database servers via JDBC/ODBC and I feel I can do any Web/database related work with the tools I have, such as generating dynamic Web pages and storing/retrieving data from different database servers such as Oracle and SQL Server. I didn’t use any J2EE/EJB.
      Because it seems EJB is a hot topic and lots of people are using it, I studied a little about it. So far, I haven’t found any advantage of using it. In fact, I feel several disadvantages of using it:

      1) You would have to use a heavy weight EJB application server such WebLogic or WebSphere, which are kind of more difficult to learn and certainly more expensive to buy than using just a light weight servlet/JSP engine like TomCat.

      2) When you use EJB, you would have to follow the strict rules of programming, such as defining the interfaces for each EJB. With just using JavaBean, you don’t have this problem.

      3) Each Entity Bean corresponds to a database table. When the database table is changed, such as adding/renaming/deleting columns, the corresponding EJB file would also have to be changed. Compared with using just a JavaBean to do the database work, the changes involved will be minimal - usually, just changing the SQL statements querying the table.

      4) Deploying the EJB is certainly much more complicated than deploying the JSP/JavaBean files in TomCat. With the former, you have to go through all the steps creating the .jar, .war, .ear files and define the jndi names etc., while with the latter all you need to do is just drop the files into the correct folder.

      5) With using the EJB, the .ear file created for one application server often doesn’t work with another application server (I tried to put the .ear file which works for one EJB application server onto another application server and it didn’t work. Other people had similar experiences like mine). I ended up having to re-create the .ear files for the new application server which cost me quite a bit of time. However, with using just a servlet engine, I would think you can just move the source code to the correct folders if you change the engine and it will work.

      6) I heard people say “EJB provides almost transparent scalability”. What does “scalability” mean exactly? Does it mean when the number of users of my application written using only JSP/JavaBean (without EJB) increases to a certain point, my application will run into the “scalability” trouble? If so, what kind of trouble is called “scalability” exactly?

      7) Another advantage of EJB I heard was “transaction management”. Why do I need that? I can use JSP/JavaBean to issue all kinds of SQL statements and commit or rollback any transaction as needed. Why do I need EJB’s “transaction management”?

      8) Another advantage of EJB I heard was “security”. My application currently uses username and passwords to authenticate users. If the user provides the correct username and password, then he/she can access the Web page. If not, then he/she cannot access the Web page. Is this kind of authentication inferior to the one EJB would provide?

      Having said above, my key questions are:

      Is there anything EJB can do but using just JSP/JavaBean cannot? For example, you can call the methods defined in the remote interface of a session bean to do your work such as issuing all kinds of SQL queries/updates after you have instantiated that session bean in a Web page, but I can also call the same methods defined in a JavaBean and do exactly the same thing. What is the difference between the two other than the fact that the former can be said “I am using EJB”? But with the former you do have to use a complicated heavy weight EJB Application Server. What are the advantages of using EJB compared with just using just JSP/JavaBean? Why are people so enthusiastic about using EJB? So far, I feel I can do anything without using EJB and I do feel using EJB just complicates the work unnecessarily, especially with using Entity Beans. I’m sorry if my questions sound naive because my experience with using EJB is very limited. Thank you all for your answers to my questions in advance!

      Tom

        • 1. Re: To EJB or not to EJB

          With EJB+xdoclet I have less code to write than doing plain beans. The following is enough :

          /**
          * @ejb.bean
          * name="UserEJB"
          * displayContent-name="User"
          * type="CMP"
          * cmp-version="2.x"
          * view-type="local"
          * local-jndi-name="nukes/User"
          * schema="user"
          * primkey-field="id"
          *
          * @ejb.pk
          * class="java.lang.Integer"
          *
          * @ejb.transaction
          * type="Required"
          *
          * @ejb.persistence
          * table-name="nuke_users"
          *
          * @ejb.finder
          * signature="org.jboss.nukes.core.ejb.UserEJBLocal findByPrimaryKey(java.lang.Integer id)"
          *
          * @ejb.finder
          * signature="org.jboss.nukes.core.ejb.UserEJBLocal findByUserName(java.lang.String userName)"
          * query="SELECT OBJECT(u) FROM user AS u WHERE u.userName = ?1"
          *
          * @jboss.persistence
          * create-table="false"
          * remove-table="false"
          *
          * @jboss.entity-command
          * name="mysql-get-generated-keys"
          *
          */
          public abstract class UserEJB
          implements EntityBean
          {

          /**
          * @ejb.create-method
          */
          public Integer ejbCreate(String userName, String email, boolean viewEmail, String password, GroupEJBLocal group)
          throws CreateException
          {
          setUserName(userName);
          return null;
          }

          public void ejbPostCreate(String userName, String email, boolean viewEmail, String password, GroupEJBLocal group)
          {
          getGroups().add(group);
          }

          /**
          * @ejb.interface-method
          * @ejb.persistence
          * column-name="pn_uid"
          * @ejb.pk-field
          * @jboss.persistence
          * auto-increment="true"
          */
          public abstract Integer getId();

          public abstract void setId(Integer id);

          /**
          * @ejb.interface-method
          * @ejb.persistence
          * column-name="pn_uname"
          */
          public abstract String getUserName();

          /**
          * @ejb.interface-method
          */
          public abstract void setUserName(String userName);

          etc....

          }

          of course you can use things like hibernate that
          will do the same for you for plain javabeans,
          but I wnant to show you that coding an EJB
          is not more a pain.

          julien

          • 2. Re: To EJB or not to EJB
            tomyoung67

            Hi all:
            Thank you very much for your replies!
            I'm currently in the process of deciding "to EJB or not to EJB" for my new project. My web page uses JSP to generate dynamic web pages and it uses JavaBean to talk to a backend database server to issue all kinds of SQL statements such as select/insert/update etc.. I feel this kind of design (without using any EJB) will serve the purpose. However, the potential users of the Web page are huge. I'm concerned about the "scalability" problem. My questions are:
            1) Will my web application run into trouble if the number of users increases to a certain point?

            2) Will I not have the same problem if I use EJB instead? If so, I can use a session bean instead of a JavaBean to issue the same set of SQL statements. However, I don't see much of a difference between the two approaches. For example, after I have instantiated a session bean in the JSP web page, I call methods defined in the remote interface to issuing all kinds of SQL queries/updates. The methods I call are exactly the same as those defined in the JavaBean. The only difference is that one is defined in a JavaBean while the other is defined in a session bean. So if I make this change and I can say "I am now using EJB", will that solve my problem of "scalability" if I have any? As I said above, I am very concerned about my web application running into trouble when the number of users increases to a certain point. Will the design without using EJB inherently be vulnerable to this trouble? Will the design using EJB (such as session bean) be immune to this trouble or at least be easier to deal with this trouble? Could someone please give some specific scenarios to help me understand the difference between the two?
            3) It is said that "EJB design is N-Tired and N-Tiers allow you to redistribute load more efficiently". In my case, how do I re-distribute the load if needed? I can put the database server on a different machine than the one running the EJB application server to distribute the load, but the same thing can be done with the JSP/JavaBean (with EJB) design, i.e., I can put the database server on a different machine than the one running the servlet engine such as TomCat. I know EJB has lots of advantages. But I may not need them in this project. The "scalability" problem is really what will determine whether I should "to EJB or not to EJB". Could someone please give me some advice? Thanks in advance!

            Tom

            • 3. Re: To EJB or not to EJB
              kdread

              > 1) You would have to use a heavy weight EJB application
              > server such WebLogic or WebSphere, which are kind of more
              > difficult to learn and certainly more expensive to buy
              > than using just a light weight servlet/JSP engine like
              > TomCat.

              Jboss is not really that heavyweight. What defines something as heavyweight vs lightweight?

              > 2) When you use EJB, you would have to follow the strict
              > rules of programming, such as defining the interfaces for
              > each EJB. With just using JavaBean, you don?t have this
              > problem.

              Programming correctly is a problem? [you do have a job right?]


              > 3) Each Entity Bean corresponds to a database table. When
              > the database table is changed, such as
              > adding/renaming/deleting columns, the corresponding EJB
              > file would also have to be changed. Compared with using
              > just a JavaBean to do the database work, the changes
              > involved will be minimal - usually, just changing the SQL
              > statements querying the table.

              You change the java first, not the tables. Also, you can map the table and column names to any ejb names you want via a simple XML file. So renaming a table is no effort.

              > 4) Deploying the EJB is certainly much more complicated
              > than deploying the JSP/JavaBean files in TomCat. With the
              > former, you have to go through all the steps creating the
              > .jar, .war, .ear files and define the jndi names etc.,
              > while with the latter all you need to do is just drop the
              > files into the correct folder.

              ANT?

              > 5) With using the EJB, the .ear file created for one
              > application server often doesn?t work with another
              > application server (I tried to put the .ear file which
              > works for one EJB application server onto another
              > application server and it didn?t work. Other people had
              > similar experiences like mine). I ended up having to

              How often do you switch servers... and why? Also if you use ANT/xdoclet you can avoid problems if its REALLY necessary.

              I won't address the scalability/transaction management features etc... if these arent features you need or think you need then its not a big deal.