Skip to main content

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



In the unlikely event that you're not familiar with my gas station, you can find my previous essays at http://jdj.sys-con.com/read/category/1142.htm. 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 http://theriabook.com). 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 acronymfinder.com. 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.
© 2006 SYS-CON Media Inc.

Comments

Guy said…
Hi,

Nice to see that more people are coming to the same conclusion. You can even design your application independent of any JMS provider like here
Guy said…
Here is an open-source JTA/XA with JDBC/JMS drivers included; ideal for J2EE without application server and free of charge: Atomikos

Disclaimer: I work for them...

Popular posts from this blog

Most "Productive" Cities In The World?

Based on a just released Brooking Institution report and this CNBC report . To be exact, they are comparing per-capita GDP and changes in employment data from 2010 to 2011 among the 200 largest metropolitan areas of the world. Please download the full report here (5MB) , it's very good. These are the metro areas that surprised me in a nice way: Hartford and Buffalo. Both cities are a little bit run-down. But I guess the surrounding wealthy towns more than make up for it. Didn't know Chinese political powerhouse Beijing is almost at the bottom (187/200) still. Indian outsourcing capital of the world Mumbai is second to the bottom, and Cairo, knowing it's poor, is at the very bottom? 

18 Rules of Management (in Chinese)

18 則好用的管理定律 1. 活力曲線( 10% 淘汰率法則) 奇異公司每年會針對各事業單位的主管打分數,區分出 ABC 三個不同等級的績效表現。最傑出的 A 級員工必須是事業單位中的前 20% ; B 級員工是中間的 70% ; C 級員工約 10% ,奇異以常態分配的鐘形活力曲線( Vitality Curve )來呈現這種概念。 A 級員工將得到 B 級員工 2 ~ 3 倍的薪資獎酬,而 C 級員工則有遭到淘汰的危機, 活力曲線是年復一年、不斷進行的動態機制,以確保企業向前邁進的動能。 2. 手錶定理 一個組織不要同時設定兩個目標。一次戴兩支手錶不但不能讓自己知道更準確的時間,還會失去準時的信心。 對同一組織採用兩種管理方法,或設置兩個不同的目標,組織就無所適從了。 3. 酒與污水定律 把一匙酒倒進一桶污水中,得到的是一桶污水;把一匙污水倒進一桶酒中,得到的還是一桶污水。 組織裡永遠都有幾個麻煩人物,他們存在的目的似乎是為了把事情搞砸。主管要及時處理,才能避免它迅速傳染。 一個正直能幹的人進入一個混亂的部門很可能被吞沒,而一個懶惰鬼很快能把高效率的部門變成一盤散沙。 4. 不值得定律 一個人會用敷衍了事的態度來從事自認為不值得做的事,因此管理者要適當的分配工作。 讓成就慾較強的員工帶頭完成具有一定風險和難度的工作,讓依附慾較強的員工融入團體中共同工作。 5. 金魚缸法則 魚缸是透明的,不論從哪個角度觀察,裡面的情況都一清二楚。增加工作流程的透明度吧!工作透明度高,領導者就被置於全體部屬的監督之下。 強化領導者的自我約束,也增強了組織的凝聚力。 6. 洛伯定理 對管理者來說,要緊的不是你在場時的情況 ,而是你不在場時發生了什麼。如果你只想讓部屬聽你的,那麼當你不在身邊時,他們就不知道應該聽誰的。 7. 鰷魚效應 鰷魚因為個體弱小而採取集體活動,以強健者為自然首領。當首領的行動發生紊亂,鰷魚仍然會盲目追隨。 部屬的悲劇總是領導者造成的,部屬覺得最沒勁的事,是跟著一位差勁的領導者。 8. 木桶定律 一隻木