Why EJB? (no really ... why?)

Discussions

EJB programming & troubleshooting: Why EJB? (no really ... why?)

  1. Why EJB? (no really ... why?) (10 messages)

    Hi,

    I know Java, I know servlets/JSP and I have been looking into EJBs to try to understand where they fit into the picture. Unfortunately I am having real dificulty understanding their value. I have read "Professional J2EE Application Programming" by Wrox, I have browsed this site, read many FAQs on other sites, and still I am afraid I am missing the point.

    Let's see if I can summarize the proposed value of EJBs that I have read and why I am not yet sold:

    1.) EJBS do transactions. Is this really true? What I mean is that the more I read about this the more it sounds like EJB transactions are really just wrapped JDBC transactions. For example, will EJBs automatically meet the ACID test if I am reading and writing data to a file (through a helper class, since I am sure EJBs will not let me write to a file directly). Somehow I doubt it. EJB transactions are just a proxy for JDBC transactions it seems. Ok, so EJB intercepts a call to a method and calls

    conn.setAutoCommit(false);
    // call my method
    conn.commit();
    // if there was an exception
    conn.rollback();

    on my behalf. Thanks I guess. Is there more to it than this? If there is, could someone explain to me how code that doesn't know what I am doing can automatically support transactions? An example (say with file IO through a helper object) would be nice ;-) This one has had be baffled for a long time.

    2.) EJBs will persist certain type of beans automatically. How does this persistence work exactly and does anyone use this in real life? I have this feeling that the app server essentially creates the tables however it likes and persists the data there. This might be useful if I didn't care how the data was persisted, but chances are I have a specific database table or tables in mind that fit into some larger picture. Often the tables come first and the data is already there. Also I write database persistance objects all the time and I don't find it that difficult. Am I missing something?

    3.) Scalability and Clustering. Ok I guess there is some value here. Has anyone out there in the real world used clustering out of curiosity? Somehow I feel that there are very few. Other than that, scalability just means threads. Whenever I need something that is 'truely' scalable (i.e. multiple machines) I write it as a servlet (how I pass parameters to and from the servlet is another story, but it is not difficult to imagine). If this sounds hokey then ask yourself how web services are implemented ;-) So far I have not had a problem doing this and it scales very well. It is trivial to test (I can use a browser to unit test). I guess I could understand the value the app server doing the threading for me (just like occurs now with the servlets), but I would need to know what significant advantage it would have. The servlet approach is oftly easy to do and like I said, unit testing is a dream.

    4.) Failover or whatever it is called. What does this mean exactly? An example would be nice.

    So I guess after writing this all out I do see some value, but I also have this gut feeling that most people out there are using EJBs as an inefficient replacement to regular Java classes, because they feel like they 'should' use EJBs. I don't want to fit into the straightjacket of EJBs unless there are some darn good reasons to do so. (Plus there appears to be some good reasons not to use EJBs from the constant flak I hear about EJB performance).

    Thanks to all who write. As you can tell I am currently biased away from EJBs from my reading to date, but I am willing to embrace them. I just don't understand what they do or how they work well enough yet to convince myself. Plus I am ever wary that it is quite possible the emperor does indeed have no clothes and not that I can not see them because of my lack of intelligence (although that is quite possible too ;-)

    Cheers.

    Threaded Messages (10)

  2. Why EJB? (no really ... why?)[ Go to top ]

    _
  3. Why EJB? (no really ... why?)[ Go to top ]

    Anick

    The reality is of course that many other people have asked the same sort of questions and seem to be getting along just fine writing J2EE without EJB (see recent JDJ article). For my part, when my former employer so kindly gave me time off this summer (let me go etc.) I spent a great deal of time writing an application using tomcat, JSP Struts and EJBs with JBoss.

    I personally found that the resulting application had an architecture that I could be really comfortable with. I thought it was great. On the other hand there is no way that I could have justified the programming effort required to any customer or manager… I think we in the Java community have lost the plot here with some of these great ideas.

    Quentin
  4. Why EJB? (no really ... why?)[ Go to top ]

    I'll take a look for the JDJ article thanks. It sounds like there are definitely a few developer camps on the EJB versus non-EJB front. Guess I will avoid it for now.
  5. Why EJB? (no really ... why?)[ Go to top ]

    I think EJB is an overkill of ~80% of the web-based projects out there. However, just to set the record straight, I want to comment about some of the points Anick made:

    1. EJB is a spec. It doesn't do anything. It mandates things that App servers should do. App servers do some of these things regardless of EJB, EJB just packs them up in a way that lets you use them portably. Here are transaction related issues that EJB provides:
    - A transaction manager. Transaction managers manage transactions that may span more that one server (in a cluster), and may access more than one resource (e.g, DB and messaging system in one transaction). This is not provided directly by the resource specific interfaces (e.g, Connection.commit/rollback() ). The transactionallity itself is provided by a resource, not by the manager. EJB does not mandate which resources are available to the bean, so unless you have a Connector for files, file access won't be transactional (btw - you can't access files from EJB at all. Moving the code into a helper is a funny "solution" many people use. It doesn't change anything, and it's still not allowed... why would App sevrers care if you run your code directly in the bean class or a helper?).
    - Transaction aware caches. The EJB server maintains caches in the form of CMP and BMP entity beans. The server makes sure these caches properly obey transactional semantics, which is hard to do by hand. There are many specifics to take care of (one example is that before executing a finder you have to store the cache of all the related entities that were accessed in this transaction, or otherwise make sure the query returns updated results based on the cached values, not the DB ones).
    - Declarative transactions. IMHO, 90% of the transaction work in EJB should be done using declarative transaction. This not only takes the load off the developer, it also helps create reusable code which is independent of particular transaction settings. In specific, if you want to change your transaction settings you don't have to rebuild (maybe not even redeploy).

    2) The persistence scheme a specific App server uses is vendor-specific, but many have flexible schemes that allow you to map beans into existing tables. I don't have any figures, but I think atleast 50% of all entity beans are CMP. EJB2.0 really improves CMP support, and right now I can see allmost no reason not to use CMP except for rare cases (special data types, complex structures that require special types of SQL queries).
    Besides from the fact that writing data access object for DBs is time consuming and error prone, there is also a big chance that the EJB server will do a better job than you in caching this data. The EJB server can wrap operations from multiple threads into bulk updates and perform other optimizations which will be very hard to do by hand.

    3. I've used EJBs with clusters :) And I know for a fact many other people have used them as well. Actually, I would say having a requirement (or a future requirement) for a cluster is a pre-requisite for using EJB. The EJB server can handle many issues concerning a cluster that would be hard for you to do by hand. Take a read-only cache for example. Many App server implement it using cluster-wide invalidation messages. Doing the same yourself it quite time-consuming (I ought to know, I've done it once).

    4. For example, when one node of the cluster fails the EB is automatically reconstituted in another node and calls are automatically redirected to it. Again, you can do it yourself, but implementing a truely robust solution is difficuilt - and you should only use EJB is you need a robust solution.

    There are other advantages to EJB, but if I commented on all of them this post would become quite a novel :)
    To summarize, I think EJB has it's own advantages, but it is massively overused and there's a lot of buzz around it. Of course, everything is relative. The amount of unjustified buzz around web services makes EJB look like a perfect, completely overlooked solution... heh

    Gal
  6. Why EJB? (no really ... why?)[ Go to top ]

    Thanks Gal.

    Informative. So it sounds like there is a lot of variability between app servers. Maybe one of the reasons I was always left unsatisfied with what I have read is that it was generic, and to get to the details one must look at a specific application server. In this case then I guess the 'portability' of code between different app servers might not be as great as I first thought.

    Transactions:
    So to make stuff (file access, database access, etc) transactional, you would need to implement a Connector interface? I had not heard of this, but it makes a lot of sense. The Connector will contain the necessary start, commit, roll-back methods and the Transaction manager will automatically call these methods. Ok, that makes sense. The transaction manager just creates a proxy object then that wraps my object and call the necessary transaction methods.

    Persistance:
    Sounds vendor specific, which is bad, but perhaps more flexible than I first thought, which is good.

    Clusters:
    Ok.

    Failover:
    I think the failover aspect of clustering would be the hardest to do.

    So I think I am starting to see the picture, thanks. There is a project that I am going to be working on that will be using a full fledged application server and I can see now a use for EJBs for a couple of the objects to take advantage of CMP and transactions. Assuming of course that the vendor specific CMP will be flexible enough to map to the existing tables (man I hope so). Also I am interested in this Connector interface now. There is a non standard database (no JDBC) that supports transactions, so maybe I could write a Connector implementation. I'm liking that idea.

    It is ironic because before I could see a use for Session beans, but not Entity beans, but now I see a use for Entity beans but little use for Session beans. Funny ;-) Of course I still don't fully understand either, but it is coming.

    Cheers,

    Anick
  7. Why EJB? (no really ... why?)[ Go to top ]

    Anick

    There's a whole thread on this subject at

    https://www.theserverside.com/home/thread.jsp?thread_id=10603

    which is worth a quick scan. There's a post from “Paul Done? that describes the circumstances when he considers it appropriate to use EJBs, that I found educational.

    Regards

    Quentin
  8. Why EJB? (no really ... why?)[ Go to top ]

    Hi again.

    I have one more point to clarify. You don't have to implement the Connector interface for DBs. It is provided automatically. The Connector architecture is a way for data-source providers to enable EJB components (and J2EE components in general) to access them. Connectors handle not only transactions, but also some aspects of resource pooling, thread management, etc. I think it is very unlikely that you will find yourself implementing a Connector. It is a very complex architecture, and I wouldn't get in to it unless I absolutely had to. For example, the transaction interface is not as simple as you put it. It implement X/Open XA standards, handles heuristic commits, forgets, recovers, and a bunch of other tricky stuff :)
    Luckily, DB and JMS connections are automatically supported, and many system vendors are now including Connector drivers with their products.

    Gal
  9. Why EJB? (no really ... why?)[ Go to top ]

    I will still take a look at implementing a Connector. The DB I need to use supports transactions already, but it is not relational and there is no JDBC driver or anything like that for it (using a proprietary protocol). Perhaps implementing a Connector is extremely difficult, but I don't see why it should be when the underlying resource already handles most issues. The Connector 'should' be nothing more than 'glue'.
  10. Why EJB? (no really ... why?)[ Go to top ]

    I know you didn't mean to implement the actual transactions, but I still think it's would be an extremely large amount of work to implement a connector. The connector architecture spec is about 200 pages, and it massively uses the X/Open DTP spec. I think just reading these two would take months, not to mention understanding them to the degree required to implement a Connector. Just so you know what you're getting in to, Connectors handle connection management, transaction management, security and CCI.
    Anyway, good luck.

    Gal
  11. Why EJB? (no really ... why?)[ Go to top ]

    Sigh ...

    Why do these things always have to be so difficult. I swear there is no reason why it has to be this difficult (reference 200 page spec for connector architecture).

    I have written an OLE DB driver before, so I'm confident that I 'could' write a connector implementation, but there is no way that it would be worth my time. Fine. Screw EJB for this project then. That decides it ;-)

    Cheers.