When implementing a service-oriented architecture (SOA), there is always the choice between components (included modules of reusable functionality) versus services (deployed once, reused by calls over the network).

How do you know which one to choose? There is a lot of things to consider, but these will give you a head-start:

• if there is a need for different configuration parameters per consumer, favor a component
• if performance of remote network calls is problematic, favor a component
• if deploy-once is crucial, favor a service
• if you have no control over the deployment parameters, favor a service (e.g., if the provider is a third party)
• to dynamically switch between both, choose service component architecture (SCA)

Also, keep in mind that components require setting up the required infrastructure (database schema, queues, etc) for each deployment.

Probably most readers of this blog post will know about components, because you probably use TransactionsEssentials as a component

In an attempt to 'increase performance', many people will try to hack around in JMS - thereby falling into the idempotent receiver trap by checking for duplicate message receipt. The consequence: scalability actually degrades!

Fortunately, the best way to enjoy reliable messaging is also the simplest one, and it scales linearly.

We've uploaded a slideshare presentation on developing transactional applications with Spring. Enjoy!

Here is another excellent article about the cost of application servers, and why a paradigm shift is needed with lighter-weight alternatives:

http://www.tomcatexpert.com/blog/2010/06/03/migrating-jee-applications-tomcat-motivation-migrating

Interesting note: the author used to work at Bea, so he definitely knows what he is talking about;-)

Check out http://www.tomcatexpert.com/blog/2010/07/07/how-migrate-jee-applications-tomcat for a nice discussion on how to migrate from jee to a light-weight alternative like Tomcat - with Atomikos for JTA if needed.