J2EE without Enterprise Java Beans?


News: J2EE without Enterprise Java Beans?

  1. J2EE without Enterprise Java Beans? (42 messages)

    A recent article in Java Developers Journal provides some interesting reflection on why EJB has become so synonymous with J2EE. "Yes, there are good and valid uses for EJBs, but there are many more projects for which servlets/JSP (and JDBC) are more than sufficient."

    Read J2EE without EJBs?.

    Threaded Messages (42)

  2. I agree. sometimes EJB is like swatting a fly with a buick.
    But I do like'em. Although I couldn't get this article up.

  3. J2EE without Enterprise Java Beans?[ Go to top ]

    click on "print article" and surprisingly you will be able to see the whole article.
  4. I think the reason so much money is being wasted is that the EJB spec has taken such a long time to mature. The idea is to get to a point where the spec is reasonably powerful and stable, and it takes time to get there.
  5. J2EE without Enterprise Java Beans?[ Go to top ]

    I completely disagree with the article. Firstly, not all EJB containers are expensive. What about Orion ($1500 per server) or JBoss (open source, free)?

    Secondly, unless a project is quite simple, EJB's <b>simplify</b>, not complicate, the development task. Transparent transaction demarcation and thread management are the main advantages.

    Using EJB also promotes good design--separation of presentation from business logic etc.

  6. J2EE without Enterprise Java Beans?[ Go to top ]

    Someday I'll write a paper entitled "The Myth of Transparent Transaction Demarcation". Having EJB's transactionally aware certainly makes transaction management far easier, and may even allow you to avoid writing code for that purpose. OTOH, it doesn't mean that you don't need to be 100% aware of transaction boundaries and plan for them.

    But I digress....

    The article's point, I think, is that you can have a J2EE system without EJB. And that, for some applications, EJB's may not be the "right" choice. BEA's presentation on EJB makes the same point: use EJB's where you require one or more of a laundry list of items including remote access, security, and/or transaction management. There are real-world applications that are not trivial where the right model for scalability is multiple instances of a non-clustered, non-remote app environment with no remote calls aside from the database. Using an EJB in such an environment may not make sense.

    Dave Lindeman

  7. I think I disagree with one of the points:
    "Sun has contributed to the perception that J2EE requires
    EJBs through the J2EE licensing program and by not offering
    a separate certification program for servlets/JSP. The only
    way for a vendor to achieve Sun certification for a
    servlet/JSP implementation is by becoming a J2EE licensee".

    Given that SonicMQ is certified J2EE compliant, and it is really only a JMS provider, how did they get around it? They got around it by shipping the J2EE reference implementation to satisfy the rest of the requirements required for certification. (see here for that new article). So, I dont think that there is no space for servlet engine providers that want to be stamped J2EE compliant.

    With regard to the rest of the article:
    Of course if your WEB application (not all apps are web apps) doesnt require complex transactions and it is read-mostly, then why not use just Servlets and JDBC. HOWEVER, if you start hearing the f-word (framework) around the place and people wanting to develop an 'f' then I think alarm bells need to ring.

    The main trap I see with JSP/Servlet/JDBC designs is there is too much of a tendancy to manage state based on the assumption that there is only one JVM (which can limit scalability and availability). While EJB doesnt necessarily eliminate this - I think it does make it harder to make that mistake because EJB makes it very explicit about where you can and cant (and therefore, should) store state.

    I think that Ed's article (here) is the best I have seen with regard to EJB or no EJB.

    I guess that ones opinions are shaped by experiences. In my experiences I have seen a whole lot more money wasted by people developing stuff that you can buy than the price delta between a Servlet Engine and Full-Appserver. I still maintain that the $1B that was supposedly overspent on appservers is chicken-feed compared to the (who knows how much) is wasted on ill-conceived projects and in-house development of middleware.

    As for:
    "And the next time someone asks, "Is your project based on
    J2EE?" smile as you reply, "Yes, but we're not using EJBs.""

    Only smile if you havent already blown the appserver saving on development and testing time.

  8. As an interesting side note to this discussion, I wanted to share an insight I gained from attending a Microsoft User's Group meeting about 2 years back. The topic of the seminar was titled something like, "Are Application Servers Evil?", and the title piqued my interest. Anyway, it was a lively discussion of app server internals but the main point was to raise the question of exactly what App servers, and more specifically EJB containers, do for you. On the transaction side, an EJB container relieves you of the necessity of calling beginTransaction() and endTransaction(). That's about it. The trade off is the overhead involved with the Interceptors/Proxies that the container has to set up for every managed transaction. This overhead is significant. I would say that with enough skill and attention to things like transactions and multi-threading, JSPs and Servlets are sufficient. On the other hand, when inheriting code of questionable quality, it's always nice to have a framework like EJB to enforce certain default behavoir. For my personal development, I'm always going to prefer the least bulky technology that gives me the most control and maximizes speed and elegance of design.
  9. J2EE without Enterprise Java Beans?[ Go to top ]

    I agree, in JDBC you can manage transactions manually with:


    Underneath the covers any RDBMS will manage concurrrency and transactions. After all, that is the enitre point of RDBMS and ACID anyway.

    It has always seemed a little weird to me that we have an entire extra tier to do something that the database does implicitly, and even without an App Server the database will continue to ensure ACID is enforced.

    The Microsoft COM+ (now '.Net Managed Component') model has always been to rely strongly on the database server itself for transaction management and concurrency. And remeber despite what the J2EE world want you to think, MS and MTS were there first and have much more experience than any other vendor with component-based middle tier systems (MS dropped the IMDB (in-memory database) from Component Services in W2k because it wouldn't scale, for example). The middle tier is great for object instance pooling and caching, and can really help scalability in that sense.

    One of my favourite architecture models is JSP, Servlets and Stateless Session EJBs...seems to be the best of all worlds.

  10. <quote>
    On the transaction side, an EJB container relieves you of the necessity of calling beginTransaction() and endTransaction(). That's about it.

    OK, so what about the other sides. Transaction management is just a small part of what an EJB container offers. What about security management, thread, object and connection management (pooling, caching), persistence management, environment management (naming, properties), messaging management, load-balancing and fail-over?

    Once you realize that you will have to do all this by yourself when building a non-trivial enterprise app without an AppServer, then you will perhaps read the EJB spec and reexamine your position.
  11. Yes. I do agree with this. First of all, I didn't understand the logic of attaching the database related information with EJBs through the Entity Beans. Not only having EJBs is a waste, it is also complex. The purpose of making enterprise applications is defeated when you have EJBs. Not only the EJBs, the EJB containers also make things difficult. The openness of Java is again defeated by the EJBs as it has to depend on the EJB vendors, who have their specific deployment rules. So, what was thought as open-source code has again gone back to proprietory methods.

    I still feel, if one can write good code, you can still manage with Servlets, JSPs and JDBC.
  12. I am sick and tired to see developers spitting in the soup.
    Understand me.
    EJB makes possible to see in a not so far future a world where a part of developers will work on Objects. Objects.
    With a good framework and some (not too much really) hard work it does not take longer to develop an EJB application than a servlet application.
    You want to go backward and forget EJB because they are they are too difficult to apprehend? Shame on you.
    I do believe in world where actual Linux/PHP developers will take their "courage à deux mains" and begin to learn J2EE. A World where Objects will rule (and no more JDBC, Pooling,...). Where you will not have to search your way in a long labyrinth to find the exit.
    I hope this highway can be construct by Java developers working hands in hands.

    Reflection about breaking. Bullshit.
    Reflection about evolving/learning/building. Applause.

    TSS is building something. Respect.

    EJB is bad ? OK where? what to do? Pricing? Go JBoss. Performance/missing components? Build it.
    You don't want, you don't have the energy, OK, then choose JSP but with the correct idea in mind : go and see EJB tomorrow, JMS the week after, ...
    J2EE is the Bazaard (meaning will not survive with open source)
    You don't like that, go for the Cathedral.

    (sorry I am not politically correct, I don't want to insult anybody, I write from heart,feelings. I may seem to have a big ego but be sure I can LOL of my own message. This message does build anything of course, I go back building right now)
  13. Finally, we must not overlook the role of Java

    >>programmers, developers, and engineers in forming the
    >>equation that J2EE equals EJB. We (yes, I put myself
    >>in this group) naturally want to work with the latest,
    >>hottest, coolest, biggest, sexiest, most important
    >>new technologies. We sometimes overspecify and
    >>overdesign, and say things like, "Sure, we don't have a
    >>requirement for that now, but..." And we always have an
    >>eye on what will look good on our résumés.

    We built a prototype for a Web enabled workflow management system last year. We followed the approach presented in "Core Servlets and JavaServer Pages", i.e. the Servlet/JSP/JDBC approach. While it allowed us to very rapidely develop the application, the only thing we implemented to save system resources was connection pooling.
    Our ____WEB____ server was Resin.
    The fact is that we didn't know about all the possibility a full blown ____APPLICATION___ server offers (transactions, concurrency, persistence, caching, clustering)
    I know the J2EE specification puts both the web and EJB container in the application server, but I believe this is done to make collocation optimizations possible like BEA WebLogic, IBM WebSphere etc. do in a homogenous cluster.
    Can somebody give me other arguments why one has taken out the web server from the J2EE architecture?

    To continue about the prototype: YES we are very happy about the project results, because we could focus on functional requirements, BUT we are very aware of the fact that our application DOES NOT SCALE.
    From the other side, we built our prototype on time, within budget and as we built our model using regular JavaBeans, we believe that the prototype can be reengineered to a more robust and scalable application.

    Would EJB have been overkill for our project? I think it would, if the prototype were to be thrown away after evaluation. Also, it would have complicated development and would have distracted our attention from the functinal requirements. However, I recently tried out the TogetherSoft ControlCenter IDE and must say that such tools make EJB development almost as simple as regular JavaBeans development.

  14. I agree with some of the postings before mine (or one? Not sure):
    Why does everyone state EJB is overkill, difficult etc.?????
    I cannot see this in any way, sorry.

    Someone please point out what exactly makes developing an EJB model more difficult than a JavaBean/"normal" Classes model (provided they implement the same functionality ;-).


  15. J2EE without Enterprise Java Beans?[ Go to top ]

    I think there is a place for EJBs in J2EE based applications but the decision to use them should be taken on a case by case basis.

    First of all, what is the experience of the development team? If they are fairly new to J2EE then they're going to have a hard enough time getting their heads around WARs, JSPs, Servlets, JDBC and a decent MVC framework (eg. Struts). In my experience EJBs do not make things easier for developers of smallish/non-complex applications (you need to create remote interfaces, separate implementations, correctly populate deployment descriptors, learn the EJB method lifecycle, etc, etc). EJBs are more beneficial for larger scale future-proof applications which require a logically separated and object-oriented architecture (following a proper analysis/design phase). Many times a team can just create classes in regular jars for business logic and data persistence and include these in the web-inf/lib of a the front-end WAR (in such cases naming/properties and security management can invariably be controlled at the WAR deployment descriptor level).

    Where the application is more complex I always use the following criteria to determine whether to use EJBs (ie. if at least one of these criteria is met)....
     - Is there a need for remote access of the business logic (eg. does Web Tier and EJB Tier need to be on separate tiers, or is the business logic going to be shared amongst more than one other front-end application)?
     - Is there a need for complex transactions or transactions which span multiple back end information systems (ie. distributed transactions)?
     - Does the development team prefer CMP as opposed to using design patterns such as DAOs and writing the JDBC manually (if the EJB container is pre-2.0 EJB compliant then I don't even consider this point 'cos CMP isn't up to the job)? Also the team may decide to use a different technology for this (eg. JDO).

    If the business logic is only to be used by one front end application, I usually prefer to house the Web Tier and EJB Tier in the same application running in the same JVM and then scale the application by clustering these physically combined applications/boxes with a HTTP hardware load balancer in front. For me this is as much about stability as it is performance. I know decent App Servers provide good failover capabilities (eg. state replication, intelligent remote proxies, etc) which help provide clustering at the EJB level (eg. EJB farms). However these systems still aren't as stable and there is still potential for application state to become inconsistent (see Tyler Jewell's draft chapter for the new serverside EJB book). As the number of physical entities in a distributed application increases, so does the overall instability (even when asynchronous messaging is used correctly). Resist designing overtly distributed architectures unless there really is a compelling case for it.

    One of previous messages advocated controlling transaction purely in JDBC using commit(), rollback(), etc. This may be fine if you only have to talk to one database. However add another database to that transaction (or worse still other information systems, via JCA) and you won't be able to. So again this decision would have to be made be a case by case basic and how extensible the application needs to be for the future.
  16. J2EE without Enterprise Java Beans?[ Go to top ]

    Thank you for bringing together all the pieces!
    I couldn't have said it as structured as you did.
  17. J2EE without Enterprise Java Beans?[ Go to top ]

    Exactly! Well said! I notice that most people worry about transactions with a RDBMS, but what about other systems? Many times you have to perform distributed transactions with some RDBMSs, an LDAP, a mainframe... A simple servlet with Connection.begin() and Connection.commit() won't do all the job.
  18. Cheer, yes there are good alternatives to Entity Beans! Please have a look at the Cameleon Open Source project at http://www.must.de/Jacompe.htm to see how simple and flexible database applications may be developed.

    Well, I realy hated to code getters and setters and bean and interfaces and descriptors for each entity . . .
  19. You said: "Well, I realy hated to code getters and setters and bean and interfaces and descriptors for each entity . . ."

    Two years ago (one month after EJB 1.1 spec was out), all I had to do was select a table and columns, provide names for the EJB and its properties and everything else was done for me, including J2EE generic and Weblogic-specific deployment descriptors.

    It's not our fault if you chose to use emacs instead of a tool designed to the task ;-)

    People's frustration with EJB is usually based on ignorance (which is easily forgivable since the spec is _so_ poorly designed and written) and the fact that emacs-style development that many Java developers are used to is initially difficult with EJB because of the number of pieces that must be created and must be in sync. As far as the typical IDEs go e.g. Borland, they did EJB etc. as an after-thought; they were all AWT-oriented drag and drop GUI designers with poorly thought out glued on tools for J2EE.


  20. Hey i am very much surprised to see about the word i hate to code getter and setter methods when Visual Age for Java is providing many facilities to generate accesors for each and every field. If you VAJ or JBuilder as IDE, surely you will love to code Entity Beans. Yupe i agree one thing regarding Entity beans is Writing and maintaining BMP Entity is difficult one but not with CMP. CMP are much easy to code and maintain, the main advandage of this is many application databases are in Oracle and very easy to produce CMP entity beans. Using schema also we can generate the beans directly.
    - Raj
  21. About hating getters and setters[ Go to top ]

    Raj and Joni,

    Concerning "Hey i am very much surprised to see about the word i hate to code getter and setter methods when Visual Age for Java is providing many facilities to generate accesors for each and every field.":

    Thanks for all informations about tools to generate getter and setter methods. Unfortunately I do not influence the decisions about tools an code style too much - when I work as freelancer. When I develop my own products, it's different.

    First: Would you agree if I say those generations should be part of the Java specifications - not being part of an IDE? Especially the way how attributes are defined should be standardized!

    Second: After generating getters and setters you still have to USE them! Why should I manually code "get entity attribute value and put in JSP / Swing / whatever" and after Ok again code "put edited values back to entity bean"?

    Indeed, the Cameleon style (http://www.must.de/cameleon.html) provides a higher abstraction level. And - it's not a decision against EntityBeans, just an independence layer.

  22. Say goodbye to tedious coding[ Go to top ]


    Hand coding getters/setters, descriptors, and keeping classes and interfaces in synch is something that J2EE tools excel at. And they will only get better with time.

    Everyone is familiar with the big boys as far as tools go. If you have a chance, though, try out www.roamingmedia.com/roamingstudio.htm and see just how painless developing and packaging EJBs can be.

  23. "Well, I realy hated to code getters and setters and bean and interfaces and descriptors for each entity . . . "

    Well, I think you should evaluate some tools which can really speed up/enhance your EJB development. Try for instance Ant + EJBDoclet and you no longer have to maintain so many files.

    If you use emacs you can write an elisp function which can add attributes and generate getters/setters automatically. The following piece of code adds an attribute. E.g:
    M-x java-add-attribute Object foo

    (defun java-add-attribute ()
      "Adds and attribute and get/set method to it"

      (setq attribute-type (completing-read "attribute type: " nil nil nil nil))
      (setq attribute-name (completing-read "attribute name: " nil nil nil nil))
      (insert "private " attribute-type " "attribute-name ";")

      (insert "/**")(newline)
      (insert "* Get method for " attribute-name)(indent-according-to-mode)(newline)
      (insert "* @return " (upcase-initials attribute-name))(indent-according-to-mode)(newline)
      (insert "*/")(indent-according-to-mode)(newline-and-indent)
      (insert "public " attribute-type " get"
    (upcase-initials attribute-name) "() {")(newline-and-indent)
      (insert "return this." attribute-name ";") (newline-and-indent)
      (insert "}") (indent-according-to-mode)(newline-and-indent)

      (insert "/**")(newline)
      (insert "* Set method for " attribute-name)(indent-according-to-mode)(newline)
      (insert "* @param " attribute-name)(indent-according-to-mode)(newline)
      (insert "*/")(indent-according-to-mode)(newline-and-indent)
      (insert "public void set" (upcase-initials attribute-name) "(" attribute-type " "
    attribute-name ") {")(newline-and-indent)
      (insert "this." attribute-name " = " attribute-name ";") (newline-and-indent)
      (insert "}") (indent-according-to-mode)(newline-and-indent)
  24. Folks, please change the URL for this to:


    The current URL is mistakenly set to view only the last page.

  25. J2EE without Enterprise Java Beans?[ Go to top ]

    EJBs are primary part of J2EE, and we can consider it as main base for J2EE. If any application wants to maintain Transactions very clearly Entity Beans should be present. More over best way of implementing MVC arch. has to be with EJBs in the Arch. Even though JSP/Servlet are working well, EJBs should be there.
  26. J2EE without Enterprise Java Beans?[ Go to top ]

    Transactions, thread safe, pooling, performance....blah blah blah.

    Forget all these things. Say u dont want to implement using an exisiting frame work of complete J2EE then why use JSP/Servlets. PHP can do it for you, CGI can do it for you. After all 1/2 of the websites in the world use these technology.

    If you have come to J2EE looking for something better, it starts with EJB. JSP/Servlets are as good as ASP or PHP or Cold Fusion. We need more. I agree, it has a steep learning curve. But once u have done learning it, there is nothing like it.

    Its easier to manage sessions, leverage EJB using patterns, or even quickly develop and deploy it. I do not use any tools other than a notepad. (I use a standard batch file and voila compiles, creates JARS and deploys). I made a list of best practices for design, develop and deploy. I work with JBoss2.3.x and Tomcat4.0

    It just feels like small projects are gettting easier than ever, big projects are getting easier than before too. I am a lazy programmer ;) and I will do only easy things, so should you. I use EJB because I feel I am doing less and geting more done. If you feel, the other way...I think thats fine too. Just remember, if you had worked with PHP or ASP before, maybe it was no use taking the trouble to cross the bridge over to J2EE.

  27. J2EE without Enterprise Java Beans?[ Go to top ]

    what if I don't nee distributed transactions? And what if I need good OO design for my application. What if I want to use O-R mapping. Can I still use ASP/PHP?
    What prevents me from scaling my application if I don't use EJB instead do clustering at the servlet container level.
  28. J2EE without Enterprise Java Beans?[ Go to top ]

    Most applications in the software are developed for Banking and Financial purpose. At these point times the applications need transactions and other things like security etc. At these times we can see the importance of J2EE(EJBs). CGI can so the things like transactions and other things but what about the performance and memory. CGI used to create one thread for each transaction, this will be headache regarding performance. Now a days we are having better implemenatation with high performance when compared to CGI. Surely we can not expect J2EE with without EJBs.

  29. Interesting that this article is by Vince Bonfanti. Who was and may still be a player at new-atlanta they make a servlet runner called servlet-exec and a type-4 jdbc driver for mssql. They where teamed with a ejb server manufacturer ( I forget the name ) but split back to thiere own company about a year ago.

    Any way this article does speak to their market.

    As for j2ee with servers offering optimizations for local java beans ( If it's in the same vm dont rmi for gods sake ) and nested containers they are becoming more like jade ( http://sharon.cselt.it/projects/jade/ ) all the time.

    Even though ejb offers a lot in transactions. I find the majority of the time treating failures as another production in conjunction with an external transaction manager is more appropriate. Users are a lot more happy just fixing what needs to be fixed rather than statring from square 1.

  30. I strongly disagree with this article.

    EJB's are transactional components which takes care about Databases and provide standard architecture to Java products.

    I implemented Orion servers for more than 6 customers with 30-40 EJB's.It is cheap and performs well.So I dont think, Application servers are costly.

    Does the Author want us to go back to old(2 yrs back) JDBC style?

  31. J2EE without Enterprise Java Beans?[ Go to top ]

    I couldn't pick one specific article to respond to but I'll offer my take on the use of EJB when building an application. Actually this is more a commentary on J2EE development as a whole which includes EJB.

    If you're building a small application that only uses a single data source and isn't expected to have to scale greatly over the next few years then utilizing most of the J2EE technologies other than JSP/Servlets and JDBC is probably overkill and worthless to you. Don't use a sledgehammer to kill a fly...


    If you're building a fairly complex enterprise application that could conceivably grow very large and very complex, involve multiple data sources then J2EE (including EJB) is probably right for your project.

    I've seen people bash the overhead involved in container managed transactions, threads, etc.. and say that at a Microsoft show they told you why app servers are bad because they inject overhead for the sake of safety. When you're working on a smaller site and you're the only developer then yeah, you know that you've done the transaction management yourself but when you're working on a large project you can't assume that everyone knows what they're doing or wasn't lazy and forgot some transactioning code somewhere else. It's a lot easier to cluster the servers and buy more of them than it is to try and find little bugs that creep up occasionally because someone forgot to abort a transaction after a weird error path that doesn't happen that often...and it does happen.

    Just because you're using an application server doesn't mean you have to use every bit of technology it provides. We've been using WebLogic for a couple of years now and we're just now going to use JMS because a problem came up that would best be solved by what JMS offers us. Sure I could have used it before but it wouldn't have made sense. EJB is no different. Don't take a technology and try to find a problem to solve with it. Solve the problem with the technology that makes the most sense for *your* project and its requirements.

    And to those that say the spec is poorly written I challenge you to come up with one that is better. Just because you can't see how others might use the services it provides doesn't mean its bad....it just means that part of the spec or the spec itself may not be the best solution for your project. If there's a particular part you'd like to see improved then get involved by all means! Contribute to the spec rather than just complaining and moaning about it.
  32.     I agree that EJBs are overkill in the case of a trivial application. But, how do I properly implement any application of moderate size and scope? Let's follow an implementation where we assume that EJBs are overkill. After deciding to use Servlets/JSP/Swing or whatever on the front and JDBC access on the back, I'll need to define a service framework (using only my own Java classes). This will assure all developers are defining business logic in a consistent manner and are not repeating plumbing code such as transaction bounding, provider based access, design patterns such as seperation of interface and implementation, database connection pooling, thread pooling and concurrent business logic handling, and security. It will take significant effort to implement distributed access and business logic scalability or load balancing. I might be able to make up for this to some extent using my web server, assuming I will use only JSPs and Servlets, never needing a Swing, WAP or whatever type interface that may not scale. I've just created something like an EJB environment, except that when I compare it to existing app servers that implement EJB, mine is non-standards based and does not have nearly the amount of testing or support. It also cost my client alot of money and time that might have been better spent on developing business solutions.
        Not all of the services described will be necessary for a given project, but why restrict the development team to anything less? Ultimately, the complication of EJBs comes from the problem they are trying to solve, not the solution.
  33. J2EE without Enterprise Java Beans?[ Go to top ]

    I like and use ejb ( less so than at first blush ) and hope jca/cci developers to what it should be.
    But I strongly agree with this article ( It's not gospel though) ...
    Actually medium to large projects are rarely monolithic.
    There are a lot of frameworks , SQL clients and standardized file directory structures which already exist and are standard and well tested by the users written in many languages and well proven some more complex than ejb some very light weight. Although sql is not standard , does more than query and isn't a fully defined language more applications use it for a common white board than use rmi or ejb wrapped session state. Why limit your developers to technologies and practices that are already being used in a heterogeneous environment? .... Because the customer wants you to develop what is there and what has they are comfortable with. Give the customer what they want but make sure you leave them more than what they already have not a different version that what they already bought.
  34. "After deciding to use Servlets/JSP/Swing or whatever on the front and JDBC access on the back, I'll need to define a service framework (using only my own Java classes)."

    Or you could use Struts, which is free.

    "This will assure all developers are defining business logic in a consistent manner and are not repeating plumbing code such as transaction bounding, provider based access, design patterns such as seperation of interface and implementation, database connection pooling, thread pooling and concurrent business logic handling, and security."

    Most web apps don't need a full-blown security model. A simple login system is all that the average commerce site requires. Connection pooling is provided by most servlet environments and certainly doesn't require EJB. Ditto with threads. Design patterns are certainly no simpler with EJB.

    "It will take significant effort to implement distributed access and business logic scalability or load balancing."

    Or you could just store your state in a central database and use a basic HTTP load-balancer.

    "I might be able to make up for this to some extent using my web server, assuming I will use only JSPs and Servlets, never needing a Swing, WAP or whatever type interface that may not scale."

    EJB is not needed to implement RMI, and nothing is stopping you from using a load-balanced RMI cluster. Use the fancy app server if you like, but you still don't need EJB. JavaBeans will be fine.

    It's not clear why you're so insistent on needing EJB. Most of the biggest sites out there don't use them, so clearly they aren't required to make a scalable site.

    Incidentally, IBM, who know something about Java and EJB, tell their consultants to avoid EJB if at all possible. They basically say that unless you need object-level security or transactions across multiple data sources you should stick to JavaBeans. They say this because they did performance tests and found that the an app coded with EJB was massively slower than the same thing with lighter weight JavaBeans.
  35. J2EE without Enterprise Java Beans?[ Go to top ]

    I prefer EJB generally over JSP because I cannot see a good way of having one component (the EJB on the app server) and different clients (HTML, XML, Swing) within a pure JSP environment.

  36. J2EE without Enterprise Java Beans?[ Go to top ]

    "I prefer EJB generally over JSP because I cannot see a good way of having one component (the EJB on the app server) and different clients (HTML, XML, Swing) within a pure JSP environment."

    Use RMI from Swing clients. Output XML from your templating system. It's not as if these things were hard.
  37. About IBM advises, I think that till now, they were a little bit twisted : actually, it's pretty sure that with Websphere before v4.0, EJBs performances were really not that good...
    Let's see what they are going to say now they got a real J2EE App server (and may be also more developpers able to implement a good EJB-based architecture)
  38. While discussing the roles of EJBs I think its good to put up a question specifically about entity bean. "What is the role of entity beans in data centric applications? Where there are alot of joins and entity beans looks very costly in terms of resource usage". Previously the job done by one query will noe require call to serveral entity beans. What should we do? Should we design the db to make it look like more of objects than relational. Please do comment on this.
  39. It is not only a technical problem[ Go to top ]

    The high abstraction of EJB make it difficult to comprehend by some developers.

    I have seen how a project went deadly wrong from ground zero because developers missunderstood the EJB. And they could not find a way out because they were totally lost in it.

    The old combination of servlet and JDBC is more concrete and easier to "feel" what's going on. If an architecture based on it, It is easier for these developers to find ways to make it work.

    Some projects are not mission critical small applications, the design and code will never be reused again. The clients are happy to live with a working application for quite a while and not touch it. And it is not a big deal to redesign the whole system from scratch some years later.

    So the good old way at least has this reason to stay.

    Of course there are other roads other than EJBs to develop good systems. That is another story.
  40. It is not only a technical problem[ Go to top ]

    I have seen how a project went deadly wrong from ground

    >> zero because developers missunderstood the EJB. And they
    >> could not find a way out because they were totally lost
    >> in it.
    >> The old combination of servlet and JDBC is more concrete
    >> and easier to "feel" what's going on. If an architecture
    >> based on it, It is easier for these developers to find
    >> ways to make it work.

    At the end of the day, if any team of developers dont understand what they are doing, the project will never succeed. Regardless of which technology they are using.

    I dont think there is any excuse for working on an EJB project without understanding it. There are countless books and tutorials and training courses available.
    I kind of think that if the developer cant pick up Richard Monson-Haefel's O'Reilly book on EJB - and understand EJB by the end of it - then they are not the ideal person for the team. I honestly dont think it is that complicated. Even at first glance, I thought it was entirely intuitive, but I admit I did have some CORBA experience.

    Sure, if people are working with just java classes and JSP/Servlets and JDBC, they might have a more hands-on feeling about what they are writing - because they are writing ALL of it. Security, multi-threaded access, persistance, transactions.

    But I am sure if these same people cant understand the fundamentals of EJB then there is a good chance they might also naively code and design themselves into an application that can not scale, be unreliable and is likely to require loads more testing.

    With regards to testing and EJB - I will share an experience:
    I worked with a small team who were working on their first EJB application. They had never done any EJB development beforehand - but they had read a bit - and always had a few books and the EJB spec lying around.
    We didnt follow proper development procedure - and load testing was not done until very late in the project. The VERY FIRST time that the app was put under load - 500 simultaneous users (that probably equated to 1000's of real-time users - and it was a very complex financial application) - it ran without crashing, without hanging, without blowing up with loads of exceptions. The performance deteriorated - which you would expect on a single-proc desktop machine with 500M ram and a dozen other apps running - but it deteriorated gracefully.

    I have never, ever, ever seen that before. I have worked on 2-3 year old, supposedly mature products/projects where if you blasted the app with just 50 concurrent users, it would occasionally blow up. We ALWAYS used to find threading issues when working on existing code - always.

    So, EJB? If you need to build an even slightly complex, solid, lasting app (its not a throw-away) - and you have at least one or two guys on the project who *know* EJB (even if the others are less experienced developers - let alone experienced in EJB) then choose EJB.
    (if you dont have any experienced developers on the team - can the project - or re-staff. Anything else is a throwing up a prayer.)
    If you want to add new people to the team and have them get up to speed quickly (they dont have to learn any home-crafted "frameworks") then choose EJB.

  41. No one is going to say that EJB is bad technology. No one is going say that distributed transactions or security or clustering are bad. You can implement your website's business layer with EJBs and it will work/perform just fine.

    You could also do it with vanilla Java classes, and that will work too. You could even use ASP (gasp) and put all your business logic right in the page - some sites do.

    As architects and developers, we need to be sensitive to the requirements of the applications they are building. Business people care about functional requirements and to some extent performance. If we consistently make the decision to solve problems in a way that is unnecessarily complicated, we are building a case for some simpler technology, like ASP.

    I always ask myself "Would an naively designed ASP application take this long to implement, and perform acceptably with this user load." If the answer is yes, then it's time to simplify.

    - The use of clean business interfaces are priceless - EJB or not.
    - If your team can implement an app with EJBs faster, ignore this post (but most can't).
    - If you have a requirement to *****, then by all means meet that requirement, and use the right tool for the job.
    - Using EJBs *do* make you're app more flexible and prepared for the future - if you can afford it, supersize!
  42. J2EE without Enterprise Java Beans?[ Go to top ]

    So many points, so little time:

    To suggest that EJB reduce complexity is ludicrous...EJB creates a complex framework around business and data logic and I think the point that many people make is that unless you need the specific features provided by EJB (essentially distribution, security and scalability) then don't use them.

    A well designed JavaBean and plain-old-vanilla class framework can provide ease of maintenance and code-reuse at least the equivalent of an EJB tier, and possibly reduce complexity because you don't need Remote interfaces, Remote Home interfaces, Local interfaces, Local Home interfaces, Abstract Accessors, Dependent Value Objects, Business interface patterns, Session Facade patterns, Remote Value Object patterns...the list of architectural demands REQUIRED to get EJB working is endless.

    As we have seen from some of the responses here and elsewhere there is a misconception that EJB are a panacea to all development problems. Wrong. EJB often particular solutions to particular problems and if your system requirements fall within the domain of EJB than they are a godsend.

    Especially now with the new CMP 2.0 specification, configuring EJBs is a complicated and convulated process. Suddenly we have a query language in the Application Layer. I remain to be convinced that moving data access commands from a well-designed data tier to configuration files reduce complexity. It seems that all EJB-QL does is shift complexity from one layer to another.

  43. J2EE without Enterprise Java Beans?[ Go to top ]

    >> To suggest that EJB reduce complexity is ludicrous...
    I agree. EJB shifts complexity. It shifts it from the coder to the designer. However, you generally need less designers than coders.

    >> EJB creates a complex framework around business and data
    >> logic and I think the point that many people make is
    >> that unless you need the specific features provided by
    >> EJB (essentially distribution, security and scalability)
    Add "reliability" to the list...

    >> then don't use them.
    It goes without saying. If you dont have these problems - then you dont need this solution. However, most people DO have these problems. However, some *think* that they can solve them - by writing all the code themselves. Some people are good enough that they can. Most are not.