What are benefits of JBoss AS-based application architecture?

Question

I am trying to understand what does JBoss AS can bring into the project, comparing to standalone architecture?

My model application is a solid thing, starting, running and stopping as a whole and solely at the host. It has a database storage, and communicates to user and other servers, clustering required. It has web-part. It's just a standard big application.

JBoss for me is a shell for (in general) multiple applications, providing my application with some standard services. This shell is also a solid thing - "get all or nothing", something can be turned on/off (influencing your app unpredictably, or influencing other part of the JBoss) or replaced (very hard and is already kind a hack) with different version or other module.

Standalone application for me is something combined of pieces with glue among them (Spring if you like) with IoC wiring. We can get everything we could have with JBoss, but separately. Spring or other glue serves here like an application server, but it's thinner and we still can replace parts or even Spring itself (IoC wiring is straightforward from coding point of view).

For me, standalone, AS-free approach gives more control and flexibility. And further more, last versions of JBoss AS are purely documented, some features (most interested) are not documented at all.

So, why somebody still choose JBoss - what are benefits?

I favors more standalone application approach, but need more facts to understand better and convince others.

Answer 1

It seems to me that what you are describing is the classic choice between best-of-breed (collecting all the parts and glueing them together your self) versus integrated stack (JBoss wrote all the parts and integrated them for you). This is a debate that will rage on for eternity. If best-of-breed is working for you then stick with it.

JBoss is a J2EE container. Take a look at the J2EE spec if you are unfamiliar with it. Basically Sun's community process came up with an development framework that contains components that you may be interested in when creating large scale apps. J2EE contains multiple sub specs such as Servlets, EJB, JTA, JMS, and a whole host of other alphabet soup technologies. If you aren't using any of these technologies then you do not need a J2EE container. If you are just interested in using Servlets and JSPs then you are better off using a servlet container such as Tomcat, Jetty, Resin, etc.

Providing enterprise features such as scalability, transactional support, federated user management, etc. are difficult. A J2EE container provides a standard level of these features. If you can find them elsewhere to a level that meets your satisfaction then more power to you.

Answer 2

Hi Seas,

I would say the only reason to use JBoss is if you need to access the JEE services (like Messaging, container-managed transactions and similar).

Keep in mind JBoss is (roughly described) Tomcat plus JEE services (yes, yes, I know, this is a very simplified approach, just bear with me). I mention this as I would say your decision is:

• If you only need IoC and some other capabilites you can get with Spring and Tomcat, go with that
• If you application requires JEE services, use JBoss

Keep in mind you can always start with the basic system (Spring + Tomcat) and move to JBoss if required later on. Nothing forbids that.And probably starting with that approach will show you if you really need the JEE services or you were over-engineering the solution.

Answer 3

You can also pick and choose if you are running inside JBoss. If you are happy with the JBoss services you can use them or deploy some others if you don't like the one JBoss provides for you.

Starting from the JBoss minimal configuration and building up your own configuration should give you a setup where you don't have services running that you don't need. Personally, I like to know what my AS is running, so I prefer to start from minimal configuration adding only the necessary parts.