Is EJB needed if clustering is involved?

[Hu Chong]

From the software architect of my current project, he is saying that we should use ejb since there are clustering of the application servers. And, we only need to deploy the ejb once only.
But, I am thinking otherwise, since the ejbs are going to be accessed by only one applications and not many applications. We can just use a Front Controller servlet and struts actions. Just that anytime we have new changes, we have to deploy the war file to every application server.

[Chris Mathews]

Originally posted by Hu Chong:
From the software architect of my current project, he is saying that we should use ejb since there are clustering of the application servers. And, we only need to deploy the ejb once only.

I strongly disagree with this. EJB is no more clusterable than Servlets/JSP Applications. Take a look at my recent article for the JavaRanch Journal where I discuss my stance on when to use EJB.

[Kyle Brown]

I agree with Chris. Clustering is a dumb reason to use EJB since Servlet applications are clusterable as well, and scale linearly the same way EJB applications do.
Kyle

[Tonny Tssagovic]

Hello Chris and Kyle;-)
Could you guys be more sepecic about how Servlets do scale? is it kinda using jk_module with Apache to distribute the load to different tomcat instances? How about clustering business logic without using EJBs, could you give us some examples?
Thanks a lot!

[David Harkness]

Originally posted by Tonny Tssagovic:
How about clustering business logic without using EJBs, could you give us some examples?

It more depends on your needs than on some standard. EJB covers business logic (session and message beans) and persistence (entity beans). They are often used together, but it's not a requirement. If you want to have users with accounts, address, phones, orders, etc. for a huge ecommerce site, you would definitely find EJBs useful, even session beans fronting a custom JDBC, JDO or Hibernate layer. If your needs aren't quite so robust, you could skip EJBs.
Adding clustering to the mix simply complicates both options (with or without EJBs) in different but related ways. With entity beans you need to think about caching issues or lock at the database. With JSPs you have the HTTP session to deal with. We have a two-node cluster for dev and setup WebLogic to set a session cookie that pegs the browser to the node they first hit. And we're using optimistic concurrency with a long version number field with entity beans.
To me, saying "Because the environment is clustered, we should use EJBs" is like saying "Because your car has four-wheel drive, you should paint it blue."

[David Harkness]

Originally posted by Chris Mathews:
Take a look at my recent article for the JavaRanch Journal where I discuss my stance on when to use EJB.

Two thumbs up on the article. As with every technology, there is a time and a place when EJBs are appropriate.
[ January 31, 2004: Message edited by: David Harkness ]

[Kyle Brown]

Originally posted by Tonny Tssagovic:
Hello Chris and Kyle;-)
Could you guys be more sepecic about how Servlets do scale? is it kinda using jk_module with Apache to distribute the load to different tomcat instances? How about clustering business logic without using EJBs, could you give us some examples?
Thanks a lot!

There are two ways to do clustering and scaling. One is with a plugin to your HTTP server, where the HTTP Server sprays requests to a number of appliation server instance, while the other is where you don't have an intermediate HTTP server and a dedicated IP Sprayer (like a Cisco router, or Big IP) sprays to a number of application servers. The details depend on the particular application server you are using.
Kyle

[Tonny Tssagovic]

Thanks a lot for your replies Kyle and David
Well I already know about http and IP sprayers (I think they are sometimes called layer 4 switches, and there are even L7 switches that route based on info at the 7.th layer!) , but I was asking about scalling between the web container and the application container (I mean something like EJB "stand-alone" containers). This actually raises another question. Should spraying be done at the front (L4 switch) or at the web server (http sprayer) or after the web container (Like at the EJB layer, or custom distributed business objects if there is no EJB-like clustering light-framework available) beside the Database cluster. Are there any general guidelines to help make the right decision of where clustering should be done?.
PS: Do you guys have any experiance with Linux Virtual Server

[Chris Mathews]

Originally posted by Tonny Tssagovic:
This actually raises another question. Should spraying be done at the front (L4 switch) or at the web server (http sprayer) or after the web container (Like at the EJB layer, or custom distributed business objects if there is no EJB-like clustering light-framework available) beside the Database cluster.

This really depends on the application...
If you have distributed clients then obviously you will need to cluster at the business tier. However, if the client resides on the same machine as the business tier (which is the case for most J2EE applications) then it would be sufficient and preferable to cluster at the web tier.
When clustering web applications, I prefer using dedicated hardware for load balancing rather than relying on the http server, though in most cases either strategy would work well. The important thing to remember when you use load balancing is to include redundancy for the load balancer itself. It does no good to cluster the hell out of your application if your load balancer is a single point of failure.

[Kyle Brown]

Listen to Chris. The man gives good advice. Also, another combination that we usually recommend (we call it the "gold standard" in WebSphere) is to use two hardware routers (one as a warm backup for the other) and at least two web servers spraying to at least two application servers. If you add an HA database in the mix, then you have *no* single points of failure.
Kyle

[Tonny Tssagovic]

Thanks for your replies Chris and Kyle ;-)
Well I know that redundancy is the key issue to assure high availability. I would add 2 connections from different ISPs, and probably all the servers have 2 of everything, NIC connected to different switches and 2 power supplies etc. It is rather the trade-off that bugs me, and want to know at which layer a cluster is mostly used.

I prefer using dedicated hardware for load balancing rather than relying on the http server

Do you mean L4 switch like UltraMonkey or which uses LVS Cisco LocalDirector thatsits before the web servers? Could you give a reason why you prefer this set-up? And I think this solution does not offer fail-over of servlet sessions.. It needs a more complex solution that works at a higher OSI layer
Thanks a lot
Cisco System's Local Director
[ February 02, 2004: Message edited by: Tonny Tssagovic ]