Open discussion of IT Business

Enterprisey IT Journal

Subscribe to Enterprisey IT Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Enterprisey IT Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Enterprisey IT Authors: Skytap Blog, Application Security, Lori MacVittie, Andy Klee, Yakov Fain

Related Topics: RIA Developer's Journal, Java EE Journal, SOA & WOA Magazine, Enterprisey IT Journal

RIA & Ajax: Article

Look Mom, No Application Servers, Look...MOM!

'What do you think of application servers?' The most popular answer was, 'I don't need no stinkin' application server.'

In the unlikely event that you're not familiar with my gas station, you can find my previous essays at Recently, I've conducted a small survey among my truck drivers. I asked them just one question: "What do you think of application servers?" The most popular answer was, "I don't need no stinkin' application server." And truck drivers usually know what they're talking about!

You may think that now I'll start selling one of the popular application frameworks. Wrong! The idea of these frameworks was nice: get back from complex containers to programming POJOs. But while trying to provide alternatives to container services, each of these frameworks ran into the short-blanket syndrome: something is always sticking out. XML is sticking out big time!

To simplify Java programming, developers are paying the high price of adding unmanageable amounts of XML descriptors, mappings, wirings, and other plumbing. Twenty years ago .ini files were widely used, 10 years ago .properties replaced them, and after the Y2K problem was solved, people were bored and started investing their time in XML.

It started quite innocently: XML is better than HTML, then DTD came about, XSLT, XPATH, XQuery, XML farms, XML processing hardware, and on, and on, and on. Basically, the proper way to name today's POJO is XPOJO. You know what I mean. Hopefully, Java annotations will slow down the X-hype. I'm already using Java 5 in my agile business, and as soon as Mustang is released, big corporations will switch to Tiger.

Let's return to the main subject. One of my readers asked if I was planning to write a piece on how to select an application server. I answered, "No, because I'm not sure if they're needed."

I believe that at least a half of today's business applications don't need one. In my gas station, I'm going to implement a set of client/server applications with rich clients talking to each other using Java messaging, and most likely, I'll need to implement an Enterprise Service Bus (ESB) to communicate with a couple of old applications that I inherited from the former owner of my gas station.

My newly developed applications will use rich application clients living in a Web browser, but they'll run in their own virtual machines (no AJAX by the pumps!). I've already started working on a more serious manuscript on RIA (see To make a long story short, I'm planning to use/implement SOA, RIA, MXML , JWS, JMS, MOM, JNDI, ESB, JTA, DAO, JDBC, DBMS, and a Web Server. Raise your hand if you know how to spell out each of the acronyms used in this article so far.

I know, I know. Ten years ago, people who could spell out VB and SQL were able to find a nice paying job in a heartbeat. Forget about it. I can recommend a handy Web site called In some cases it gives you too many versions for your acronym, but key in JTA and you'll find that it stands for Java Transaction API (it's right above Japan Toilet Association). Since I'm not going to use the J2EE application server, I have to find transaction support somewhere else.

Consider the use case of a typical business application without an application server. The front-end reacts to various events by putting messages (Java value objects or key-value pairs) into a remote message queue (orders, requests, etc.). A server-side JMS listener picks them up from the queue and starts business processing the messages received. This is where transaction support comes in handy. For example, from a business perspective saving a customer's order in a database and making a JMS call for further processing can be considered one unit of work, which has to be rolled back if any of these actions fails. That's why a JMS listener has to be able to begin, commit, and roll back transactions.

Communicating with the database can be done using a simple DAO/JDBC combo. Create a tiny .properties file with a dozen parameters (the data source to use, maybe some external URLs, and a couple of others). That's it. This is what I call real POJO programming. Did I miss anything? Oh yeah, JMS is just an API, so we need a transport/storage for our messages, and this is what Message-Oriented Middleware (MOM) is for.

