Discussions

General J2EE: Is scalability the reason to use EJB?

  1. Is scalability the reason to use EJB? (7 messages)

    I had this question in my head for a while and now is time to share it with others..

    I've been reading everywhere that EJB let you build scalable applications, and that if you want to build scalable apps with Java, you should use EJB.

    I think there's a lot of hype on this. There are a lot of reasons to use EJB, but scalability is not the main one.

    What is EJB? It's a lot of things:

    - It's a programming model: If I want to keep the database access code in one side and the UI code in the other, EJB helps me. It also provides a good programming model for distributed applications. If I want to write a distributed app in Java, EJB is a good choice.

    - It's a way to secure your apps. Giving rights to users on objects instead of database tables seems better.

    - It's a 'Object-Relational' mapping tool. If you use CMP, you could forget all you know about SQL and JDBC (or you will be able to do it in the near term with EJB 2.0)

    (I could continue, but I rather go to the point)

    Let's say I don't care about this 3 things. For example, let's say I have a tool that generates Java code, and that provides a way to develop the application in a propietary way. So, I don't care about the programming model, nor the OR mapping, and let's say I don't care about setting security rights at the object level.

    Then, I don't need to have a real 'distributed' application. I don't need to have code running in a lot of boxes at the seame time, cooperating. I just want a servlet application where all the servers are one next to the other.

    I think that the application will be much faster, and more scalable if the app uses JDBC directly to access the database, than going through the EJB layer. Even for transactions (ie, the generated application could use XA for the transactions).

    It's very easy to scale at the Servlet engine level. I just add more servlets engines. It's not that easy to scale in the EJB side, and I really don't see how that could help in improving the scalabilty.

    I'm obviously missing the point, because I can't be the only one who is right on this ,-), but I really don't see the point I'm missing...

    Thanks

    Threaded Messages (7)

  2. Is scalability the reason to use EJB?[ Go to top ]

    It is the primary reason to use stateless session beans, but not stateful session and entities beans. However, the latter ones can be made scalable, if you take advantage of each EJB container's proprietary optimization features and follow the well-documented EJB design patterns.
  3. Is scalability the reason to use EJB?[ Go to top ]

    I am afraid, I will have to agree with Mark on this issue. EJBs appear to reduce, not increase scalability. I think they were indended as a response to COM or, maybe, CORBA, but I have trouble justifying their use every time this question comes up. Other technologies appear to beat them on every level. Servlets are at least as scalable as stateless sessions, JavaBeans combined with object-relational binding systems are more functional and significantly more efficient than entity beans, WebServices are more client-independent and as secure as session beans. The only aspect of EJBs that still has promise is reusability. However I have yet to see a project where the idea of reuse materialized, or at least where it allowed people to save money.

    IMO, its time to tone down the hype.
  4. Is scalability the reason to use EJB?[ Go to top ]

    The points you may be missing :-) (I don't pretend I'm right):

    1. Scalability is about extending application due to growing customer/user needs. This means adding functionality, adding new client devices, integrating new systems and databases. What you are talking about is performance, not scalability. Why:


    2. Pure servlet and JDBC can be slower than servlet
  5. Sorry - something wrong has happened to my browser.
    The points you may be missing :-) (I don't pretend I'm right):

    1. Scalability is about extending application due to growing customer/user needs. This means adding functionality, adding new client devices, integrating new systems and databases. What you are talking about is performance, not scalability. Why:
    - Application logic (EJB) is presentation independent. Think about scaling the application by adding new user devices.
    - Application logic (EJB) should be data store independent. Think about extending the range of data storing mechanisms. For example - replace single database, by a distributed net of heterogenous databases (Oracle, Sybase, DB2) accessed through transaction monitor (Tuxedo, CICS). EJB's (particulary Entity Beans) are built to encapsulate business logic. They are not a kind of information storing mechanism (they may use one in a consistent way). Adding new databases etc. is also a way to improve performance.

    2. Servlet/JDBC can be slower than Servlet/EJB/JDBC. The Entity Beans are good at caching application logic data (business object states). Of course, caching algorithms depends on application server. This is also a matter of design and components granularity. In portal like environements, when number of reads is much more greater than number of writes, using Entity Beans for storing frequently accessed objects (i.e. articles) is a very good solution.

    Regards

    Wojtek
  6. Wojciech,

    My understanding of the term scalability seems to be somewhat different from yours. To me scalability has to do with size, not functionality. The ability to support more users or more data or more transactions is scalability, the ability to be modified easily is flexibility or maintainability.

    1. Examples you are providing are legitimate but addressing them still does not require EJBs. You are saying that session EJBs are presentation-independent, but so are web services. The database-independence is addressed by JDBC and more so by object-relational binding systems. For example, TOPLink will allow you to switch between databases and, on top of that, distribute your application between multiple databases and four tiers - in addition to what EJB does, they will also allow you to maintain transaction scopes on the client side, if the client is connected to the server over an RMI/IIOP connection.

    2. I am not saying EJBs cannot be used for data caching, it's just that other technologies are better at that. Let me use the same example: TOPLink, which has amazing caching capabilities. Of course, you can use an object-relational binding system in conjunctions with EJBs, but then why bother with the EJBs, you can just work directly with the data objects. Soon we will be able to do that in a server-independent fashion (see JDO, http://www.jcp.org/aboutJava/communityprocess/first/jsr012).

    Let me repeat: I am not saying that EJBs are not doing something they promised to do. I am just saying other technologies do those things better.
  7. Is scalability the reason to use EJB?[ Go to top ]

    1. I can achieve presentation independence without EJB, there are a lot of 'web frameworks' to do that, from Cocoon to Struts, XMLC, etc.

    I agree with the second one, you can change your data store for one that scales better, and have better scalability.

    2. There are a lot of better cache mechanisms than EJB Entity beans for read-only content (or 'almost read-only' content). Doing a complex JOIN that can't be done efficiently with Entity Beans plus, for example, Oracle Database Cache, is much better that doing it with Entity beans. Or even caching the dynamic page, as a lot of web app servers do (Oracle Web Cache, Resin, ASP.NET).

    Anyway, you are depending a lot in the quality of the EJB implementation. I don't know if there's an implementation that solves all this issues well.
  8. Is scalability the reason to use EJB?[ Go to top ]

    In
    Deciding whether EJB is appropriate seems to agree with me. It doesn't mention scalability as a reason to go with EJB.