Re: EJB vs Servlets
Title: RE: EJB vs Servlets
I agree that the standardness is a good argument in
favor of CMP beans (as oppossed to another OR mapping tools); I was just making
the point that there are plenty of mapping tools and they work fine with
servlets, they worked fine before servlets... I think original post below would
be more correct to say that development is faster with an OR mapping tool than
with JDBC, and EJB CMP beans was their chosen OR mapping tools.
What I want to avoid is the idea that somehow OR
mapping is something "new" that is only available via EJB CMP
beans.
- Original Message -
From:
Magnus
Rydin
To: Orion-Interest
Sent: Wednesday, October 11, 2000 6:07
AM
Subject: RE: EJB vs Servlets
I
would say that the keyword here, and in nearly everything else is
*standard*.
There are *loads* of books, tutorials, documentation,
news-groups, people that uses EJB and likes it.
When
you are using other, less widely spread, object-wrapper products, you can only
rely on a small community for help.
With
standards comes tools, and we want tools, dont we?
WR
-Original Message-From: Kyle Cordes
[mailto:[EMAIL PROTECTED]]Sent: den 10 oktober 2000
20:51To: Orion-InterestSubject: Re: EJB vs
Servlets
This strikes me as a straw-man argument.
There is no reason that servlet code must use JDBC directly. There are
many object-wrapper products available that work similarly to CMP beans;
such products predate EJB by a long, long time.
-Kyle Cordes
- Original Message -
From:
Mike
Cannon-Brookes
To: Orion-Interest
Sent: Monday, October 09, 2000 6:08
PM
Subject: RE: EJB vs Servlets
I use EJBs in a high volume environment and have
had no problems with scalability or speed yet.
I have to say once you know EJBs well enough,
dev't is definitely faster than with servlets. The sheer volume of JDBC
code and debugging required in a servlet outweighs the quick speed you can
do the same thing in EJBs. (See ejb-maker for an
example).
Mike
RE: EJB vs Servlets
Hi, > As far as the question that kicked of this discussion. If you > do not need > the any of the benefits of EJB then don't use it. However, I > would recommend > that you separate your data and business layers from your > servlets and JSPs. > Have them be presentation only. That way you could always > grow into EJB > without having to rewrite your front end. Actually, we have done just this. Using the Struts framework, we have JSP/Action classes that call upon "session" classes. These session classes are our logic, which would become EJB. The action classes would then get the EJB Home and do the EJB calling and so on. But the actual logic wouldn't change..only the classes would have to extend EJB (or whatever it is they extend) and stub/skeleton classes would be created.
RE: EJB vs Servlets
Title: RE: EJB vs Servlets I would say that the keyword here, and in nearly everything else is *standard*. There are *loads* of books, tutorials, documentation, news-groups, people that uses EJB and likes it. When you are using other, less widely spread, object-wrapper products, you can only rely on a small community for help. With standards comes tools, and we want tools, dont we? WR -Original Message-From: Kyle Cordes [mailto:[EMAIL PROTECTED]]Sent: den 10 oktober 2000 20:51To: Orion-InterestSubject: Re: EJB vs Servlets This strikes me as a straw-man argument. There is no reason that servlet code must use JDBC directly. There are many object-wrapper products available that work similarly to CMP beans; such products predate EJB by a long, long time. -Kyle Cordes - Original Message - From: Mike Cannon-Brookes To: Orion-Interest Sent: Monday, October 09, 2000 6:08 PM Subject: RE: EJB vs Servlets I use EJBs in a high volume environment and have had no problems with scalability or speed yet. I have to say once you know EJBs well enough, dev't is definitely faster than with servlets. The sheer volume of JDBC code and debugging required in a servlet outweighs the quick speed you can do the same thing in EJBs. (See ejb-maker for an example). Mike
RE: EJB vs Servlets
A very effective technique can be to use an OODMS (e.g. ObjectStore, Objectivity) rather than entity beans, and then code session EJBs to encapsulate logic. I've never liked O/R mappings. It's a constant disappoint to me that EJB doesn't generically support the transparent mapping of entity EJBs to an OODB, although BMP could emulate it with careful use of the ODMG API's. I know that this is basically what ODI's Javlin module does, but that's a platform-limited product. - Joshua Goodall -Original Message- From: Kyle Cordes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 10, 2000 8:51 PM To: Orion-Interest Subject: Re: EJB vs Servlets This strikes me as a straw-man argument. There is no reason that servlet code must use JDBC directly. There are many object-wrapper products available that work similarly to CMP beans; such products predate EJB by a long, long time. -Kyle Cordes - Original Message - From: Mike <mailto:[EMAIL PROTECTED]> Cannon-Brookes To: Orion-Interest <mailto:[EMAIL PROTECTED]> Sent: Monday, October 09, 2000 6:08 PM Subject: RE: EJB vs Servlets I use EJBs in a high volume environment and have had no problems with scalability or speed yet. I have to say once you know EJBs well enough, dev't is definitely faster than with servlets. The sheer volume of JDBC code and debugging required in a servlet outweighs the quick speed you can do the same thing in EJBs. (See ejb-maker for an example). Mike
Re: EJB vs Servlets
Title: RE: EJB vs Servlets This strikes me as a straw-man argument. There is no reason that servlet code must use JDBC directly. There are many object-wrapper products available that work similarly to CMP beans; such products predate EJB by a long, long time. -Kyle Cordes - Original Message - From: Mike Cannon-Brookes To: Orion-Interest Sent: Monday, October 09, 2000 6:08 PM Subject: RE: EJB vs Servlets I use EJBs in a high volume environment and have had no problems with scalability or speed yet. I have to say once you know EJBs well enough, dev't is definitely faster than with servlets. The sheer volume of JDBC code and debugging required in a servlet outweighs the quick speed you can do the same thing in EJBs. (See ejb-maker for an example). Mike
RE: EJB vs Servlets
Hello, This is a very interesting discussion. Here at we built our own application server on top of servlets, no JSP, no EJB's. This application server is focused on content management systems. While we are stil happy using it for almost all our clients, I still intent to go to building sites using the J2EE technology and methods. The main reason I want this is not because of technical reasons, but because almost all application server vendors are going the J2EE way. For example, take a look at Vignette, which is going to rebuilt their Storyserver on top of J2ee, of Allaire, which is going to rebuilt its Cold Fusion engine on top of JRun. Also, BEA, IBM and others are all creating J2EE compliant Application Servers. I know this is more a long-term, management overview, probably not intented for a single project, but all these players are going to create reusable components using EJB. So we have to have experience using J2EE, and especially the EJB part, even when it's as immature as it is today, in order to take advantage of them. Martijn -- _ Martijn van Berkum creative online development _ mailto:[EMAIL PROTECTED] _ http://www.gx.nl/ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > bradley mclain > Sent: dinsdag 10 oktober 2000 14:57 > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > hello all, > > since it came up, this is an issue that i and our > other programmer have been wrestling with for a while, > because like everyone else we feel the pressure to use > the cool new stuff..and we wonder if the transactional > and distributed advantages will help us out. > > here is my problem. call me dense, but i just don't > see or mapping being as flexible as i need it to be. > in all the books the examples tell you that you map > your object to the table that holds its data. sounds > fine in theory, but we have some very complex objects, > and we have a complex relational model, the reason for > which is to store our data efficiently, not only for > this application, but also for others. so we have > objects that need to get their data from different > tables, even different databases. these objects > contain collections, single entities, indexes into > other objects, etc., all of which must be persisted in > the db. we have solved the problem by writing our own > dblayer, employing reflection and stashing all our > queries (as well as caching them and the connections) > in a static lookup object. this gives us a level of > control over the data that i cannot see us getting > from any OR tool, no matter how smart (and remember, > the smarter something is, the slower). > > as to transactional support, we use jts or the db > transaction services. no problems.. > > as to servlets, we use exactly one per application, > mereley to take the requests and to control > everything--everything else is plain old java classes. > it is blazingly fast. i cannot believe that looking > up objects through jndi is going to be as quick as > looking up my classes in a hashmap. > > if i want distribution, i simply break my app into > multiple apps, run them on separate machines, and use > the same object model--thats one benefit of oo, right? > > i hope someone has the time to refute me completely, > because, like kevin, i really do want to understand > what ejb will give me that i cannot live without. my > greatest concern, as i mentioned above, is OR mapping. > i have been a dba and a programmer, and i find it > really difficult to believe that some tool is going to > produce more efficient and more flexible access to my > data than i can, given that i currently have full > control from table to view to sp to accessor methods > on objects.. > > bradley mclain > --usmoving.com > > --- "Duffey, Kevin" <[EMAIL PROTECTED]> wrote: > > Hi Mike (and all), > > > > Actually, while Struts is pretty kewl, there are > > some things that I wish > > were modified that won't be for reasons of the > > general population interest > > instead of my own. Because of this, while I will > > continue to use Struts at > > work, my own projects will use my own solution, > > similar to Struts but not > > near as robust in some ways, but a bit better on > > performance. The one thing > > I really dislike, but I agree with based on what > > Craig has told me, is that > > every single form submission causes the > > auto-population feature to get > > called (reflection). I only want it to be called if > &
Re: EJB vs Servlets
well, here's my 2cts: I have been dealing with objects and relational databases for 7 years now, spending 4 of those writing an object-relational mapping tool for the Smalltalk language. I remember well the time when a CORBA persistence service and OODBMS integration was under consideration and later abandoned because it was too complex and ill-designed (dont know if they have come up with another one since then). One point in the discussion at that time was that incarnating every object in a (usually complex) persistent object model as a remote entity would impose an unacceptable overhead and not provide any significant benefits. Considering my experience, I would always first opt for session beans to implement transaction demarcation and business processes, and do the database access either directly or through some nice mapping tool (those are rare, however). Entity EJBs come in handy if you really need remote accessibility, and maybe the deferred mapping (at deployment time, meaning the deployer can choose the persistent represenation) for CMP beans may also be an argument. -Original Message- From: bradley mclain <[EMAIL PROTECTED]> To: Orion-Interest <[EMAIL PROTECTED]> Date: Dienstag, 10. Oktober 2000 17:59 Subject: RE: EJB vs Servlets >hello all, > >since it came up, this is an issue that i and our >other programmer have been wrestling with for a while, >because like everyone else we feel the pressure to use >the cool new stuff..and we wonder if the transactional >and distributed advantages will help us out. > >here is my problem. call me dense, but i just don't >see or mapping being as flexible as i need it to be. >in all the books the examples tell you that you map >your object to the table that holds its data. sounds >fine in theory, but we have some very complex objects, >and we have a complex relational model, the reason for >which is to store our data efficiently, not only for >this application, but also for others. so we have >objects that need to get their data from different >tables, even different databases. these objects >contain collections, single entities, indexes into >other objects, etc., all of which must be persisted in >the db. we have solved the problem by writing our own >dblayer, employing reflection and stashing all our >queries (as well as caching them and the connections) >in a static lookup object. this gives us a level of >control over the data that i cannot see us getting >from any OR tool, no matter how smart (and remember, >the smarter something is, the slower). > >as to transactional support, we use jts or the db >transaction services. no problems.. > >as to servlets, we use exactly one per application, >mereley to take the requests and to control >everything--everything else is plain old java classes. > it is blazingly fast. i cannot believe that looking >up objects through jndi is going to be as quick as >looking up my classes in a hashmap. > >if i want distribution, i simply break my app into >multiple apps, run them on separate machines, and use >the same object model--thats one benefit of oo, right? > >i hope someone has the time to refute me completely, >because, like kevin, i really do want to understand >what ejb will give me that i cannot live without. my >greatest concern, as i mentioned above, is OR mapping. > i have been a dba and a programmer, and i find it >really difficult to believe that some tool is going to >produce more efficient and more flexible access to my >data than i can, given that i currently have full >control from table to view to sp to accessor methods >on objects.. > >bradley mclain >--usmoving.com >
RE: EJB vs Servlets
Hello, This is a very interesting discussion. Here at we built our own application server on top of servlets, no JSP, no EJB's. This application server is focused on content management systems. While we are stil happy using it for almost all our clients, I still intent to go to building sites using the J2EE technology and methods. The main reason I want this is not because of technical reasons, but because almost all application server vendors are going the J2EE way. For example, take a look at Vignette, which is going to rebuilt their Storyserver on top of J2ee, of Allaire, which is going to rebuilt its Cold Fusion engine on top of JRun. Also, BEA, IBM and others are all creating J2EE compliant Application Servers. I know this is more a long-term, management overview, probably not intented for a single project, but all these players are going to create reusable components using EJB. So we have to have experience using J2EE, and especially the EJB part, even when it's as immature as it is today, in order to take advantage of them. Martijn -- _ Martijn van Berkum creative online development _ mailto:[EMAIL PROTECTED] _ http://www.gx.nl/ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > bradley mclain > Sent: dinsdag 10 oktober 2000 14:57 > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > hello all, > > since it came up, this is an issue that i and our > other programmer have been wrestling with for a while, > because like everyone else we feel the pressure to use > the cool new stuff..and we wonder if the transactional > and distributed advantages will help us out. > > here is my problem. call me dense, but i just don't > see or mapping being as flexible as i need it to be. > in all the books the examples tell you that you map > your object to the table that holds its data. sounds > fine in theory, but we have some very complex objects, > and we have a complex relational model, the reason for > which is to store our data efficiently, not only for > this application, but also for others. so we have > objects that need to get their data from different > tables, even different databases. these objects > contain collections, single entities, indexes into > other objects, etc., all of which must be persisted in > the db. we have solved the problem by writing our own > dblayer, employing reflection and stashing all our > queries (as well as caching them and the connections) > in a static lookup object. this gives us a level of > control over the data that i cannot see us getting > from any OR tool, no matter how smart (and remember, > the smarter something is, the slower). > > as to transactional support, we use jts or the db > transaction services. no problems.. > > as to servlets, we use exactly one per application, > mereley to take the requests and to control > everything--everything else is plain old java classes. > it is blazingly fast. i cannot believe that looking > up objects through jndi is going to be as quick as > looking up my classes in a hashmap. > > if i want distribution, i simply break my app into > multiple apps, run them on separate machines, and use > the same object model--thats one benefit of oo, right? > > i hope someone has the time to refute me completely, > because, like kevin, i really do want to understand > what ejb will give me that i cannot live without. my > greatest concern, as i mentioned above, is OR mapping. > i have been a dba and a programmer, and i find it > really difficult to believe that some tool is going to > produce more efficient and more flexible access to my > data than i can, given that i currently have full > control from table to view to sp to accessor methods > on objects.. > > bradley mclain > --usmoving.com > > --- "Duffey, Kevin" <[EMAIL PROTECTED]> wrote: > > Hi Mike (and all), > > > > Actually, while Struts is pretty kewl, there are > > some things that I wish > > were modified that won't be for reasons of the > > general population interest > > instead of my own. Because of this, while I will > > continue to use Struts at > > work, my own projects will use my own solution, > > similar to Struts but not > > near as robust in some ways, but a bit better on > > performance. The one thing > > I really dislike, but I agree with based on what > > Craig has told me, is that > > every single form submission causes the > > auto-population feature to get > > called (reflection). I only want it to be called if > &
Re: EJB vs Servlets
Title: RE: EJB vs Servlets This strikes me as a straw-man argument. There is no reason that servlet code must use JDBC directly. There are many object-wrapper products available that work similarly to CMP beans; such products predate EJB by a long, long time. -Kyle Cordes - Original Message - From: Mike Cannon-Brookes To: Orion-Interest Sent: Monday, October 09, 2000 6:08 PM Subject: RE: EJB vs Servlets I use EJBs in a high volume environment and have had no problems with scalability or speed yet. I have to say once you know EJBs well enough, dev't is definitely faster than with servlets. The sheer volume of JDBC code and debugging required in a servlet outweighs the quick speed you can do the same thing in EJBs. (See ejb-maker for an example). Mike
Re: EJB vs Servlets
Hello Reddy, I agree with you in some points. Yes, complex OR mapping is solved in 2.0, but as you said is a draft. I won't risk put it into production right now (we have to finish the project by Octuber 17). About SQL, again I agree with you. I was using BMP EJB until I found out that Orion 1.3.6 generates automatically the findByAll() and findByXXX(). That way I have a better control over the beans I need. There is something I left out from the last mail. Because EJB1.1 complex O-R mapping is impossible (you need a workaround), sometimes I need a BMP Entity because I need a complex query. And for me, the myth was true. The migration from HyperSonic SQL to Oracle was transparent for the application. I just had to redeploy the application, and volia!, all the tables and constraints where there. The mass import was a little more tricky, (we used JDBC and SQL, query one place, insert in the other). Two side notes about independance from tables and databases: If you relay on triggers, multiple-field primary keys, foreign key for consistency, etc..., you have to stick into you RDMBS. And remember: never, ever, use a RDBMS that don't support multiple-field primary keys. They only give you headaches. -- Best regards, Rafaelmailto:[EMAIL PROTECTED]
RE: EJB vs Servlets
hello all, since it came up, this is an issue that i and our other programmer have been wrestling with for a while, because like everyone else we feel the pressure to use the cool new stuff..and we wonder if the transactional and distributed advantages will help us out. here is my problem. call me dense, but i just don't see or mapping being as flexible as i need it to be. in all the books the examples tell you that you map your object to the table that holds its data. sounds fine in theory, but we have some very complex objects, and we have a complex relational model, the reason for which is to store our data efficiently, not only for this application, but also for others. so we have objects that need to get their data from different tables, even different databases. these objects contain collections, single entities, indexes into other objects, etc., all of which must be persisted in the db. we have solved the problem by writing our own dblayer, employing reflection and stashing all our queries (as well as caching them and the connections) in a static lookup object. this gives us a level of control over the data that i cannot see us getting from any OR tool, no matter how smart (and remember, the smarter something is, the slower). as to transactional support, we use jts or the db transaction services. no problems.. as to servlets, we use exactly one per application, mereley to take the requests and to control everything--everything else is plain old java classes. it is blazingly fast. i cannot believe that looking up objects through jndi is going to be as quick as looking up my classes in a hashmap. if i want distribution, i simply break my app into multiple apps, run them on separate machines, and use the same object model--thats one benefit of oo, right? i hope someone has the time to refute me completely, because, like kevin, i really do want to understand what ejb will give me that i cannot live without. my greatest concern, as i mentioned above, is OR mapping. i have been a dba and a programmer, and i find it really difficult to believe that some tool is going to produce more efficient and more flexible access to my data than i can, given that i currently have full control from table to view to sp to accessor methods on objects.. bradley mclain --usmoving.com --- "Duffey, Kevin" <[EMAIL PROTECTED]> wrote: > Hi Mike (and all), > > Actually, while Struts is pretty kewl, there are > some things that I wish > were modified that won't be for reasons of the > general population interest > instead of my own. Because of this, while I will > continue to use Struts at > work, my own projects will use my own solution, > similar to Struts but not > near as robust in some ways, but a bit better on > performance. The one thing > I really dislike, but I agree with based on what > Craig has told me, is that > every single form submission causes the > auto-population feature to get > called (reflection). I only want it to be called if > an update occurs. If the > user hits cancel to go back, or what not..I don't > much care what they just > entered. Only when doing searches or updates/entry > on forms should it be > called. For that reason I am doing my own reflection > population routine that > does use nested objects. But overall Struts kicks > ass in what it offers for > a free package. > > Did I compare Struts to EJB? I didn't mean to in > terms of performance. > > > -Original Message- > > From: Mike Cannon-Brookes > [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 09, 2000 4:12 PM > > To: Orion-Interest > > Subject: RE: EJB vs Servlets > > > > > > I have to laugh when someone compares Struts to > EJBs for performance. > > > > I've used both and I'd have to say Kevin that if > you factored > > your code away > > from Struts and used EJBs instead you'd have a > very VERY > > minimal performance > > impact (if any noticable at all). > > > > And looking up EJBs is really very simple two > lines of code > > (or one little > > JSP tag ). > > > > Although if you wanted to attach a Swing client to > Struts... > > you'd have much > > greater problem I fear? ;) > > > > Mike > > > > PS Struts does have some cool points, I wish > they'd break out > > the i18n stuff > > into another library, it doesn't seem to fit > there. > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of > > Duffey, Kevin > > > Sent: Tuesday, October 10, 2000 5:01 AM > > > To: Orion-Interest > > > Subject: RE: EJB vs Servlets &
RE: EJB vs Servlets
What a fun discussion. There are obviously alot of strong opinions out there, and here's one more. :) I come from a DCE/Encina background and have been playing with EJB 1.1 (Orion) for about 2 months now. For those of you not familiar with Encina, it is a highly distributable RPC environment with very strong security, transaction support, etc. My take on EJB is as follows. The biggest benefit I see from EJB is distribution, transaction management, and security. I still think EJB still has a long way to go, but it's getting there. 2.0 seems to be another strong step in the right direction. As far as ease of development, pure enterprise beans are straight forward. Where I run into complexity is when I start getting a complex object model (lots of one-to-one and one-to-many relationships.) Even on this list, it has been strongly recommended that you don't talk to entity beans directly, but instead, talk via a session bean. This is almost necessary if you want any kind of decent transactional control (unless you mess with user transactions). Where I think this gets nasty is taking you details objects (somtimes called value objects, see details pattern at www.theserverside.com) and syncing them with your entity beans. With one-to-many's this is not a trivial task. As far as the OR mapping features of EJB (even 2.0) they are still weak. There are more sophisticated solutions for OR mapping (Toplink for Java, Cocobase, etc.). Unfortunately, the EJB spec doesn't provide a way for vendors of these tools to write plugins for expanding the functionality of EJB. (Although there is a Weblogic specific version of Toplink that allows for very sophisticated OR mappings) Also, EJBs and servlets are not mutually exclusive. While you don't always need both, as Russ White pointed out, if you need to be distributed, EJBs give you that without worrying about what kind of client you have. For web access to your app, servlets and JSPs can be clients to your EJB app. Lastly, as far as performance goes, I believe you are going to take a performance hit (not necessarily significant) with EJBs versus talking to to your persistence classes directly. This is because you are always going through the client stub when you use the EJB remote interface. In DCE and CORBA, when you call the client stub, it is optimized to do an RPC if the server is on a different machine, an IPC if it's on the same machine, and a simple method call if in the same process. EJB doesn't offer that kind of optimization, therefore, you are always serializing what your are passing to and from the enterprise bean. As far as the question that kicked of this discussion. If you do not need the any of the benefits of EJB then don't use it. However, I would recommend that you separate your data and business layers from your servlets and JSPs. Have them be presentation only. That way you could always grow into EJB without having to rewrite your front end. Bill -Original Message- From: Robert Krueger [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 10, 2000 7:04 AM To: Orion-Interest Subject: RE: EJB vs Servlets At 10:54 10.10.00 , you wrote: >Hi Kevin > >You seem to be missing the big picture here. With using a Servlet engine for >handling all your logic you are putting all your eggs the same basket. You >may have partitioned your logic up in the servlet container envirionment >(MVC) but this is only at class level. EJB gives you distinct partioning at >the component level. If you model all your Data and business logic at the >EJB level then you create yourself a reuseable component layer. This way you >can connect to this EJB layer from any clients, (Java) Servlets, (Java) jsp >, (java) desktop client , (java) mobile client, (VB) desktop client, (CORBA) >client and many more. At the moment you can only access your model layer >through the servlet contain (or at least you can't easily access the same >model from servlets and standalone clients, due to classloading etc) > >When you are accessing DB's from servlets you find yourself reinventing the >wheel , for OR mapping, calling frameworks and data caching algorithims all >the things that the best (like orion) app servers support > >:) > generally agree here. the point is that you have to make good modelling decisions WHAT you package as a component because you do pay a price for modelling something as an ejb (overhead due to copy-by-value semantics, maintenance of assembly and deployment information etc. and yes, the development cycle is slower with all ejb server I've uesd including orion) which you have to justify by the value you get back (declarative transactions, flexibility to deploy in different environments, remote usability by non-web-clients). I don't think it's a good question to ask whether to generally use servlets or ejb (provided you have a working
Re: EJB vs Servlets
> Hani Suleiman wrote: > > > 1) Connection pooling: This is available everywhere, and everyone can > reap the benefits of it while being perfectly EJBless. > > 2) Transaction support: Stored procedures can take care of this. Stored procedures to do your transactions for you takes away the possibility to easilly 'plug-in' another database, which, imho is one of the greatest benefits of EJB. While trying to learn orion & EJB at the same time, I was able to run the app I developed on Orion & Interprise App Server against Oracle, DB2, Sybase, Cloudscape & MYSQL without any changes to my code (Of course w/o the benefit of transactions in MySql. > 3) Caching of database objects: Pretty easy to implement > 4) Failover/load-balancing: As Kevin mentioned, works very nicely for > servlets. Sure all this can be easilly implemented, but why should you? The guys at Orion, Inprice, IBM etc already did this for us. Which is another nice benefit of EJB, a container that does all this for you, you only have to implement the bussines logic. More tedious sure, it's the stuff mentioned above which is the nice part of programming, calculating priceindexes is not really fun. > > Having said all that though, I'm still going to try and use EJB's in > my current project, and port all the existing 'model' objects to > become full fledged EJB's. I'm hoping the advantages will become > apparent then! > > Also, does anyone have any concrete examples of EJB's > performance/scalability? Has anyone deployed them in a high volume > production environment? Most people seem to be using them for > prototyping and small scale projects, that I know of... It's quite a new technology, so there are hardly any big projects running. I know that here in brazil some financial institutions are messing with it (IAS because of Cobra). Sure EJB is slower, it's the java standard for a transactional framework, not the Java implemented in McLaren cars ;-) sven -- == Sven E. van 't Veer http://www.cachoeiro.net Java Developer [EMAIL PROTECTED] ==
RE: EJB vs Servlets
At 10:54 10.10.00 , you wrote: >Hi Kevin > >You seem to be missing the big picture here. With using a Servlet engine for >handling all your logic you are putting all your eggs the same basket. You >may have partitioned your logic up in the servlet container envirionment >(MVC) but this is only at class level. EJB gives you distinct partioning at >the component level. If you model all your Data and business logic at the >EJB level then you create yourself a reuseable component layer. This way you >can connect to this EJB layer from any clients, (Java) Servlets, (Java) jsp >, (java) desktop client , (java) mobile client, (VB) desktop client, (CORBA) >client and many more. At the moment you can only access your model layer >through the servlet contain (or at least you can't easily access the same >model from servlets and standalone clients, due to classloading etc) > >When you are accessing DB's from servlets you find yourself reinventing the >wheel , for OR mapping, calling frameworks and data caching algorithims all >the things that the best (like orion) app servers support > >:) > generally agree here. the point is that you have to make good modelling decisions WHAT you package as a component because you do pay a price for modelling something as an ejb (overhead due to copy-by-value semantics, maintenance of assembly and deployment information etc. and yes, the development cycle is slower with all ejb server I've uesd including orion) which you have to justify by the value you get back (declarative transactions, flexibility to deploy in different environments, remote usability by non-web-clients). I don't think it's a good question to ask whether to generally use servlets or ejb (provided you have a working J2EE implementation at hand). it's like asking:"what's better? a race car or a jeep". you have to know the trade-offs to make good modelling decisions (HOW to use those technologies is the key) and that requires experience (especially having made bad ones ;-). however, there are many productive applications out there based on proven technologies like the apache jserv combination because they are rock stable, clustering is easy and people have had a few years time to find out the odds and evens of the particular technologies and I would agree that in many transactional web applications you would not lose too much if you did it with servlets, a transaction manager like tirex and some other O/R mapping layer like castor if you have a good architect. the modelling decisions (the tough part) you have to make are not that different. just my 2c, robert >-Original Message- >From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 09, 2000 6:22 PM >To: Orion-Interest >Subject: EJB vs Servlets > > >Hey all, > >I know this is a little off-topic, but seeing as how Orion is about the only >fully compliant EJB server, I figured this would be a better place to ask. > >Lately I have talked to a number of people that have been moving towards EJB >and pulled back because they have found it to be more tedious to develop, as >well as the end result was slower than just using Servlets. > >I ask this because it appears to me that the servlet engine (at least with >2.2) being able to be failed over, load-balanced, etc, seems to be quite as >capable for scalability and fault-tolerance as the ejb engine used to be. I >do realize that the EJB container offers transaction management, but >connection pooling is available in the servlet engine at the server level as >well. So, if you lose speed in development time and performance, what is the >real benefits of moving to EJB? I should say this with caution..I am sure >the EJB engine/container offers some things the servlet container doesn't, >but I would think its possible to actually put those abilities in the >servlet container. > >Anyways..I'll be interested in hearing any feedback on this. > >Thanks. (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: EJB vs Servlets
Hi Kevin You seem to be missing the big picture here. With using a Servlet engine for handling all your logic you are putting all your eggs the same basket. You may have partitioned your logic up in the servlet container envirionment (MVC) but this is only at class level. EJB gives you distinct partioning at the component level. If you model all your Data and business logic at the EJB level then you create yourself a reuseable component layer. This way you can connect to this EJB layer from any clients, (Java) Servlets, (Java) jsp , (java) desktop client , (java) mobile client, (VB) desktop client, (CORBA) client and many more. At the moment you can only access your model layer through the servlet contain (or at least you can't easily access the same model from servlets and standalone clients, due to classloading etc) When you are accessing DB's from servlets you find yourself reinventing the wheel , for OR mapping, calling frameworks and data caching algorithims all the things that the best (like orion) app servers support :) -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 6:22 PM To: Orion-Interest Subject: EJB vs Servlets Hey all, I know this is a little off-topic, but seeing as how Orion is about the only fully compliant EJB server, I figured this would be a better place to ask. Lately I have talked to a number of people that have been moving towards EJB and pulled back because they have found it to be more tedious to develop, as well as the end result was slower than just using Servlets. I ask this because it appears to me that the servlet engine (at least with 2.2) being able to be failed over, load-balanced, etc, seems to be quite as capable for scalability and fault-tolerance as the ejb engine used to be. I do realize that the EJB container offers transaction management, but connection pooling is available in the servlet engine at the server level as well. So, if you lose speed in development time and performance, what is the real benefits of moving to EJB? I should say this with caution..I am sure the EJB engine/container offers some things the servlet container doesn't, but I would think its possible to actually put those abilities in the servlet container. Anyways..I'll be interested in hearing any feedback on this. Thanks.
RE: EJB vs Servlets
Here is what we are at ... By the mere fact we are using Swing we can't use Servlets. I'm working on an application that we will run as a webservice. That is, you will be able to enter/retrieve data in a Swing applet. We choose for the Swing route, because using HTML/ASP/JSP doesn't give you a good enough interface for anything beyond casual usage. We use applets because the ease of installation. Assuming the Java Plugin and code signing runs fine (and you don't need to transfer too many sizeable jar files) the whole thing will run nicely and limited bandwidth and you have on the server side full control over the client configuration. That -is- a tempting proposition. Setting up your environment: blazing speed is possible using EJB. With respect to coding things three times. That is only a sizable waiste of time when you do that often and in that case you write a program that generates these files. We have even gone beyond generating the three/four standard classes by generating wrappers around the client objects/interfaces to generalize access to the EJBs to make it easy to create table listing, record entry etc. I'm still developping on it, but it all looks like it is going to work even better then I expected. By the end of the month I expect to be able to 'generate' a standard data entry/retrieval application from a 'data-design' in just a few days (fingers crossed). I have to admit I don't know if that is easily done using Servlets, as I have not investigated that technology. Frank On Monday, October 09, 2000 9:24 PM, Reddy Krishnan [SMTP:[EMAIL PROTECTED]] wrote: > hi Kevin, > > Could not agree with you more. I am developing a system using EJBs and it takes 2-3 times as much effort to do the same stuff what could have been > done with jsps and servlets. The only saving grace seems to be OR mapping in EJB 2.0 where you can avoid writing JDBC code. I get a feeling of writing > the same code three times ( in xml descriptor, ejb accessor methods, details java object as dependents cannot be directly exposed). > > I think the full use of EJB will come into effect if there are some cool GUI tools that allow to you drag and drop and wire a business application > with all code automatically generated for you, for most of the code seems to be mechanical once the design is done. > > Would definately like to get a good answer from this forum. > > Cheers > Krishnan > > -Original Message- > From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 09, 2000 10:22 AM > To: Orion-Interest > Subject: EJB vs Servlets > > > Hey all, > > I know this is a little off-topic, but seeing as how Orion is about the only > fully compliant EJB server, I figured this would be a better place to ask. > > Lately I have talked to a number of people that have been moving towards EJB > and pulled back because they have found it to be more tedious to develop, as > well as the end result was slower than just using Servlets. > > I ask this because it appears to me that the servlet engine (at least with > 2.2) being able to be failed over, load-balanced, etc, seems to be quite as > capable for scalability and fault-tolerance as the ejb engine used to be. I > do realize that the EJB container offers transaction management, but > connection pooling is available in the servlet engine at the server level as > well. So, if you lose speed in development time and performance, what is the > real benefits of moving to EJB? I should say this with caution..I am sure > the EJB engine/container offers some things the servlet container doesn't, > but I would think its possible to actually put those abilities in the > servlet container. > > Anyways..I'll be interested in hearing any feedback on this. > > Thanks. >
RE: EJB vs Servlets
Here is what we are at ... By the mere fact we are using Swing we can't use Servlets. I'm working on an application that we will run as a webservice. That is, you will be able to enter/retrieve data in a Swing applet. We choose for the Swing route, because using HTML/ASP/JSP doesn't give you a good enough interface for anything beyond casual usage. We use applets because the ease of installation. Assuming the Java Plugin and code signing runs fine (and you don't need to transfer too many sizeable jar files) the whole thing will run nicely and limited bandwidth and you have on the server side full control over the client configuration. That -is- a tempting proposition. Setting up your environment: blazing speed is possible using EJB. With respect to coding things three times. That is only a sizable waiste of time when you do that often and in that case you write a program that generates these files. We have even gone beyond generating the three/four standard classes by generating wrappers around the client objects/interfaces to generalize access to the EJBs to make it easy to create table listing, record entry etc. I'm still developping on it, but it all looks like it is going to work even better then I expected. By the end of the month I expect to be able to 'generate' a standard data entry/retrieval application from a 'data-design' in just a few days (fingers crossed). I have to admit I don't know if that is easily done using Servlets, as I have not investigated that technology. Frank On Tuesday, October 10, 2000 10:13 AM, Frank Eggink [SMTP:[EMAIL PROTECTED]] wrote: > On Monday, October 09, 2000 9:24 PM, Reddy Krishnan [SMTP:[EMAIL PROTECTED]] wrote: > > hi Kevin, > > > > Could not agree with you more. I am developing a system using EJBs and it takes 2-3 times as much effort to do the same stuff what could have been > > done with jsps and servlets. The only saving grace seems to be OR mapping in EJB 2.0 where you can avoid writing JDBC code. I get a feeling of writing > > the same code three times ( in xml descriptor, ejb accessor methods, details java object as dependents cannot be directly exposed). > > > > I think the full use of EJB will come into effect if there are some cool GUI tools that allow to you drag and drop and wire a business application > > with all code automatically generated for you, for most of the code seems to be mechanical once the design is done. > > > > Would definately like to get a good answer from this forum. > > > > Cheers > > Krishnan > > > > -Original Message- > > From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 09, 2000 10:22 AM > > To: Orion-Interest > > Subject: EJB vs Servlets > > > > > > Hey all, > > > > I know this is a little off-topic, but seeing as how Orion is about the only > > fully compliant EJB server, I figured this would be a better place to ask. > > > > Lately I have talked to a number of people that have been moving towards EJB > > and pulled back because they have found it to be more tedious to develop, as > > well as the end result was slower than just using Servlets. > > > > I ask this because it appears to me that the servlet engine (at least with > > 2.2) being able to be failed over, load-balanced, etc, seems to be quite as > > capable for scalability and fault-tolerance as the ejb engine used to be. I > > do realize that the EJB container offers transaction management, but > > connection pooling is available in the servlet engine at the server level as > > well. So, if you lose speed in development time and performance, what is the > > real benefits of moving to EJB? I should say this with caution..I am sure > > the EJB engine/container offers some things the servlet container doesn't, > > but I would think its possible to actually put those abilities in the > > servlet container. > > > > Anyways..I'll be interested in hearing any feedback on this. > > > > Thanks. > >
Re: Re EJB vs Servlets
"van Geel, Leo" wrote: > > > -Original Message- > > From: Rafael Alvarez [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, October 10, 2000 9:11 AM > > To: Orion-Interest > > Subject: Re[2]: EJB vs Servlets > > > > > > I'm currently developing a big project using EJBs,a backend for a > > one-hour delivery company. In fact, I'm using CMP EJB for the data and > > a fakade object for processing.There were few factors that > > influenced the > > choice: > > .- You don't have to code in SQL. That says a lot on easy manteinance. > > .- Don't need to understand, as a programmer, the how of > > inner working of > >your RDMBS. > > This is one of the big dangers I see happening around me. Don't fall in this > trap. > You need to understand what is happening behind the scenes. Poor performance > is the result. > A programmer needs to understand how the the code is accessing the database. > That is a different story than understanding the DBMS internals! It is one > of the bad things about CMP EJB's. I do not believe that generated SQL code > can be optimal for all the different relational database backends. > Impossible! > > DBA's raise your voice! > > Leo van Geel > Massey University > New Zealand I agree that you need to understand what is happening behind the scenes, but that doesn't mean that you need to re-invent the wheel! CMP EJB's allow developers to concentrate on the business logic rather than having to worry about database access code, this is a good thing. Besides, I have run BMP vs CMP tests on several App server + DB combinations, CMP wins hands down every time. Damian
Re EJB vs Servlets
> -Original Message- > From: Rafael Alvarez [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 10, 2000 9:11 AM > To: Orion-Interest > Subject: Re[2]: EJB vs Servlets > > > I'm currently developing a big project using EJBs,a backend for a > one-hour delivery company. In fact, I'm using CMP EJB for the data and > a fakade object for processing.There were few factors that > influenced the > choice: > .- You don't have to code in SQL. That says a lot on easy manteinance. > .- Don't need to understand, as a programmer, the how of > inner working of >your RDMBS. This is one of the big dangers I see happening around me. Don't fall in this trap. You need to understand what is happening behind the scenes. Poor performance is the result. A programmer needs to understand how the the code is accessing the database. That is a different story than understanding the DBMS internals! It is one of the bad things about CMP EJB's. I do not believe that generated SQL code can be optimal for all the different relational database backends. Impossible! DBA's raise your voice! Leo van Geel Massey University New Zealand
RE: EJB vs Servlets
Couldn't agree more! > -Original Message- > From: Russ White [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 09, 2000 1:15 PM > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > Why do you have the idea the EJBs yield slower performance? > This is false. > > Your site sounds to small to worry about EJB right now. Stick > with Struts. Still > as a developer you owe it to yourself to dig deeper. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > Duffey, Kevin > > Sent: Monday, October 09, 2000 3:03 PM > > To: Orion-Interest > > Subject: RE: EJB vs Servlets > > > > > > You are talking about legacy support. I agree there. I > haven't read the full > > spec of EJB, and I heard EJB 2.0 is even better. I would > agree that overall > > its probably a better way to go, but, what does it really > offer that you > > can't do in the servlet engine? If you can do fail-over/scalability, > > connection pooling, transaction management, and so on now, > what benefits do > > you get from moving to EJB? Is it worth the bit slower > process of developing > > them, and the slower performance? I think on our site we > would be lucky to > > see 1000 users a day in 2 years from now, using our site, > and we have about > > 50 or so a day now. So is there a big need for us to move > to EJB in terms of > > future growth, or is the only "good" reason (for small to > mediume sites) to > > move to EJB is just to separate your tiers amongst servers? > > > > > > > -Original Message- > > > From: Troy Echols [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, October 09, 2000 11:37 AM > > > To: Orion-Interest > > > Subject: Re: EJB vs Servlets > > > > > > > > > Might there be some benefit to using EJBs over servlets alone > > > if you want to > > > support various modes of connectivity to your business logic > > > (e.g., standalone > > > clients using JMS/CORBA/RMI in addition to web clients). > > > > > > Just my two cents worth. > > > > > > Troy > > > > > > > Hani Suleiman wrote: > > > > > > > > I've considered using EJB's a number of times for various > > > projects I'm > > > > involved in, but every time, I have to admit to myself that > > > it's more for the > > > > fun and coolness factor, than any real 'need' to use EJB's. > > > > > > > > In every case, I was able to implement a solution using > > > servlets with various > > > > caches to do whatever is needed much faster than an EJB > > > would do things (as > > > > far as I can tell, I haven't put this theory to the test > > > yet though!). Here > > > > are some examples of EJB features and ways to get the same > > > thing without > > > > EJB's.. > > > > > > > > 1) Connection pooling: This is available everywhere, and > > > everyone can reap the > > > > benefits of it while being perfectly EJBless. > > > > > > > > 2) Transaction support: Stored procedures can take care of this. > > > > 3) Caching of database objects: Pretty easy to implement > > > > 4) Failover/load-balancing: As Kevin mentioned, works very > > > nicely for > > > > servlets. > > > > > > > > Having said all that though, I'm still going to try and use > > > EJB's in my > > > > current project, and port all the existing 'model' objects > > > to become full > > > > fledged EJB's. I'm hoping the advantages will become > apparent then! > > > > > > > > Also, does anyone have any concrete examples of EJB's > > > performance/scalability? > > > > Has anyone deployed them in a high volume production > > > environment? Most people > > > > seem to be using them for prototyping and small scale > > > projects, that I know > > > > of... > > > > > > > > Hani Suleiman > > > > > > > > > -Original Message- > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > > > Duffey, Kevin > > > > > Sent: Monday, October 09, 2000 1:22 PM > > > > > To: Orion-Interest > > > > > Sub
RE: EJB vs Servlets
Hi Mike (and all), Actually, while Struts is pretty kewl, there are some things that I wish were modified that won't be for reasons of the general population interest instead of my own. Because of this, while I will continue to use Struts at work, my own projects will use my own solution, similar to Struts but not near as robust in some ways, but a bit better on performance. The one thing I really dislike, but I agree with based on what Craig has told me, is that every single form submission causes the auto-population feature to get called (reflection). I only want it to be called if an update occurs. If the user hits cancel to go back, or what not..I don't much care what they just entered. Only when doing searches or updates/entry on forms should it be called. For that reason I am doing my own reflection population routine that does use nested objects. But overall Struts kicks ass in what it offers for a free package. Did I compare Struts to EJB? I didn't mean to in terms of performance. > -Original Message- > From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 09, 2000 4:12 PM > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > I have to laugh when someone compares Struts to EJBs for performance. > > I've used both and I'd have to say Kevin that if you factored > your code away > from Struts and used EJBs instead you'd have a very VERY > minimal performance > impact (if any noticable at all). > > And looking up EJBs is really very simple two lines of code > (or one little > JSP tag ). > > Although if you wanted to attach a Swing client to Struts... > you'd have much > greater problem I fear? ;) > > Mike > > PS Struts does have some cool points, I wish they'd break out > the i18n stuff > into another library, it doesn't seem to fit there. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > Duffey, Kevin > > Sent: Tuesday, October 10, 2000 5:01 AM > > To: Orion-Interest > > Subject: RE: EJB vs Servlets > > > > > > Actually, I know all about it. I have read up on it in > those books and > > others. Infact, we have already separated our code into > those tiers but it > > all runs in the servlet engine. This is what I am talking about. > > I am using > > the Struts framework to allow all forms submitted to a > single controller > > servlet, which then calls upong action classes. Those > action classes then > > figure out what "session" class to call upon. These > "session" classes are > > our logic (ejb) code, but its not in the EJB container..it > runs in our > > servlet engine. It is separated, just not from the servlet > engine itself. > > However, by compexity of building EJBs, I think I mean what > goes into it. > > Instead of a single class, we would have 2 (or is it 3) > interfaces and an > > implementation class. To access it, its not as simple as a > class/reference > > variable to an object in the servlet engine, you have to do > a lookup, > > etc..its a bit more code. Sure..its not terribly complex, > but compared to > > doing it the way we are now, there is quite a bit more work > involved than > > what we are doing now. Also, actually testing and learning > how exactly it > > works is a process that will take a little time. All of these > > things add up. > > What I am wondering is..is it really worth it if supposedly > EJB doesn't > > offer much in the way of performance..it just separates the > logic into a > > separate "tier" of servers. Our code is already separated > long those tiers > > now..and it will probably be easier for us to move to EJB > than those that > > have logic in their servlets. > > > > > > > -Original Message- > > > From: Russ White [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, October 09, 2000 11:32 AM > > > To: Orion-Interest > > > Subject: RE: EJB vs Servlets > > > > > > > > > You should read up on J2EE so you can understand what > separation of > > > data/logic/presentation is all about. I would recommend any > > > of the O'Reilly > > > books on the subject(s). Also Development of EJBs is very > > > simple. Especially > > > with a good IDE like VA, Forte, or JBuilder. Orion even comes > > > with a simple tool > > > for creating very useful EntityBeans from a GUI. > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > >
RE: EJB vs Servlets
Hi Russ, though the concept of EJBs sounds interesting and appealing there are two complaints against it (1) its not fully mature like other components of J2EE. Anybody who has developed using would know the numerous small issues here and there. I have been using EJBs from 1.1 and has been folllowing the spec to 2 and then pd2. Though it is moving in right direction it is still not fully there. (2) what does all these additional hue and cry finally buy? the question which everybody raises, which Sun and others intrested in future of EJB has to answer clearly, is what does it finally bring to the table that is substantial to the developer??? Still looking for a convincing answer. Thanks Krishnan -Original Message- From: Russ White [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 1:15 PM To: Orion-Interest Subject: RE: EJB vs Servlets Why do you have the idea the EJBs yield slower performance? This is false. Your site sounds to small to worry about EJB right now. Stick with Struts. Still as a developer you owe it to yourself to dig deeper. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin > Sent: Monday, October 09, 2000 3:03 PM > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > You are talking about legacy support. I agree there. I haven't read the full > spec of EJB, and I heard EJB 2.0 is even better. I would agree that overall > its probably a better way to go, but, what does it really offer that you > can't do in the servlet engine? If you can do fail-over/scalability, > connection pooling, transaction management, and so on now, what benefits do > you get from moving to EJB? Is it worth the bit slower process of developing > them, and the slower performance? I think on our site we would be lucky to > see 1000 users a day in 2 years from now, using our site, and we have about > 50 or so a day now. So is there a big need for us to move to EJB in terms of > future growth, or is the only "good" reason (for small to mediume sites) to > move to EJB is just to separate your tiers amongst servers? > > > > -Original Message- > > From: Troy Echols [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 09, 2000 11:37 AM > > To: Orion-Interest > > Subject: Re: EJB vs Servlets > > > > > > Might there be some benefit to using EJBs over servlets alone > > if you want to > > support various modes of connectivity to your business logic > > (e.g., standalone > > clients using JMS/CORBA/RMI in addition to web clients). > > > > Just my two cents worth. > > > > Troy > > > > > Hani Suleiman wrote: > > > > > > I've considered using EJB's a number of times for various > > projects I'm > > > involved in, but every time, I have to admit to myself that > > it's more for the > > > fun and coolness factor, than any real 'need' to use EJB's. > > > > > > In every case, I was able to implement a solution using > > servlets with various > > > caches to do whatever is needed much faster than an EJB > > would do things (as > > > far as I can tell, I haven't put this theory to the test > > yet though!). Here > > > are some examples of EJB features and ways to get the same > > thing without > > > EJB's.. > > > > > > 1) Connection pooling: This is available everywhere, and > > everyone can reap the > > > benefits of it while being perfectly EJBless. > > > > > > 2) Transaction support: Stored procedures can take care of this. > > > 3) Caching of database objects: Pretty easy to implement > > > 4) Failover/load-balancing: As Kevin mentioned, works very > > nicely for > > > servlets. > > > > > > Having said all that though, I'm still going to try and use > > EJB's in my > > > current project, and port all the existing 'model' objects > > to become full > > > fledged EJB's. I'm hoping the advantages will become apparent then! > > > > > > Also, does anyone have any concrete examples of EJB's > > performance/scalability? > > > Has anyone deployed them in a high volume production > > environment? Most people > > > seem to be using them for prototyping and small scale > > projects, that I know > > > of... > > > > > > Hani Suleiman > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > > Duffey, Kevin > > > &g
RE: EJB vs Servlets
I have to laugh when someone compares Struts to EJBs for performance. I've used both and I'd have to say Kevin that if you factored your code away from Struts and used EJBs instead you'd have a very VERY minimal performance impact (if any noticable at all). And looking up EJBs is really very simple two lines of code (or one little JSP tag ). Although if you wanted to attach a Swing client to Struts... you'd have much greater problem I fear? ;) Mike PS Struts does have some cool points, I wish they'd break out the i18n stuff into another library, it doesn't seem to fit there. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin > Sent: Tuesday, October 10, 2000 5:01 AM > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > Actually, I know all about it. I have read up on it in those books and > others. Infact, we have already separated our code into those tiers but it > all runs in the servlet engine. This is what I am talking about. > I am using > the Struts framework to allow all forms submitted to a single controller > servlet, which then calls upong action classes. Those action classes then > figure out what "session" class to call upon. These "session" classes are > our logic (ejb) code, but its not in the EJB container..it runs in our > servlet engine. It is separated, just not from the servlet engine itself. > However, by compexity of building EJBs, I think I mean what goes into it. > Instead of a single class, we would have 2 (or is it 3) interfaces and an > implementation class. To access it, its not as simple as a class/reference > variable to an object in the servlet engine, you have to do a lookup, > etc..its a bit more code. Sure..its not terribly complex, but compared to > doing it the way we are now, there is quite a bit more work involved than > what we are doing now. Also, actually testing and learning how exactly it > works is a process that will take a little time. All of these > things add up. > What I am wondering is..is it really worth it if supposedly EJB doesn't > offer much in the way of performance..it just separates the logic into a > separate "tier" of servers. Our code is already separated long those tiers > now..and it will probably be easier for us to move to EJB than those that > have logic in their servlets. > > > > -Original Message- > > From: Russ White [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 09, 2000 11:32 AM > > To: Orion-Interest > > Subject: RE: EJB vs Servlets > > > > > > You should read up on J2EE so you can understand what separation of > > data/logic/presentation is all about. I would recommend any > > of the O'Reilly > > books on the subject(s). Also Development of EJBs is very > > simple. Especially > > with a good IDE like VA, Forte, or JBuilder. Orion even comes > > with a simple tool > > for creating very useful EntityBeans from a GUI. > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Duffey, Kevin > > > Sent: Monday, October 09, 2000 1:22 PM > > > To: Orion-Interest > > > Subject: EJB vs Servlets > > > > > > > > > Hey all, > > > > > > I know this is a little off-topic, but seeing as how Orion > > is about the only > > > fully compliant EJB server, I figured this would be a > > better place to ask. > > > > > > Lately I have talked to a number of people that have been > > moving towards EJB > > > and pulled back because they have found it to be more > > tedious to develop, as > > > well as the end result was slower than just using Servlets. > > > > > > I ask this because it appears to me that the servlet engine > > (at least with > > > 2.2) being able to be failed over, load-balanced, etc, > > seems to be quite as > > > capable for scalability and fault-tolerance as the ejb > > engine used to be. I > > > do realize that the EJB container offers transaction management, but > > > connection pooling is available in the servlet engine at > > the server level as > > > well. So, if you lose speed in development time and > > performance, what is the > > > real benefits of moving to EJB? I should say this with > > caution..I am sure > > > the EJB engine/container offers some things the servlet > > container doesn't, > > > but I would think its possible to actually put those > > abilities in the > > > servlet container. > > > > > > Anyways..I'll be interested in hearing any feedback on this. > > > > > > Thanks. > > > > > > > > > >
RE: EJB vs Servlets
Title: RE: EJB vs Servlets I use EJBs in a high volume environment and have had no problems with scalability or speed yet. I have to say once you know EJBs well enough, dev't is definitely faster than with servlets. The sheer volume of JDBC code and debugging required in a servlet outweighs the quick speed you can do the same thing in EJBs. (See ejb-maker for an example). Mike -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hani SuleimanSent: Tuesday, October 10, 2000 3:41 AMTo: Orion-InterestSubject: RE: EJB vs Servlets I've considered using EJB's a number of times for various projects I'm involved in, but every time, I have to admit to myself that it's more for the fun and coolness factor, than any real 'need' to use EJB's. In every case, I was able to implement a solution using servlets with various caches to do whatever is needed much faster than an EJB would do things (as far as I can tell, I haven't put this theory to the test yet though!). Here are some examples of EJB features and ways to get the same thing without EJB's.. 1) Connection pooling: This is available everywhere, and everyone can reap the benefits of it while being perfectly EJBless. 2) Transaction support: Stored procedures can take care of this. 3) Caching of database objects: Pretty easy to implement 4) Failover/load-balancing: As Kevin mentioned, works very nicely for servlets. Having said all that though, I'm still going to try and use EJB's in my current project, and port all the existing 'model' objects to become full fledged EJB's. I'm hoping the advantages will become apparent then! Also, does anyone have any concrete examples of EJB's performance/scalability? Has anyone deployed them in a high volume production environment? Most people seem to be using them for prototyping and small scale projects, that I know of... Hani Suleiman > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Duffey, Kevin > Sent: Monday, October 09, 2000 1:22 PM > To: Orion-Interest > Subject: EJB vs Servlets > > > Hey all, > > I know this is a little off-topic, but seeing as how Orion is > about the only > fully compliant EJB server, I figured this would be a better > place to ask. > > Lately I have talked to a number of people that have been > moving towards EJB > and pulled back because they have found it to be more tedious > to develop, as > well as the end result was slower than just using Servlets. > > I ask this because it appears to me that the servlet engine > (at least with > 2.2) being able to be failed over, load-balanced, etc, seems > to be quite as > capable for scalability and fault-tolerance as the ejb engine > used to be. I > do realize that the EJB container offers transaction management, but > connection pooling is available in the servlet engine at the > server level as > well. So, if you lose speed in development time and > performance, what is the > real benefits of moving to EJB? I should say this with > caution..I am sure > the EJB engine/container offers some things the servlet > container doesn't, > but I would think its possible to actually put those abilities in the > servlet container. > > Anyways..I'll be interested in hearing any feedback on this. > > Thanks. >
Re: EJB vs Servlets
I thought the main idea was that once you had creaed your J2EE deployable App you could pick it up (in the form of one neat package/jar) and dump it into any J2EE compliant container - W.O.R.A. la! Your EJBs implement all the necessary interfaces to allow any J2EE container to manage them in a multiplicity of ways. The only real question is viability - just how much load can you app take? BTW I think (am not certain) there are compliance issues if you use 'good' tools like VAJ to generate your EJBs. Great if you really like or want ot use WebSphere? - Original Message - From: "Russ White" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Monday, October 09, 2000 8:32 PM Subject: RE: EJB vs Servlets > You should read up on J2EE so you can understand what separation of > data/logic/presentation is all about. I would recommend any of the O'Reilly > books on the subject(s). Also Development of EJBs is very simple. Especially > with a good IDE like VA, Forte, or JBuilder. Orion even comes with a simple tool > for creating very useful EntityBeans from a GUI. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin > > Sent: Monday, October 09, 2000 1:22 PM > > To: Orion-Interest > > Subject: EJB vs Servlets > > > > > > Hey all, > > > > I know this is a little off-topic, but seeing as how Orion is about the only > > fully compliant EJB server, I figured this would be a better place to ask. > > > > Lately I have talked to a number of people that have been moving towards EJB > > and pulled back because they have found it to be more tedious to develop, as > > well as the end result was slower than just using Servlets. > > > > I ask this because it appears to me that the servlet engine (at least with > > 2.2) being able to be failed over, load-balanced, etc, seems to be quite as > > capable for scalability and fault-tolerance as the ejb engine used to be. I > > do realize that the EJB container offers transaction management, but > > connection pooling is available in the servlet engine at the server level as > > well. So, if you lose speed in development time and performance, what is the > > real benefits of moving to EJB? I should say this with caution..I am sure > > the EJB engine/container offers some things the servlet container doesn't, > > but I would think its possible to actually put those abilities in the > > servlet container. > > > > Anyways..I'll be interested in hearing any feedback on this. > > > > Thanks. > > > > > >
RE: [RE: EJB vs Servlets]
Hi, > I think what we have is a case of fear, uncertainty and doubt. My > experience with EJBs has been so good I'm going back to > rewrite some of my > personal-hobby-related sites into EJBs. That is how > impressed I am with > EJB. I think your exactly right. I bought an EJB book and started reading it and the first couple of chapters have got me a little worried. ;) Actually..I think once I actually figure out how to develop them, it will be less fear. I am just looking at what needs to be done and it appears to be a lot of work. Ideally I really want to learn about EJB, CMP and O/R, but I have no idea where to being (other than that book i got). Is CMP and O/R a standard..or vendor specific implementations? Do I need special tools for CMP and O/R, or do all DBMS with Type IV JDBC 2.0 drivers support it. I am looking at the Interbase 6 free RDBMS which I have used a while back with C++Builder and the fact that its free and was pretty fast back then impresses me. Its not for large-scale apps, but it will certainly work for most tasks. But to actually get started, that seems to be taking the most time. There isn't much docs on Orion on how to get EJB's working, CMP, O/R, etc. I don't even fully understand those items yet, and am not sure if I need tools to do that, or can I manually edit them, and so on. Anyways..thanks for the reply.
Re: EJB vs Servlets
I would say that using J2EE architecture and EJB is most useful if you don't have specific performance needs. When you don't have leeway on performance you have to bite the bullet and use whatever gives you the performance you need. Obviously EJB2.0 OR mapping is a huge key, this allows the full usage of CMP as it's intended. CMP is a huge benefit since it puts more code on the shoulders of the server vendor and not the application developer(or a separate team of developers). And using a standardized architecture that is supported by multiple app server vendors(who are in multiple price/quality arenas) is a benefit in my eyes as well. In the past we've done our own code generation for OR mapping, and at first it did not handle transactions and connection pooling for you. We had to upgrade it and maintain it to provide these features. With J2EE servers you get all that stuff without having to maintain the code for it -- we've upgraded our tier that has this code about 5 times over the past year and a half! Probably the majority of us out there right now are inbetween a pre-J2EE/EJB solution and a post solution. I'm looking forward to EJB2.0 and plan on writing or using one code-generator for CMP Entity beans and possibly generating Session Beans as well, or Session Bean shells for the different interfaces and such. This will take care of the 'time-to-develop' problem, remember, the use of EJBs is supposed to cut development/maintenance time. Also you get a fully distributed system(probably the performance hit) which has it's benefits if the application scope is right. Can the tiers of business code you have written be accessed(re-used) by any app running on any machine, no matter who develops it(VB team vs. Swing team vs. JSP or ASP teams)? If you've implemented them using RMI then you may be able to, but again you end up doing the maintenance and upgrades on that code too. Even with all the benefits I've listed, I'm not developing production code with EJBs just yet - one prototype application is all - the bleeding edge of EJB looks to be a sharp one if the project/application isn't right for it. The bottom line is time to market and a solution that fits the price - bigger customers can afford to wait a bit and pay for WebLogic and the like - but this list is most probably filled with us smaller company types who cater to smaller customers. Hopefully this info is useful - Matt
RE:[RE: EJB vs Servlets]
It sounds to me like it probably is not worth it for you to move to EJBs considering how much you have invested in your current technology. But some reasons we use EJBs where I work: a) portability. Stored procedures, mentioned in another post, are not portable at all. Whereas EJBs will run on a mainframe (Websphere), midrange (AS/400) or Unix to PCs (weblogic, orion, websphere, etc) with pretty much any database backend. b) Sure, you have lookups, but then if you want remote access ... c) NO SQL in our code (that could become a weird chant...). Fits the KISS principle and eliminates one learning curve (SQL is steeper than learning EJB and XML descriptors that's for sure). Plus, any change to the data model is not that big a deal to us with EJBs because it is easier to restructure an object and it's XML descriptors rather than chase down every SQL call to update/modify it. Especially in the maintenance phase where the original programmers are no longer around and no-one knows just where that insert/update/delete is happening... d) Learning EJB is not that big a deal. We put together a large website all EJB based (with servlets and JSPs to round out MVC) in less than 3 months. No one on the project had seen EJBs before. Even lightweight java programmers (less than a years experience) picked up on the concepts and were productive. Performance is on par with any other java environment I've seen, even under heavy load (given that you have the appropriate hardware behind it). I think what we have is a case of fear, uncertainty and doubt. My experience with EJBs has been so good I'm going back to rewrite some of my personal-hobby-related sites into EJBs. That is how impressed I am with EJB. -Alexandre On Mon, 9 Oct 2000 12:00:34 -0700 "Duffey, Kevin" <[EMAIL PROTECTED]> wrote: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Actually, I know all about it. I have read up on it in those books and others. Infact, we have already separated our code into those tiers but it all runs in the servlet engine. This is what I am talking about. I am using the Struts framework to allow all forms submitted to a single controller servlet, which then calls upong action classes. Those action classes then figure out what "session" class to call upon. These "session" classes are our logic (ejb) code, but its not in the EJB container..it runs in our servlet engine. It is separated, just not from the servlet engine itself. However, by compexity of building EJBs, I think I mean what goes into it. Instead of a single class, we would have 2 (or is it 3) interfaces and an implementation class. To access it, its not as simple as a class/reference variable to an object in the servlet engine, you have to do a lookup, etc..its a bit more code. Sure..its not terribly complex, but compared to doing it the way we are now, there is quite a bit more work involved than what we are doing now. Also, actually testing and learning how exactly it works is a process that will take a little time. All of these things add up. What I am wondering is..is it really worth it if supposedly EJB doesn't offer much in the way of performance..it just separates the logic into a separate "tier" of servers. Our code is already separated long those tiers now..and it will probably be easier for us to move to EJB than those that have logic in their servlets. > -Original Message- > From: Russ White [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 09, 2000 11:32 AM > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > You should read up on J2EE so you can understand what separation of > data/logic/presentation is all about. I would recommend any > of the O'Reilly > books on the subject(s). Also Development of EJBs is very > simple. Especially > with a good IDE like VA, Forte, or JBuilder. Orion even comes > with a simple tool > for creating very useful EntityBeans from a GUI. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > Duffey, Kevin > > Sent: Monday, October 09, 2000 1:22 PM > > To: Orion-Interest > > Subject: EJB vs Servlets > > > > > > Hey all, > > > > I know this is a little off-topic, but seeing as how Orion > is about the only > > fully compliant EJB server, I figured this would be a > better place to ask. > > > > Lately I have talked to a number of people that have been > moving towards EJB > > and pulled back because they have found it to be more > tedious to develop, as > > well as the end result was slower than just using Servlets. > > > > I ask this because it appears to me that the servlet engine > (at least with > > 2.2) being able to be failed over, load-balanced, etc, >
RE: EJB vs Servlets
Why do you have the idea the EJBs yield slower performance? This is false. Your site sounds to small to worry about EJB right now. Stick with Struts. Still as a developer you owe it to yourself to dig deeper. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin > Sent: Monday, October 09, 2000 3:03 PM > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > You are talking about legacy support. I agree there. I haven't read the full > spec of EJB, and I heard EJB 2.0 is even better. I would agree that overall > its probably a better way to go, but, what does it really offer that you > can't do in the servlet engine? If you can do fail-over/scalability, > connection pooling, transaction management, and so on now, what benefits do > you get from moving to EJB? Is it worth the bit slower process of developing > them, and the slower performance? I think on our site we would be lucky to > see 1000 users a day in 2 years from now, using our site, and we have about > 50 or so a day now. So is there a big need for us to move to EJB in terms of > future growth, or is the only "good" reason (for small to mediume sites) to > move to EJB is just to separate your tiers amongst servers? > > > > -Original Message- > > From: Troy Echols [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 09, 2000 11:37 AM > > To: Orion-Interest > > Subject: Re: EJB vs Servlets > > > > > > Might there be some benefit to using EJBs over servlets alone > > if you want to > > support various modes of connectivity to your business logic > > (e.g., standalone > > clients using JMS/CORBA/RMI in addition to web clients). > > > > Just my two cents worth. > > > > Troy > > > > > Hani Suleiman wrote: > > > > > > I've considered using EJB's a number of times for various > > projects I'm > > > involved in, but every time, I have to admit to myself that > > it's more for the > > > fun and coolness factor, than any real 'need' to use EJB's. > > > > > > In every case, I was able to implement a solution using > > servlets with various > > > caches to do whatever is needed much faster than an EJB > > would do things (as > > > far as I can tell, I haven't put this theory to the test > > yet though!). Here > > > are some examples of EJB features and ways to get the same > > thing without > > > EJB's.. > > > > > > 1) Connection pooling: This is available everywhere, and > > everyone can reap the > > > benefits of it while being perfectly EJBless. > > > > > > 2) Transaction support: Stored procedures can take care of this. > > > 3) Caching of database objects: Pretty easy to implement > > > 4) Failover/load-balancing: As Kevin mentioned, works very > > nicely for > > > servlets. > > > > > > Having said all that though, I'm still going to try and use > > EJB's in my > > > current project, and port all the existing 'model' objects > > to become full > > > fledged EJB's. I'm hoping the advantages will become apparent then! > > > > > > Also, does anyone have any concrete examples of EJB's > > performance/scalability? > > > Has anyone deployed them in a high volume production > > environment? Most people > > > seem to be using them for prototyping and small scale > > projects, that I know > > > of... > > > > > > Hani Suleiman > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > > Duffey, Kevin > > > > Sent: Monday, October 09, 2000 1:22 PM > > > > To: Orion-Interest > > > > Subject: EJB vs Servlets > > > > > > > > > > > > Hey all, > > > > > > > > I know this is a little off-topic, but seeing as how Orion is > > > > about the only > > > > fully compliant EJB server, I figured this would be a better > > > > place to ask. > > > > > > > > Lately I have talked to a number of people that have been > > > > moving towards EJB > > > > and pulled back because they have found it to be more tedious > > > > to develop, as > > > > well as the end result was slower than just using Servlets. > > > > > > > > I ask this because it appears to me that the servlet engine > > > > (at least with > > > > 2.2) being able to be failed over, load-balanced, etc, seems > > > > to be quite as > > > > capable for scalability and fault-tolerance as the ejb engine > > > > used to be. I > > > > do realize that the EJB container offers transaction > > management, but > > > > connection pooling is available in the servlet engine at the > > > > server level as > > > > well. So, if you lose speed in development time and > > > > performance, what is the > > > > real benefits of moving to EJB? I should say this with > > > > caution..I am sure > > > > the EJB engine/container offers some things the servlet > > > > container doesn't, > > > > but I would think its possible to actually put those > > abilities in the > > > > servlet container. > > > > > > > > Anyways..I'll be interested in hearing any feedback on this. > > > > > > > > Thanks. > > > > > > > >
RE: EJB vs Servlets
The short answer to your questions is that you do not always need to use EJBs. In places where you don't need them it would be wasteful to use them. I use EJBs because I develop across clients for the enterprise. I don't know whether another developer will use my business logic in a servlet or a GUI client, or another bean. The fact is that because I wrote to a common interface (EJB) the logic can be used be any client. Another benefit for the enterprise by using EJBs is distributing the load across servers by splitting up the tiers physically. Actually it goes beyond that, you could actually have some servers running some EJBs, and other servers other EJBs. HTH Russ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin > Sent: Monday, October 09, 2000 3:01 PM > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > Actually, I know all about it. I have read up on it in those books and > others. Infact, we have already separated our code into those tiers but it > all runs in the servlet engine. This is what I am talking about. I am using > the Struts framework to allow all forms submitted to a single controller > servlet, which then calls upong action classes. Those action classes then > figure out what "session" class to call upon. These "session" classes are > our logic (ejb) code, but its not in the EJB container..it runs in our > servlet engine. It is separated, just not from the servlet engine itself. > However, by compexity of building EJBs, I think I mean what goes into it. > Instead of a single class, we would have 2 (or is it 3) interfaces and an > implementation class. To access it, its not as simple as a class/reference > variable to an object in the servlet engine, you have to do a lookup, > etc..its a bit more code. Sure..its not terribly complex, but compared to > doing it the way we are now, there is quite a bit more work involved than > what we are doing now. Also, actually testing and learning how exactly it > works is a process that will take a little time. All of these things add up. > What I am wondering is..is it really worth it if supposedly EJB doesn't > offer much in the way of performance..it just separates the logic into a > separate "tier" of servers. Our code is already separated long those tiers > now..and it will probably be easier for us to move to EJB than those that > have logic in their servlets. > > > > -Original Message- > > From: Russ White [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 09, 2000 11:32 AM > > To: Orion-Interest > > Subject: RE: EJB vs Servlets > > > > > > You should read up on J2EE so you can understand what separation of > > data/logic/presentation is all about. I would recommend any > > of the O'Reilly > > books on the subject(s). Also Development of EJBs is very > > simple. Especially > > with a good IDE like VA, Forte, or JBuilder. Orion even comes > > with a simple tool > > for creating very useful EntityBeans from a GUI. > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Duffey, Kevin > > > Sent: Monday, October 09, 2000 1:22 PM > > > To: Orion-Interest > > > Subject: EJB vs Servlets > > > > > > > > > Hey all, > > > > > > I know this is a little off-topic, but seeing as how Orion > > is about the only > > > fully compliant EJB server, I figured this would be a > > better place to ask. > > > > > > Lately I have talked to a number of people that have been > > moving towards EJB > > > and pulled back because they have found it to be more > > tedious to develop, as > > > well as the end result was slower than just using Servlets. > > > > > > I ask this because it appears to me that the servlet engine > > (at least with > > > 2.2) being able to be failed over, load-balanced, etc, > > seems to be quite as > > > capable for scalability and fault-tolerance as the ejb > > engine used to be. I > > > do realize that the EJB container offers transaction management, but > > > connection pooling is available in the servlet engine at > > the server level as > > > well. So, if you lose speed in development time and > > performance, what is the > > > real benefits of moving to EJB? I should say this with > > caution..I am sure > > > the EJB engine/container offers some things the servlet > > container doesn't, > > > but I would think its possible to actually put those > > abilities in the > > > servlet container. > > > > > > Anyways..I'll be interested in hearing any feedback on this. > > > > > > Thanks. > > > > > > > > > >
RE: EJB vs Servlets
hi Kevin, Could not agree with you more. I am developing a system using EJBs and it takes 2-3 times as much effort to do the same stuff what could have been done with jsps and servlets. The only saving grace seems to be OR mapping in EJB 2.0 where you can avoid writing JDBC code. I get a feeling of writing the same code three times ( in xml descriptor, ejb accessor methods, details java object as dependents cannot be directly exposed). I think the full use of EJB will come into effect if there are some cool GUI tools that allow to you drag and drop and wire a business application with all code automatically generated for you, for most of the code seems to be mechanical once the design is done. Would definately like to get a good answer from this forum. Cheers Krishnan -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Monday, October 09, 2000 10:22 AM To: Orion-Interest Subject: EJB vs Servlets Hey all, I know this is a little off-topic, but seeing as how Orion is about the only fully compliant EJB server, I figured this would be a better place to ask. Lately I have talked to a number of people that have been moving towards EJB and pulled back because they have found it to be more tedious to develop, as well as the end result was slower than just using Servlets. I ask this because it appears to me that the servlet engine (at least with 2.2) being able to be failed over, load-balanced, etc, seems to be quite as capable for scalability and fault-tolerance as the ejb engine used to be. I do realize that the EJB container offers transaction management, but connection pooling is available in the servlet engine at the server level as well. So, if you lose speed in development time and performance, what is the real benefits of moving to EJB? I should say this with caution..I am sure the EJB engine/container offers some things the servlet container doesn't, but I would think its possible to actually put those abilities in the servlet container. Anyways..I'll be interested in hearing any feedback on this. Thanks.
RE: EJB vs Servlets
You are talking about legacy support. I agree there. I haven't read the full spec of EJB, and I heard EJB 2.0 is even better. I would agree that overall its probably a better way to go, but, what does it really offer that you can't do in the servlet engine? If you can do fail-over/scalability, connection pooling, transaction management, and so on now, what benefits do you get from moving to EJB? Is it worth the bit slower process of developing them, and the slower performance? I think on our site we would be lucky to see 1000 users a day in 2 years from now, using our site, and we have about 50 or so a day now. So is there a big need for us to move to EJB in terms of future growth, or is the only "good" reason (for small to mediume sites) to move to EJB is just to separate your tiers amongst servers? > -Original Message- > From: Troy Echols [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 09, 2000 11:37 AM > To: Orion-Interest > Subject: Re: EJB vs Servlets > > > Might there be some benefit to using EJBs over servlets alone > if you want to > support various modes of connectivity to your business logic > (e.g., standalone > clients using JMS/CORBA/RMI in addition to web clients). > > Just my two cents worth. > > Troy > > > Hani Suleiman wrote: > > > > I've considered using EJB's a number of times for various > projects I'm > > involved in, but every time, I have to admit to myself that > it's more for the > > fun and coolness factor, than any real 'need' to use EJB's. > > > > In every case, I was able to implement a solution using > servlets with various > > caches to do whatever is needed much faster than an EJB > would do things (as > > far as I can tell, I haven't put this theory to the test > yet though!). Here > > are some examples of EJB features and ways to get the same > thing without > > EJB's.. > > > > 1) Connection pooling: This is available everywhere, and > everyone can reap the > > benefits of it while being perfectly EJBless. > > > > 2) Transaction support: Stored procedures can take care of this. > > 3) Caching of database objects: Pretty easy to implement > > 4) Failover/load-balancing: As Kevin mentioned, works very > nicely for > > servlets. > > > > Having said all that though, I'm still going to try and use > EJB's in my > > current project, and port all the existing 'model' objects > to become full > > fledged EJB's. I'm hoping the advantages will become apparent then! > > > > Also, does anyone have any concrete examples of EJB's > performance/scalability? > > Has anyone deployed them in a high volume production > environment? Most people > > seem to be using them for prototyping and small scale > projects, that I know > > of... > > > > Hani Suleiman > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > Duffey, Kevin > > > Sent: Monday, October 09, 2000 1:22 PM > > > To: Orion-Interest > > > Subject: EJB vs Servlets > > > > > > > > > Hey all, > > > > > > I know this is a little off-topic, but seeing as how Orion is > > > about the only > > > fully compliant EJB server, I figured this would be a better > > > place to ask. > > > > > > Lately I have talked to a number of people that have been > > > moving towards EJB > > > and pulled back because they have found it to be more tedious > > > to develop, as > > > well as the end result was slower than just using Servlets. > > > > > > I ask this because it appears to me that the servlet engine > > > (at least with > > > 2.2) being able to be failed over, load-balanced, etc, seems > > > to be quite as > > > capable for scalability and fault-tolerance as the ejb engine > > > used to be. I > > > do realize that the EJB container offers transaction > management, but > > > connection pooling is available in the servlet engine at the > > > server level as > > > well. So, if you lose speed in development time and > > > performance, what is the > > > real benefits of moving to EJB? I should say this with > > > caution..I am sure > > > the EJB engine/container offers some things the servlet > > > container doesn't, > > > but I would think its possible to actually put those > abilities in the > > > servlet container. > > > > > > Anyways..I'll be interested in hearing any feedback on this. > > > > > > Thanks. > > > >
RE: EJB vs Servlets
Actually, I know all about it. I have read up on it in those books and others. Infact, we have already separated our code into those tiers but it all runs in the servlet engine. This is what I am talking about. I am using the Struts framework to allow all forms submitted to a single controller servlet, which then calls upong action classes. Those action classes then figure out what "session" class to call upon. These "session" classes are our logic (ejb) code, but its not in the EJB container..it runs in our servlet engine. It is separated, just not from the servlet engine itself. However, by compexity of building EJBs, I think I mean what goes into it. Instead of a single class, we would have 2 (or is it 3) interfaces and an implementation class. To access it, its not as simple as a class/reference variable to an object in the servlet engine, you have to do a lookup, etc..its a bit more code. Sure..its not terribly complex, but compared to doing it the way we are now, there is quite a bit more work involved than what we are doing now. Also, actually testing and learning how exactly it works is a process that will take a little time. All of these things add up. What I am wondering is..is it really worth it if supposedly EJB doesn't offer much in the way of performance..it just separates the logic into a separate "tier" of servers. Our code is already separated long those tiers now..and it will probably be easier for us to move to EJB than those that have logic in their servlets. > -Original Message- > From: Russ White [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 09, 2000 11:32 AM > To: Orion-Interest > Subject: RE: EJB vs Servlets > > > You should read up on J2EE so you can understand what separation of > data/logic/presentation is all about. I would recommend any > of the O'Reilly > books on the subject(s). Also Development of EJBs is very > simple. Especially > with a good IDE like VA, Forte, or JBuilder. Orion even comes > with a simple tool > for creating very useful EntityBeans from a GUI. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > Duffey, Kevin > > Sent: Monday, October 09, 2000 1:22 PM > > To: Orion-Interest > > Subject: EJB vs Servlets > > > > > > Hey all, > > > > I know this is a little off-topic, but seeing as how Orion > is about the only > > fully compliant EJB server, I figured this would be a > better place to ask. > > > > Lately I have talked to a number of people that have been > moving towards EJB > > and pulled back because they have found it to be more > tedious to develop, as > > well as the end result was slower than just using Servlets. > > > > I ask this because it appears to me that the servlet engine > (at least with > > 2.2) being able to be failed over, load-balanced, etc, > seems to be quite as > > capable for scalability and fault-tolerance as the ejb > engine used to be. I > > do realize that the EJB container offers transaction management, but > > connection pooling is available in the servlet engine at > the server level as > > well. So, if you lose speed in development time and > performance, what is the > > real benefits of moving to EJB? I should say this with > caution..I am sure > > the EJB engine/container offers some things the servlet > container doesn't, > > but I would think its possible to actually put those > abilities in the > > servlet container. > > > > Anyways..I'll be interested in hearing any feedback on this. > > > > Thanks. > > > > >
Re: EJB vs Servlets
Might there be some benefit to using EJBs over servlets alone if you want to support various modes of connectivity to your business logic (e.g., standalone clients using JMS/CORBA/RMI in addition to web clients). Just my two cents worth. Troy > Hani Suleiman wrote: > > I've considered using EJB's a number of times for various projects I'm > involved in, but every time, I have to admit to myself that it's more for the > fun and coolness factor, than any real 'need' to use EJB's. > > In every case, I was able to implement a solution using servlets with various > caches to do whatever is needed much faster than an EJB would do things (as > far as I can tell, I haven't put this theory to the test yet though!). Here > are some examples of EJB features and ways to get the same thing without > EJB's.. > > 1) Connection pooling: This is available everywhere, and everyone can reap the > benefits of it while being perfectly EJBless. > > 2) Transaction support: Stored procedures can take care of this. > 3) Caching of database objects: Pretty easy to implement > 4) Failover/load-balancing: As Kevin mentioned, works very nicely for > servlets. > > Having said all that though, I'm still going to try and use EJB's in my > current project, and port all the existing 'model' objects to become full > fledged EJB's. I'm hoping the advantages will become apparent then! > > Also, does anyone have any concrete examples of EJB's performance/scalability? > Has anyone deployed them in a high volume production environment? Most people > seem to be using them for prototyping and small scale projects, that I know > of... > > Hani Suleiman > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Duffey, Kevin > > Sent: Monday, October 09, 2000 1:22 PM > > To: Orion-Interest > > Subject: EJB vs Servlets > > > > > > Hey all, > > > > I know this is a little off-topic, but seeing as how Orion is > > about the only > > fully compliant EJB server, I figured this would be a better > > place to ask. > > > > Lately I have talked to a number of people that have been > > moving towards EJB > > and pulled back because they have found it to be more tedious > > to develop, as > > well as the end result was slower than just using Servlets. > > > > I ask this because it appears to me that the servlet engine > > (at least with > > 2.2) being able to be failed over, load-balanced, etc, seems > > to be quite as > > capable for scalability and fault-tolerance as the ejb engine > > used to be. I > > do realize that the EJB container offers transaction management, but > > connection pooling is available in the servlet engine at the > > server level as > > well. So, if you lose speed in development time and > > performance, what is the > > real benefits of moving to EJB? I should say this with > > caution..I am sure > > the EJB engine/container offers some things the servlet > > container doesn't, > > but I would think its possible to actually put those abilities in the > > servlet container. > > > > Anyways..I'll be interested in hearing any feedback on this. > > > > Thanks. > >
RE: EJB vs Servlets
You should read up on J2EE so you can understand what separation of data/logic/presentation is all about. I would recommend any of the O'Reilly books on the subject(s). Also Development of EJBs is very simple. Especially with a good IDE like VA, Forte, or JBuilder. Orion even comes with a simple tool for creating very useful EntityBeans from a GUI. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin > Sent: Monday, October 09, 2000 1:22 PM > To: Orion-Interest > Subject: EJB vs Servlets > > > Hey all, > > I know this is a little off-topic, but seeing as how Orion is about the only > fully compliant EJB server, I figured this would be a better place to ask. > > Lately I have talked to a number of people that have been moving towards EJB > and pulled back because they have found it to be more tedious to develop, as > well as the end result was slower than just using Servlets. > > I ask this because it appears to me that the servlet engine (at least with > 2.2) being able to be failed over, load-balanced, etc, seems to be quite as > capable for scalability and fault-tolerance as the ejb engine used to be. I > do realize that the EJB container offers transaction management, but > connection pooling is available in the servlet engine at the server level as > well. So, if you lose speed in development time and performance, what is the > real benefits of moving to EJB? I should say this with caution..I am sure > the EJB engine/container offers some things the servlet container doesn't, > but I would think its possible to actually put those abilities in the > servlet container. > > Anyways..I'll be interested in hearing any feedback on this. > > Thanks. > >
RE: EJB vs Servlets
Title: RE: EJB vs Servlets I've considered using EJB's a number of times for various projects I'm involved in, but every time, I have to admit to myself that it's more for the fun and coolness factor, than any real 'need' to use EJB's. In every case, I was able to implement a solution using servlets with various caches to do whatever is needed much faster than an EJB would do things (as far as I can tell, I haven't put this theory to the test yet though!). Here are some examples of EJB features and ways to get the same thing without EJB's.. 1) Connection pooling: This is available everywhere, and everyone can reap the benefits of it while being perfectly EJBless. 2) Transaction support: Stored procedures can take care of this. 3) Caching of database objects: Pretty easy to implement 4) Failover/load-balancing: As Kevin mentioned, works very nicely for servlets. Having said all that though, I'm still going to try and use EJB's in my current project, and port all the existing 'model' objects to become full fledged EJB's. I'm hoping the advantages will become apparent then! Also, does anyone have any concrete examples of EJB's performance/scalability? Has anyone deployed them in a high volume production environment? Most people seem to be using them for prototyping and small scale projects, that I know of... Hani Suleiman > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Duffey, Kevin > Sent: Monday, October 09, 2000 1:22 PM > To: Orion-Interest > Subject: EJB vs Servlets > > > Hey all, > > I know this is a little off-topic, but seeing as how Orion is > about the only > fully compliant EJB server, I figured this would be a better > place to ask. > > Lately I have talked to a number of people that have been > moving towards EJB > and pulled back because they have found it to be more tedious > to develop, as > well as the end result was slower than just using Servlets. > > I ask this because it appears to me that the servlet engine > (at least with > 2.2) being able to be failed over, load-balanced, etc, seems > to be quite as > capable for scalability and fault-tolerance as the ejb engine > used to be. I > do realize that the EJB container offers transaction management, but > connection pooling is available in the servlet engine at the > server level as > well. So, if you lose speed in development time and > performance, what is the > real benefits of moving to EJB? I should say this with > caution..I am sure > the EJB engine/container offers some things the servlet > container doesn't, > but I would think its possible to actually put those abilities in the > servlet container. > > Anyways..I'll be interested in hearing any feedback on this. > > Thanks. >
