----- Original Message ----- From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: 24, 02, 2003 9:20 PM Subject: Re: JSP/JavaBean compared with EJB
Ok, all inline. > > 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 (http://www.jboss.org) is as expensive as Tomcat. Orion (http://www.orionserver.com) and Resin (http://www.caucho.com) are cheaper than Tomcat(unless the hardware you run them on top of is really inexpensive < 100 U$S, or your app doesn't handle an important load). Both of these containers are free for non-commercial applications, I think, and for commercial applications there's a fee, but since they're a lot faster(one order of magnitude average in the apps I've tested) than current Tomcat implementations, it's cost when compared with the hardware cost is marginal > > > > 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. There are a lot of free tools that aid you in this process, and you could also roll out your own. Depending on the methodology of work you use this will be either a burden or a bless. > > > > 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. Altough most EJB/table mappings are 1..1, this could be altered. It's not usual that mappings aren't 1..1. But at least you'll know if the underlying data structure has changed. It also depends on how you're using the table. To accommodate for a new field you have to add 2 methods anywhere in the EJB file and touch the constructors a little. I don't perceive this to be much more work than tracing SQL statements that need changing (and I presume the code is neatly arranged). If you own the tables, some EJB servers will generate as much SQL as they can(Orion does this with inserts, simple finders, even create the tables for you). This helps to develop quickly and eases initial deployment. Changes on the underlying data structure are bound to be as harmful regardless of the technology used. > > > > 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. Both apps will need a web.xml file placed correctly. Both will also need .jar files available to the web app. The extra steps are building of EJB jars (which can be reused in different applications, like a backend), and building the ear (simple even in complex applications). They're just zip files, so it's not extremely difficult to do, even automate. Use ant to automate the build of .jar, .war and .ear files. > > > > 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. This is because: A) You made a mistake. B) You didn't make a mistake (and your server vendor did, or Sun when writing the spec). On B, I can tell you that basically, this is one of the biggest flaws in the EJB spec. The gap, however, narrows on each release, and there are tools available to make the whole thing even more pleasant(like XDoclet, EJBDoclet, etc.). This is a problem with Servlet/JSP specs too, and the specs aren't carved in stone either(for instance, I recall that Tomcat didn't implement HTTPRequest.getPath() as per the spec; instead of fixing Tomcat "The golden reference", the spec was patched to match Tomcat's behavior, and this meant a lot of apps will break when moved from Tomcat to another JSP Engine working with the *same* Servlet/JSP spec). But this is THE major open flank on J2EE today. It's not a perfect world. > > > > 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? A JSP/JavaBean app isn't inherently n-Tiered(you'd have to do that yourself). That means that under heavy load & complex operation it's likely not to be able to scale as linealy as an n-Tiered app. N-Tiers allow you to redistribute load more efficiently, and also help reuse. Again, this may or may not be needed by your app. Before I get flamed over this, yes, I know RMI, and N-Tiers aren't exclusive of EJBs, and you can achieve it with JSP/JavaBeans, but you'd have to write a lot of the plumbing yourself. Mounting RMID is a lot worse than deploying an ear. Distributing load must be manually handled. And these implementations are bound to be less efficient except in a very few cases. > > > > 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"? Think about accessing and modifiying 8 or more tables. You'd have to write all the code serially, commit or rollback the transaction manually. Think about 20 or so similar operations: reuse could become more difficult. Then think about continuous improvement: you might need to add a simple insert before a lot of these operations, manually. Altough it's completely possible using JavaBeans, EJBs provide a cleaner, more object-oriented approach, since they're fully blown, transactional, secured business objects. When you add teams, and possibly changes in teams and requirements, the benefits are more clear. On top of all this, EJBs guarantee handling some "special" cases more effectively (like a server crashing, for instance). > > > > 8) Another advantage of EJB I heard was "security". My application > currently > > uses username and passwords to authenticate users. If the > user provide > > 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? Web pages show content. EJBs encapsulate business processes and business data. An EJB(like a JavaBean) may be used by something other than a Web page; an EJB(unlike a regular JavaBean) may be located anywhere, and it's security requirements may differ from the ones governing whether a web page must be displayed or not. > > > > Having said above, my questions are: > > > > Is there anything EJB can do but using just JSP/JavaBean > cannot? No, there's nothing you cannot do without EJBs that you can do with it. And that's not the point. The point is that there's a lot you will need to do when using just JSP/JavaBeans that you won't need to do when you use EJBs to achieve equal results, under certain scenarios. > What > > are the advantages of using EJB compared with just using just > > JSP/JavaBean? The advantages are many, but the spirit could be expressed like this: EJBs allow you to worry less about the plumbing(like object usage, memory, replication, scalability, reliability, SQL execution performance, load balancing, etc.) and focus on the business problem at hand. It also gives a common standard to work on top of to all developers, and sort of a common language to communicate with each other. Other choices give more freedom (and perhaps a faster time to market in small projects) at the expense of networking. On ocasions EJBs either don't handle these properly or are overkill. This aren't the majority of the ocasions, in fact it's a small percentage on very specific situations. You can switch back to JSP/JavaBeans(or any other alternative) to handle special cases. > 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. Maybe. Maybe the sort of work you've done so far is simple enough for JSP to handle it properly, therefore making EJBs an unnecessary burden. Maybe you're just starting with EJBs and you're not as profficient with EJBs as you might be with JSP. Maybe you work alone or within a very small team. Maybe you haven't got to modify a JavaBean a programmer who just left the company created. You haven't mentioned Message Queues, Asynchronic Transactions, non-relational or exotic Persitence Subsystems(no JDBC support for instance), etc. I use EJBs in projects where EJBs are needed. I don't build a Ferrari when asked for a bycicle. And when the strictness of EJBs harms my ability to deliver, I switch back to technologies that provide greater freedom(proefficiency with EJBs isn't a concern to me anymore). EJB eases, more often than not, the amount of work of my team has to do, both now and in the future. My 2c, JP PS: Could somebody FW this to JSP-INTEREST? ========================= To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
