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:

http://vossnet.org/jms-links.html

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.

Roger,

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 :))

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.

Ron,

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

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.

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.

Most likely, Jencks (http://jencks.org/)

What JTA implementation are you planning on using?

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!

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!