Comments on: In defence of EJBs http://www.magpiebrain.com/blog/2004/01/30/in-defence-of-ejbs/ Sam Newman's blog Mon, 06 Oct 2008 23:38:33 +0000 http://wordpress.org/?v=2.5.1 By: KungFooCoder http://www.magpiebrain.com/blog/2004/01/30/in-defence-of-ejbs/#comment-172 KungFooCoder Tue, 03 Feb 2004 21:21:35 +0000 http://www.magpiebrain.com/2004/01/30/in-defence-of-ejbs/#comment-172 Actually I?d have to disagree there. There was a time when I said that, and in some instances that?s still true. If you?re running on a single box, then Hibernate or some other ORM is a better option. However if you need to scale large like CheapTickets.com has to do, then there is no single box on the planet except for an IBM big iron machine that will handle that stuff. CheapTickets and companies like them use EJB server farms to handle processing. SOAP is just an object access protocol similar to RMI/IIOP that EJBs use. Also SOAP and web services are not exactly ?fast?. For a few transactions per second they?re ok, but once you start getting hundreds or thousands per second then they become a bottleneck. SOAP was design for interoperability between platforms like java to .NET. EJBs a much better in terms of performance & system resources for serving enterprise data & business logic. JMS is part of the J2EE structure. Technical it uses EJBs as well. What EJBs offer are the ability to scale since a client requests an object from a group of machines. Need more performance? Add a box. Also most EJB containers have sophisticated object caching so you don?t hit the RDBMS every time you get an object. DBs take a pounding on most apps. So anything you can do to speed them up is a plus. Also EJBs have a security layer by design. EJBs are portable to other app servers and DB servers. Now having praised them, let me beat ?em for a sec. They suck when you have to learn the technology and/or build stuff. To me, building EJBs is like you hard coding SOAP envelopes into your calling classes or in separate XML files. Any time I see a point where I have to write XML files by hand, that?s a time I know that someone hasn?t built a tool for the technology. XML files and service specs aren?t created so you code them by hand. They?re made so a computer application can be design that can talk to the spec and create that stuff for you. Again, this is why JBuilder has actually pryed Intellij IDEA from my hands. They do an exceptional job creating EJBs, descriptors, and JBoss descriptors for me so I can focus on the app and test cases. There I get pissed at SUN is when I talk to my .NET friends around the corner and they tell me COM and .NET remoting is a snap. The .NET SDK, VM, and compiler is basically the same as Java. There no reason that SUN can?t do something as powerful that is much easier to use. :) Actually I?d have to disagree there. There was a time when I said that, and in some instances that?s still true. If you?re running on a single box, then Hibernate or some other ORM is a better option. However if you need to scale large like CheapTickets.com has to do, then there is no single box on the planet except for an IBM big iron machine that will handle that stuff. CheapTickets and companies like them use EJB server farms to handle processing. SOAP is just an object access protocol similar to RMI/IIOP that EJBs use. Also SOAP and web services are not exactly ?fast?. For a few transactions per second they?re ok, but once you start getting hundreds or thousands per second then they become a bottleneck. SOAP was design for interoperability between platforms like java to .NET. EJBs a much better in terms of performance & system resources for serving enterprise data & business logic. JMS is part of the J2EE structure. Technical it uses EJBs as well. What EJBs offer are the ability to scale since a client requests an object from a group of machines. Need more performance? Add a box. Also most EJB containers have sophisticated object caching so you don?t hit the RDBMS every time you get an object. DBs take a pounding on most apps. So anything you can do to speed them up is a plus. Also EJBs have a security layer by design. EJBs are portable to other app servers and DB servers. Now having praised them, let me beat ?em for a sec. They suck when you have to learn the technology and/or build stuff. To me, building EJBs is like you hard coding SOAP envelopes into your calling classes or in separate XML files. Any time I see a point where I have to write XML files by hand, that?s a time I know that someone hasn?t built a tool for the technology. XML files and service specs aren?t created so you code them by hand. They?re made so a computer application can be design that can talk to the spec and create that stuff for you. Again, this is why JBuilder has actually pryed Intellij IDEA from my hands. They do an exceptional job creating EJBs, descriptors, and JBoss descriptors for me so I can focus on the app and test cases. There I get pissed at SUN is when I talk to my .NET friends around the corner and they tell me COM and .NET remoting is a snap. The .NET SDK, VM, and compiler is basically the same as Java. There no reason that SUN can?t do something as powerful that is much easier to use. :)

]]> By: Jared Odulio http://www.magpiebrain.com/blog/2004/01/30/in-defence-of-ejbs/#comment-171 Jared Odulio Sat, 31 Jan 2004 06:02:18 +0000 http://www.magpiebrain.com/2004/01/30/in-defence-of-ejbs/#comment-171 Kyle, definitely no. When performance is high priority it is wiser to stay away in EJB further as matter of fact. Kyle, definitely no. When performance is high priority it is wiser to stay away in EJB further as matter of fact.

]]> By: Kyle Adams http://www.magpiebrain.com/blog/2004/01/30/in-defence-of-ejbs/#comment-170 Kyle Adams Fri, 30 Jan 2004 18:12:08 +0000 http://www.magpiebrain.com/2004/01/30/in-defence-of-ejbs/#comment-170 Aren't there situations where performance is of high priority, and the processing hit you take when using XML (SOAP, JMS) necessitates a switch to EJBs called via local interface? Aren’t there situations where performance is of high priority, and the processing hit you take when using XML (SOAP, JMS) necessitates a switch to EJBs called via local interface?

]]> By: Jared Odulio http://www.magpiebrain.com/blog/2004/01/30/in-defence-of-ejbs/#comment-169 Jared Odulio Fri, 30 Jan 2004 15:56:25 +0000 http://www.magpiebrain.com/2004/01/30/in-defence-of-ejbs/#comment-169 "In this way I could eliminate vicious app servers and the need to cluster it"... Perhaps the context wasn't clear. Of course, we can't eliminate clustering per se. How much processing power do I need for a SOAP, JMS or Jabber cluster compared to the ones pockmarked with EJBs in it? We usually deploy non-trivial server applications(e.g. AI in Prolog etc.). We found EJB to be overkill in that environment and yet it eats up unnecessary resources. “In this way I could eliminate vicious app servers and the need to cluster it”...