While there are several Open Source JMS/MOM implementations on the market, I'm planning to use ActiveMQ from Logic Blaze. The product has been on the market for years, has good reputation, supports JTA/XA, and has a large user community. Look at the ActiveMQ list of features, and you'll see that it offers more than any small business needs. Another pro is that the same vendor offers an Open Source JBI-based ESB implementation called ServiceMix. But this is a topic for future discussions. And the best part is that this middleware is available for free.

Not everyone may like this architecture, but let me remind you, we're talking about a small business here. One of my readers sent me an e-mail asking, "What if this application is supposed to be used by thousands users?" I wish... This is just a gas station! When you're architecting your next application, try not to get into a Google/Amazon state of mind unless you work for them. If you're not dealing with thousands of users, just use a simple Data Access Object, write a couple of SQL statements here and there, and make a dozen JDBC and JMS calls. And MOM will be a good, reliable foundation for creating loosely coupled applications with robust transactions, persistence, and failover support.

More Stories By Yakov Fain

Yakov Fain is a Java Champion and a co-founder of the IT consultancy Farata Systems and the product company SuranceBay. He wrote a thousand blogs ( and several books about software development. Yakov authored and co-authored such books as "Angular 2 Development with TypeScript", "Java 24-Hour Trainer", and "Enterprise Web Development". His Twitter tag is @yfain

Comments (11) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
RogerV 04/18/06 02:13:38 AM EDT

Hi Greg. In my case I design distributed apps using JMS for marine terminal operations and all my nodes run on the same network. Hence my JMS clients don't have to go thru a firewall to interact with the JMS server.

However, a typical JMS server can be started up to accept connections on an arbitrary port so you could accept unencrypted connections on port 80 and SSL connections on port 443. As long as your firewall doesn't enforce strict HTTP protocol over port 80 then you should be fine.

My company uses Tibco EMS which is a proprietary JMS that has excellent .NET client that is 100% managed code. They also support .NET Compact Framework on WinCE, which we happen to use on embedded industrial microcomputers.

I've seen info that ActiveMQ supports .NET clients now so you might look at that for an open source implementation.

If you need enterprise capabilities, you'll certainly find it in the Tibco product, though.

As to payload, we pretty much stick to XML, which is easy to process in both .NET and Java in various ways. Sometimes I use XML object serialization and sometimes I just use XPath. I stick with JMS properties that are string values as that works well with any client language bindings.

You can check out some more of my writings on JMS related matters here:

Greg 04/17/06 01:02:55 PM EDT

Hi RogerV,
We're doing something similar in terms of .NET client talking to a JEE server. Currently we're using a more custom protocol for having the .NET client talk to the server, but we'd like to move to JMS. One thing that I'm worried about is firewall issues. I'd love to hear your thoughts about JMS implementations, etc. that bridge that gap, and any lessons learned about having .NET and JEE interoperate in that way.

Yakov Fain 04/16/06 08:26:24 AM EDT


In this article I do not ask to abandon app servers. But I do believe that half of the applictions do not need them. I don't buy your arguments about JBoss saving your messages and moving the bad ones into a dead letter queue: this functionality is supported by any MOM server.
As to other advantages of the app servers that you've mentioned, I'll just remind you that we are talking about gas station here. I guess, I can survive without clustering and HA support.
What I do need though, is a new AC unit. It's getting hot in the summer in my convenience store :))

RogerV 04/15/06 12:50:51 PM EDT

Hi Yakov.

As we've chatted on this subject before on other forums, you know that I'm a big fan of JMS and asynchronous messaging in general. I'm the guy that does rich clients using .NET Winforms and then JMS as my distributed computing communication protocol. So I'm in lock step with your sentiments on both of those choices: messaging and rich clients (as opposed web browser thin client).

However, I don't agree much with your sentiment to abandon application servers. For the series of distributed applications I've created over the last 3 1/2 years using this messaging paradigm, I've found my JBoss application server to be an extremely crucial component in the overall mix.

IMO, The EJB 2.0/2.1 spec of the Message Driven Bean (MDB) is the most successful and useful EJB that was defined for JEE. They are very simple to program and yet can avail themselves of all JEE services. I can easily achieve the objectives you mention of processing an in-coming message while in turn interacting with the database (and in my case it is also frequently an interaction with a distributed cache). All these interactions can be done under an XA transaction by simply specifying a declaration in the deployment descriptor of the MDB. Very simple indeed.

When an XA roll-back occurs, the msg. remains safely in the queue. JBoss can be configured to retry it multiple times. After exhausting retries, JBoss moves the msg. to a dead letter queue - where can be configured to raise administrative alert. Sometimes when our back-end database gets really bogged down, some transaction might fail and get rolled back. Yet on some successive retry, the operation will finally pop on through. It's nice to have this bit of resiliency as this system.

Another group in my company chose to use JMS messaging but also decided to code everything in .NET - their choice is essentially equivalent to the one you say your making in your article. So they have no nice application server to host things in. Therefore they are always reinventing these various wheels that I, in contrast, just take for granted by choosing to use a JEE application server. Database connection pooling (with automatic reconnect mgt.), declarative XA, JNDI to lookup other services to consume, application hot deployment (this is a biggie), clustering and high availability (another biggie), distributed caching, - I could go on and on listing the things I use daily but those guys have to code themselves or else do without.

I really struggle to try and understand why it is people do such things to themselves. Their excuse is that they simplify by having C# .NET as their universal programming language at all end-points. But by tossing aside Java in the middle-tier they have lost a great deal indeed as .NET provides them practically nothing other than database access APIs.

Frankly I just don't get what people are talking about in terms of JEE complexity (the issue you allude to). I use JMX MBeans, JMS MDBs, and Hibernate persistence (I've purposely avoided session beans and entity beans). In my view, and from 20 years experience, server-side programming doesn't get any easier than this combo. It's truly an embarrassment of riches to be a JEE developer in such a context.

