Java IoT Authors: Pat Romanski, Yeshim Deniz, Liz McMillan, Elizabeth White, Zakia Bouachraoui

Related Topics: Java IoT

Java IoT: 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 http://java.sys-con.com/general/gasstation.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.

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 (http://yakovfain.com) 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 http://opentrade.sourceforge.net.

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 (http://jencks.org/)

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 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!

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 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!

IoT & Smart Cities Stories
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
SYS-CON Events announced today that IoT Global Network has been named “Media Sponsor” of SYS-CON's @ThingsExpo, which will take place on June 6–8, 2017, at the Javits Center in New York City, NY. The IoT Global Network is a platform where you can connect with industry experts and network across the IoT community to build the successful IoT business of the future.
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Disruption, Innovation, Artificial Intelligence and Machine Learning, Leadership and Management hear these words all day every day... lofty goals but how do we make it real? Add to that, that simply put, people don't like change. But what if we could implement and utilize these enterprise tools in a fast and "Non-Disruptive" way, enabling us to glean insights about our business, identify and reduce exposure, risk and liability, and secure business continuity?