To say that any tool or framework is just 'better' is ridiculous. It always depends on the situation, architecture, etc. You don't necessarily want to use a hammer to drive a screw.
I wrote JBoss in Action, so I obviously like the JBoss technology, but I'll be the first to say that JBoss can be overkill in many situations. For example, for the last two sites I've developed, it made more sense to build with Grails and deploy on a standalone Tomcat instance.
Its a bit unfair to say that all you get when using JBoss is EJB and JMS. JBoss offers many services and features, including:
- Servlet/JSP container
- JNDI
- EJB
- JTA
- clustering
- caching
- JMS
- Datasource / Resource management
- JMX integration
- OSGi support
- web services
- portals
- Web Beans (Seam)
- Some administrative consoles
- an IoC container
- etc.
The thing that attracts many architects to JBoss is its flexibility. It uses a plugin architecture that allows you to add and remove services. As other have said, in uses Tomcat as its Servlet container, so you can literally whittle JBoss down to where it is practically just a Tomcat server. What is the benefit of doing this? Future proofing if you think that you're going to utilize other features of JBoss.
These services in JBoss come pre-integrated and strive to provide a consistent deployment model that minimizes your effort in writing application logic or configuration to integrate them yourself. That being said, other frameworks like Spring also do a great job of supporting a uniform ways of integrating many popular libraries and frameworks. But since they focus on integrating 3rd party libraries, the interoperability between services is up to you. Because JBoss is building the services and the integration platform, they spend time developing (and providing support) for interoperability.
Some questions to ask when making a choice are:
- Are you going to use standard JavaEE architectural components like EJB?
- BTW, EJB can be run in standalone Tomcat using the JBoss embedded container, so if EJB is all you're using, then you still don't have to use JBoss
- Are you going to utilize Web Services, Portals, JMS?
- Are you looking into building with Web Beans or Seam?
- What deployment platforms (Tomcat, JBoss, etc) does your IT, support, and development staff currently use? If you are going to use something new, you will incur additional cost to learn the new platform.
- If you're selling a product that customers will deploy, what impact will it have on the customers' IT organization.
- Are you going to need paid support?
- You can find support for Tomcat through many companies (including Red Hat I believe).
- You'll need to compare the costs, because I don't think JBoss support is cheap, though I haven't looked up prices lately.
- Will you need to do any sophisticated clustering?
- JBoss has some wonderful clustering capabilities, and you'll probably get good clustering support through Red Hat. Though, for full disclosure, I've never done any complex clustering with any other frameworks to be able to compare.
- Are you going to need advanced transaction management (distributed transactions, 2-phase commits, etc)
Not to sound like a shameless plug, but the first chapter of JBoss in Action is available for free on the Manning website. Though we don't do a direct comparison between JBoss and other applications servers and deployment environments in the chapter, we do talk about the architectural differences a bit, which is relevant to your question.