Yakov Fain 04/15/06 11:27:47 AM EDT


I have no intention to create my own app server. All the components mentioned in the article are open source tools available on the market. My POJOs will contain the business logic only

Ron Smith 04/15/06 10:40:20 AM EDT

I completely agree with your feelings about XML Hell. I keep saying "I thought I was a Java programmer, not an XML programmer".

Still, what you are basically saying is, "write your own app server". I'll admit it's nice that most of the pieces of an app server have been decoupled to the point that you can mix and match. Unfortunately, I have been the one that comes in behind a project like this and I had to figure out how frankenstein pieced his monster together. Sometimes, the users requirements change (the gas station decided it needed to sell sushi -- its a local joke in Memphis, don't ask) or the app needs to scale (gas stations do sometimes turn into oil companies, it seems) or who knows what.

Maybe roll-your-own is a first step towards a better standard. Personally, I am more and more disappointed in the directions that Java is going and I'm not sure I want to stay on for the ride.

Nambi Sankaran 04/15/06 01:40:48 AM EDT

Hi Yakov

Using MOM (JMS) with POJOs, and plain XML for data transfer, is perhaps the best way to build an application.

Using this approach I am able to build a trading platform. Presentation of data to the user is done by creating javascript widgets in a browser.

Our home page is

Though this is not a gas station, I am sure this application can be scaled to the demands of larger volume websites such as amazon.

Yakov Fain 04/14/06 09:20:14 PM EDT

Most likely, Jencks (

Greg 04/14/06 07:12:55 PM EDT

What JTA implementation are you planning on using?

SYS-CON Brazil News Desk 04/13/06 10:44:08 AM EDT

In the unlikely event that you're not familiar with my gas station, you can find my previous essays at Recently, I've conducted a small survey among my truck drivers. I asked them just one question: 'What do you think of application servers?' The most popular answer was, 'I don't need no stinkin' application server.' And truck drivers usually know what they're talking about!

SYS-CON India News Desk 04/13/06 10:18:44 AM EDT

In the unlikely event that you're not familiar with my gas station, you can find my previous essays at Recently, I've conducted a small survey among my truck drivers. I asked them just one question: 'What do you think of application servers?' The most popular answer was, 'I don't need no stinkin' application server.' And truck drivers usually know what they're talking about!