Re: JSP/JavaBean compared with EJB
> 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”? I tend to agree with you on other points. You will need a transaction management if you have a distributed transaction, which means more than one database are involved (or database schema for that matter). In fact you can make a one phase transaction with regular JavaBean (better with Data Access Objects), but for true two-phase commit you will need EJB. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.458 / Virus Database: 257 - Release Date: 2/24/2003 ==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
Re: Fw: Re: JSP/JavaBean compared with EJB
I think the scalability isn´t a problem in the simple javabeans aproach. You can deploy a web application in a cluster of Application Servers and the javabeans are replicated in each server. I think you must use EJB´s if; -you have diferent presentation layers such HTML and a GUI client. -you need the special features of ejb´s (transactions, CMP ...) -There are another applications that uses these objects. My experience is that EJB´s are hard to learn and use by not experienced programers. If in your organization there are many of novice people, be carefull with these technologies. -Mensaje original- De: A mailing list about Java Server Pages specification and reference [mailto:[EMAIL PROTECTED] nombre de Tom Yang Enviado el: martes, 25 de febrero de 2003 21:18 Para: [EMAIL PROTECTED] Asunto: Re: Fw: Re: JSP/JavaBean compared with EJB Hi all: Thank you all 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 _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail === 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 === 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
Re: Fw: Re: JSP/JavaBean compared with EJB
Hi all: Thank you all 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 _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail === 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
Fw: Re: JSP/JavaBean compared with EJB
- 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 be
Re: JSP/JavaBean compared with EJB
Tom, I echo your concerns. Our company uses the same basic components you described, and then when the whole "EJB Buzz" started to pick up stream I was tasked with evaluating whether or not EJB would be appropriate for some of our projects. Now, I do not claim to have a good understanding of EJB, just a moderate one ;) But here are some reasons why EJB is good: - If you are writing a large, enterprise class system, using EJB will result in that system being built faster and more reliably. Because EJB includes declarative middleware, like instance pooling, transactions, security, etc, you don't have to write all that yourself. You get a nice team of people from IBM or Oracle to do it for you. - You can encapsulate your business objects without mixing them in another layer. This way your EJBs can be ported to other systems with different user interfaces, for instance a thick client model. - You can sepperate your web layer and application layer, letting you sepperate load, and also for security purposes (like having a firewall between the application server and the web server). There are a lot of other pluses of course, for instance most tool vendors are starting to ship their products with helpful wizards, etc that simplify some of the work. Also, if you prefer to get your setup from one vendor, their tools usually take care of a lot of the deploy work. I suggest you go buy a book on EJB to see if its really worth it. Now, along with the positives, theres of course the negatives. EJB, in my opinion, is this giant ugly monster. Its bloated, complicated, and expensive for all but the biggest of our projects. Most websites are just pretty GUIs wrapping a database, no need for EJB. I hope this gives you a little idea of EJB. Like I said, buying a book or taking a short class on EJB will definatly help towards understanding it. -- Branden Root Senior Developer Portent Interactive On Monday 24 February 2003 10:51 am, you wrote: > Hi all: > Ive 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 didnt 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 havent 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 dont 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 doesnt 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 didnt 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 > doesscalability 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 EJBs > transaction management? > > 8) Another advantage of EJB I heard was security. My application > currently uses username and passwords to
