Spring with JBoss with no EJB's - advice needed

Hi,

I was happily setting up our new wep-app architecture with Tomcat, Spring and Hibernate - using 3 tiers.

It has now been suggested that we move to use JBoss or similar, and utilize the strengths of an application server.

I am completely new to J2EE (apart from above), and am struggling to see how it all fits together ie Spring and JBoss. We would like to avoid EJB's if possible.

Would really appreciate it if anyone can offer any advice or experience, please, on how best to set things up, what parts of the app server to utilize, how transactions will work etc..

Many thanks,

David

I'm using Jboss for web applications without EJB's. Also relatively new to J2EE, and probably not using all the facilities of the appserver that might be useful.

To start with, your app should pretty much transfer without any changes. Possibly just a few tweaks to the deployment descriptors.

A couple of things in JBoss (beyond the servlet container) that I do use is setting up datasources, and access them in spring using JndiObjectFactoryBean; and using JBoss to run a scheduled task with a SAR (service archive).

You've also got JTA if you need distributed transactions, JMS if you want messaging, etc. etc. I don't currently use either of those.

If you need any further help with JBoss config on the bits I'm familiar with, I'll be happy to help.

Quote:

---

It has now been suggested that we move to use JBoss or similar, and utilize the strengths of an application server.

---

This is mostly a scentence keeping me alarmed. What me bug is the 'use JBoss or similar' and 'utilize the strengths'. A application server is quite a time-eater. Many things offered by JBoss may be also utilized using Tomcat and it seams that mostly people just use an application-server because its a real J2EE thing.

So what is it, you are actually trying to do?

Quote:

---

It has now been suggested that we move to use JBoss or similar, and utilize the strengths of an application server.

---

I agree with Martin. This sounds like classic markitecture: going for a full J2EE stack when it may not be required just because of the mystical benefits of an app server. Even if your app server costs $0, the greater complexity (if you don't need it) will still cost you, as license cost is only a part of the story.

Look at your requirements. If you want a typical web app, you may be better off with a web container. If you need distributed transactions or messaging, you probably need an app server.

J2EE without EJB provides some guidance as to when an app server is required.

I am going to agree with Rod and Martin on this one. Do you require any J2EE features that are not provided by Tomcat such as EJB? If not, my advice is stick with Tomcat.

Yesterday afternoon, we spent three hours and moved a customer off of JBoss/Spring and onto Tomcat/Spring. The customer is over the moon with the performance increase and lower memory utilisation this small amount of effort gave him. This is part of a larger movement for my company as we move many customers off JBoss and onto Tomcat. We are seeing better per request performance and much better memory utilization.

The fact is Tomcat/Spring just rocks. All my devs are happy coding away on this platform and the customers are loving the increase in performance for such a minimal amount of effort. For all new projects that don't need J2EE features we are saving ourselves the trouble and starting out on Tomcat.

Hi All,

Thanks for the replies...perhaps I can explain what we're doing a little more and why we were thinking of J2EE server.

We have our own job-processing server, and have various clients that use and administrate it - some are still thick-apps, but we are moving everything to web based. So we currently use Tomcat as our webserver, which receives requests from the clients and talks to our job-processing server.

Now we want to grow things and support usage in the enterprise. As well as handling the higher volume of requests, we want to provide clustering, load-balancing, fail-over, on BOTH the web end AND the job-processing end. The web side I understand somewhat. Whether we can use a J2EE server to provide clustering and load-balancing of our own job-processing server I am trying to figure out (and a little confused on!).

Any advice would be greatly appreciated!!! From the above, do you think a J2EE server would help?

Thanks,

David

Quote:

---

Originally Posted by Rod Johnson

Quote:

---

It has now been suggested that we move to use JBoss or similar, and utilize the strengths of an application server.

---

I agree with Martin. This sounds like classic markitecture: going for a full J2EE stack when it may not be required just because of the mystical benefits of an app server. Even if your app server costs $0, the greater complexity (if you don't need it) will still cost you, as license cost is only a part of the story.

Look at your requirements. If you want a typical web app, you may be better off with a web container. If you need distributed transactions or messaging, you probably need an app server.

J2EE without EJB provides some guidance as to when an app server is required.

---

Hi Rod, i totally agree with you but what about applications that need JTA transactions from the application server? Is it possible to use Spring + Hibernate in such configuration? If the answer is 'yes', how can this be configured with Spring's IOC?

Quote:

---

Hi Rod, i totally agree with you but what about applications that need JTA transactions from the application server? Is it possible to use Spring + Hibernate in such configuration? If the answer is 'yes', how can this be configured with Spring's IOC?

---

You could achieve that with Spring/Tomcat/JOTM using Spring's JtaTransactionManager strategy.

http://jotm.objectweb.org/current/jo...mcat-jotm.html