Perhaps the context wasn’t clear. Of course, we can’t eliminate clustering per se. How much processing power do I need for a SOAP, JMS or Jabber cluster compared to the ones pockmarked with EJBs in it? We usually deploy non-trivial server applications(e.g. AI in Prolog etc.). We found EJB to be overkill in that environment and yet it eats up unnecessary resources.

]]> By: Sam Newman http://www.magpiebrain.com/blog/2004/01/30/in-defence-of-ejbs/#comment-168 Sam Newman Fri, 30 Jan 2004 15:41:41 +0000 http://www.magpiebrain.com/2004/01/30/in-defence-of-ejbs/#comment-168 I fail to see how the use of SOAP, JMS or Jabber eliminate the need for clustering. Non-trivial J2EE applications typically need to be run on clusters because they need the power, and given the ecomomies of scale it is far cheaper to run on several cheap computers than one big one - just look at the recent OSX cluster running on G5 desktop machines, or googles linux server farm. I fail to see how the use of SOAP, JMS or Jabber eliminate the need for clustering. Non-trivial J2EE applications typically need to be run on clusters because they need the power, and given the ecomomies of scale it is far cheaper to run on several cheap computers than one big one – just look at the recent OSX cluster running on G5 desktop machines, or googles linux server farm.

]]> By: Jared Odulio http://www.magpiebrain.com/blog/2004/01/30/in-defence-of-ejbs/#comment-167 Jared Odulio Fri, 30 Jan 2004 15:34:26 +0000 http://www.magpiebrain.com/2004/01/30/in-defence-of-ejbs/#comment-167 I could write several cluster apps/services down from ground up and take control of everything. Instead of letting some EJB explain to me what fucked up what. As an advocate of XP, everything should be simple and we found simplicity in SOAP, JMS or even Jabber. In this way I could eliminate vicious app servers and the need to cluster it and that's easier. I could write several cluster apps/services down from ground up and take control of everything. Instead of letting some EJB explain to me what fucked up what. As an advocate of XP, everything should be simple and we found simplicity in SOAP, JMS or even Jabber. In this way I could eliminate vicious app servers and the need to cluster it and that’s easier.

]]> By: Sam Newman http://www.magpiebrain.com/blog/2004/01/30/in-defence-of-ejbs/#comment-166 Sam Newman Fri, 30 Jan 2004 15:19:59 +0000 http://www.magpiebrain.com/2004/01/30/in-defence-of-ejbs/#comment-166 Well, how about clustering app servers? EJBs transaction management makes this fairly easy... Well, how about clustering app servers? EJBs transaction management makes this fairly easy…

]]> By: Jared Odulio http://www.magpiebrain.com/blog/2004/01/30/in-defence-of-ejbs/#comment-165 Jared Odulio Fri, 30 Jan 2004 15:14:25 +0000 http://www.magpiebrain.com/2004/01/30/in-defence-of-ejbs/#comment-165 Unfortunately, those very specific circumstances can be easily addressed by SOAP or JMS alone. I may have tried to use EJB in the wrong place but nobody is certain where is the right place. Even the 'right place' does not immediately justify the use EJB as a solution. Right now, I am still looking for a good problem that can be solved by EJB hands down. Unfortunately, those very specific circumstances can be easily addressed by SOAP or JMS alone.

I may have tried to use EJB in the wrong place but nobody is certain where is the right place. Even the ‘right place’ does not immediately justify the use EJB as a solution.

Right now, I am still looking for a good problem that can be solved by EJB hands down.

]]>