Why package JBoss with integrated Tomcat or Jetty?

[bugsbunny]

Hello,

Why is JBoss packaged with integrated Tomcat or Jetty? Shouldn't the application server sit behind the firewall separate from the servlet container? Unless, you want JBoss to be in front of the firewall so that the outside world can call the methods inside your EJB container, but that's a huge security risk. Either way I don't get it. Maybe JBoss with integrated Tomcat is only for development purpose?

Thanks
Stephen

[jonlee]

This is really a two stage answer.

Putting the servlet container in front of the firewall doesn't provide you with that much more security. The servlet container still needs to communicate with the EJB container to look up resources and then connect to them. You can configure the firewall to only accept requests from the servlet container's physical server but it starts becoming complex when you have multiple servlet containers, clusters and so on. In any case, the upshot is that you need to punch a hole in the firewall to allow incoming requests to the EJB container.

Having the servlet container outside the firewall also exposes your servlet container so it can be subverted or otherwise tampered with - and then an attacker could make calls to your EJBs with the subverted servlet container.

Normally, you would have both servlet and EJB containers behind the firewall and protected. You punch a hole in your firewall to only allow access to http and https for your servlet container. This is much more restrictive on the access that an external attacker has to your infrastructure. You can also front-end this through a webserver such as Apache using the AJP13 connector which also restricts modes of access to your infrastructure.

Why couple them?

With a coupled container set, you have greater sharing of libraries so there is less resource burden. You will find with any reasonable set of applications that you have helper classes that need to exist on both containers - beans, data classes and so on. It is also less adminstration trying to keep classes in synch so you don't have the serialUID problem. The connections between the client application and the EJB no longer need to go across the wire so you have reduced latency and hence faster response. The containers often require the same infrastructure to keep them happy so they also share infrastructure classes.

All commercial J2EE servers bundle both the EJB container and the servlet container in the same VM - WAS 5.0, SilverStream and BEA. You can assume that the resource economies are the major reason for bundling them.

Hope that goes some way to answering your question.

[mikefinn]

Why separate them? Unless you need the servlet container on a separate box for performance or security reasons (physical partioning of tiers), there is no reason not to use the integrated server. Web tier > EJB tier calls are all in VM. Security is integrated. Management and administration are easier since the web container is controlled by JMX, etc.

As long as you have a decent DMZ (as you should if you're exposing corporate data), JBoss can live there in its entirety, if that's what you need. Just allow HTTP traffic from the Internet into the DMZ JBoss. Otherwise put it on your private.

mike

[bugsbunny]

That's what I forgot, Apache! You're right, Apache stays outside the firewall with http and https open to the world. JBoss/Tomcat stays inside the firewall. Apache routes requests to the servlet container via the connector. Now it's all clear. Thanks dude.

[frank.eggink]

The benefit of deploying both the web tier and the EJB on one server is in the fact you do not need to serialize data transferred between the two tiers. The serialization would drain resources and hamper performance. Preventing that is the basic idea in running these both tiers in one JVM.

Wrt. security: go for the DMZ (= two firewalls). That's the most common security architecture and solves your problem.