Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Why are Java developers ignorant of JMS and messaging in general?
At 8:42 AM on Jan 29, 2006, Roger Voss wrote:
Fresh Jobs for Developers Post a job opportunity
In the '90s I slaved away building distributed software founded on DCOM, C++, ATL, etc.
These days, though, everything I do with JMS and Java goes so much better. The programming technology is superior and most importantly, messaging is superior to RPC - or the anti-pattern of DCOM (which consist of the notion of trying to span synchronous object interfaces across the unreliable network).
I certainly encounter other Java programmers that share my sentiments toward JMS and messaging. But I'd have to say most developers I rub shoulders with don't particularly groc messaging.
The current AJAX fad is perhaps swinging the pendulum a bit my way but the XmlHttpRequest mechanism has no queuing, guaranteed delivery (persistent queues), publish/subscribe notification via server-side push, nor routing via message filtering. So it falls quite a bit short of JMS and true messaging in the feature department. It's basically just async RPC.
Also, with true messaging systems you get very powerful capabilities such as the ability to bridge message flows from one queue into another in a transparent fashion. (I use this all the time to develop and test new software off of live production message flows without impacting the production system.)
Message bridging also figures prominently in how we administratively set up our queues and topics. Instead of having an app connect to several different queues (or go back to recode the app to connect to a new queue that is now required as a source input), we just add a bridge rule in the messaging server to route messages from the desired queues into the one queue that the app was written to know about. Over the lifetime of applications this eases deployment as a given app will hardly ever need to interact with more than one queue and perhaps one topic. Bridging can take care of all other configuration needs as to what messaging traffic flows where and what component processes it. I look back on the RPC scene and think, my how pathetic all that tight coupling is.
So a message is a kind of "tangible object" that can be manipulated in all manner of powerful ways, while an RPC payload is too ephemeral to be useful for much or very accessible to do much of anything with.
Here's a suggestion for a new year's resolution - learn more about messaging and the JMS specification.
45 replies so far (
Post your own)
Re: Why are Java developers ignorant of JMS and messaging in general?
Why? Because its harder than synchronous RPC.For a developer who spends most of their timw just coding simple method calls, networks and their problems are an alien environment. When faced with a calling a remote service of some kind they typically have to choose between an RPC/RMI type solution or a message/JMS type solution.
A synchronous RPC call looks like a local simple method call, you call it, it does something, it returns and your program flow continues. Simple and Easy.
An asynchronous messaging call requires firing off a 'message', writing a completely separate handler to receive the result, somehow coding the client to wait for the result (depending on the requirement), ... Its much harder.
So, most developers choose the RPC call. It just fits better with how they think about coding. And its simpler. In the end, we are mostly lazy people
Can it be solved? The only possibility I can see is if major language changes occurred (ie. not Java) to expose the async nature of messaging in a nice simple way. I'm not going to attempt any syntaxes though
Re: Why are Java developers ignorant of JMS and messaging in general?
Totally agree with this post. Once learned, JMS and messaging become powerful tools in every Java developer's toolbox. I spent a lot of years architecting without messaging and regret not learning it sooner.
One thing to add in regards to:
> The current AJAX fad is perhaps swinging the pendulum
> a bit my way but the XmlHttpRequest mechanism has no
> queuing, guaranteed delivery (persistent queues),
> publish/subscribe notification via server-side push,
> nor routing via message filtering. So it falls quite
> a bit short of JMS and true messaging in the feature
> department. It's basically just async RPC.
Just one more reason to check out Flex 2 which supports pub/sub, server push, connecting to JMS or any other backend messaging service. Read more:
Flex Message Service - Pub/Sub for RIA
-James
Disclaimer: I work for Adobe, yet my thoughts are my own
Re: Why are Java developers ignorant of JMS and messaging in general?
IMHO, JMS is one of the most useful Java APIs. I've been using it with MQ Series (now WebSphere MQ) in a high-volume stock trading system. Works great. Asynchronous nature of messaging helps in building losely-coupled applications.Re: Why are Java developers ignorant of JMS and messaging in general?
The Cajo Project and Blitz Javaspaces are well worth a look as well for inter-process/machine communicationRe: Why are Java developers ignorant of JMS and messaging in general?
+1Async persistent messages are great for decoupling.
We also use synchronous non-persistent messages with a "time-to-live" instead of rpc.
A piece of cake to administer, scale up the number of backend services etc.
Haven't used publish/subscribe yet, but I can think of some useful scenarios for that too.
This is SOA in a nutshell.
The only alternative worth mentioning is ebXML Messaging Service in reliable messaging mode. Might be worth mentioning that web services (whatever that really is) only work well with messages (style document/literal), not as SOAP (object access).
In "real OO", don't you think of sending messages between objects rather than calling methods?
Currently engaged in Weffo web architecture outline and the Flying Saucer xhtml and xml+css renderer
Re: Why are Java developers ignorant of JMS and messaging in general?
Do you know of any market research or developer surveys that show the percentage of projects that use messaging?It would be interesting to see if the perception of messaging ignorance is true.
.
Re: Why are Java developers ignorant of JMS and messaging in general?
> Why? Because its harder than synchronous RPC.Agreed
> A synchronous RPC call looks like a local simple
> method call, you call it, it does something, it
> returns and your program flow continues. Simple and
> Easy.
>
> An asynchronous messaging call requires firing off a
> 'message', writing a completely separate handler to
> receive the result, somehow coding the client to wait
> for the result (depending on the requirement), ...
> Its much harder.
>
> So, most developers choose the RPC call. It just fits
> better with how they think about coding. And its
> simpler. In the end, we are mostly lazy people :-)
>
> Can it be solved? The only possibility I can see is
> if major language changes occurred (ie. not Java) to
> expose the async nature of messaging in a nice simple
> way. I'm not going to attempt any syntaxes though ;-)
Note that Lingo makes it very easy for folks to stick to a POJO style way of programming yet reuse the power of JMS underneath to deal with load balancing, reliability, persistence, XA/transactions as well as to provide asynchronous method calls...
http://lingo.codehaus.org/
There is support for asynchronous request-reply methods too if you use a listener as a parameter
Iona
Open Source the Enterprise Way
Open Source SOA using Apache ActiveMQ, Apache Camel, Apache CXF and Apache ServiceMix
Re: Why are Java developers ignorant of JMS and messaging in general?
> The current AJAX fad is perhaps swinging the pendulum> a bit my way but the XmlHttpRequest mechanism has no
> queuing, guaranteed delivery (persistent queues),
> publish/subscribe notification via server-side push,
> nor routing via message filtering. So it falls quite
> a bit short of JMS and true messaging in the feature
> department. It's basically just async RPC.
BTW you can use Ajax nicely with JMS via the following JavaScript library
http://activemq.org/Ajax
Iona
Open Source the Enterprise Way
Open Source SOA using Apache ActiveMQ, Apache Camel, Apache CXF and Apache ServiceMix
Re: Why are Java developers ignorant of JMS and messaging in general?
Roger,Totally agreed that people need to think of behavioral distribution in terms of messages, not the anti-pattern of RPC / DCOM / RMI / etc. (which can all be lumped together as "low level technologies for synchronously waiting on a method call to occur on some other box").
I have a slide in one of my presentations that says point blank: "There are only two things that you can distribute in a distributed system: State and behavior." The point is that sometimes it's more efficient to have localized behavior and mobile state, and sometimes it's more efficient to have localized state and mobile behavior. The best systems (IMHO) are those that realize that neither of these is a one-size-fits-all, and they look to architect around the inherent evil of distribution by explicitly deciding what data to distribute, and when (and where) to distribute behavior.
The real problem is that once people think in terms of RPC (e.g. DCOM), they are -- for the most part -- ruined and worthless for building distributed systems. In a way (to draw a poor analogy) it is like teaching someone to build multi-threaded systems by showing them how to put "synchronized" onto every single method, but if every single method is synchronized then by definition it cannot be a multi-threaded system (i.e. there would be no thread level concurrency).
Similarly, RPC causes people to think of distribution as a means to be able to force some piece of functionality -- at great cost -- to be run in a particular location, which in net has absolutely no value.
I'm not sure how to educate the industry about how best to build distributed applications. I have been speaking at industry events on the topic now for four years or so, and it seems to have made some impact, but the damage done by CORBA / DCOM / RMI will last at least another entire generation of programmers.
Peace.
Re: Why are Java developers ignorant of JMS and messaging in general?
Can you share with us your experiences with jms-products?Which (opensource) product is the best? (I'm currently looking for an implementation of jms)
Kees.
Re: Why are Java developers ignorant of JMS and messaging in general?
> Can you share with us your experiences with> jms-products?
> Which (opensource) product is the best? (I'm
> currently looking for an implementation of jms)
>
> Kees.
Kees,
You know, this particular posting must have struck a chord with folks - in less than 24 hours it has already had over 6000 hits. If you ever post anything on JavaLobby and monitor the hit rate accumulation, 6000 in such a short time is really quite something. So I'll take the bold leap and assume this translates into some rather intense interest in messaging on behalf of the Java development community?
So, yes, Kees, am thinking I should write up an experience report and see if could get it posted on JavaLobby with a bit of prominence so that it would stay on the front page for a while - say like the Spotlight features section (though a simple paper might not be cool enough for that). At a minimum I'll post something back to this thread, though.
Coincidentally I was just today participating in a customer survey with Tibco. These guys need to do a better job of promoting their product to the Java development community. You don't see their advertisements that much for JMS messaging in the various Java online venues. I think the hit rate on this thread indicates they're missing opportunity. (BTW, I evaluated several commercial JMS offerings and considered an open source implementation - I'll cover the logic of my decision matrix of why I finally drilled down to Tibco EMS. It'd be great for a new JMS product comparison to be done, though, as JMS products and offerings have evolved and expanded since I conducted my particular evaluation.)
BTW, I'm framing out a design for a specialized bridge implemented with Java NIO such that AJAX web clients using XmlHttpRequest could become full participants to JMS messaging. One of my long standing desires is to see server-side push event notification come to the web. To do that there needs to be queuing on the server-side (which JMS provides), and ideally a persistent (or mostly persistent) connection from the client to the server.
The latter requirement has always been a stumbling block as persistent connections consume resources on the server (in the case of old Java socket servers that resource would be a thread per connection), thus imposing a significant limitation on scaling. Yet with an effective use of Java NIO I think it should be possible to get ~10,000 persistent connections per a single 3 GHz server. So this Java NIO-implemented bridge would handle thousands of client connections while funneling them all down to a modest number of connections against the actual JMS server (cluster) itself.
For a lot of small and medium businesses on the Internet with modest traffic levels this kind of bridge would be quite workable. Or for enterprise web sites that have a specialized audience (which my company has such sites). There are lots of applications folks would like to do that could benefit from effective server-side push notification.
Oh, a side benefit to an AJAX-to-JMS bridge is that the Message Driven Bean (MDB) could then be used to process queued messages as published by AJAX clients. The MDB is the simplest - and IMHO - the coolest kind of EJB to write. A MDB is a full blown EJB that can use declarative transactions, security, JNDI, JDBC, Hibernate, distributed caching, access other session beans, etc., etc. EJB3 will simplify coding MDBs still further as will then be able to use dependency injection and EJB3 ORM persistence. Yet even the 2.1 MDB is really startling easy. (Frankly I see the MDB and Hibernate ORM as the two factors that made using J2EE app servers worth while - that and the JMX mbean services we write to do specialized device interactions.)
Re: Why are Java developers ignorant of JMS and messaging in general?
I think what would be interesting is to take the ubiquitous Java Pet Store example and show how one would go about designing it based on messaging principles rather than RPC.Is such a design overkill for Java Pet Store? Sure it is, but a lot of things are overkill for Java Pet Store, but the application it presents is pretty darn generic, and that's the kind of applications most people are creating.
You don't have to actually create a JPS implementation, but some code examples that compare and contrast the RPC approach to JPS and a messaging approach would help hilight the distinctions between the implementations, as well as the benefits and trade offs.
Almost all of the books I've seen on JMS are on the mechanics of JMS, but not the process and design.
Because, particularly for your off the shelf web application, the call from the browser to the app IS an RPC, essentially, and it's easy to see how that gets propagated back as more procedure calls.
If my servlet makes an RPC call to a Session Bean, vs queuing up a JMS message and waiting for a result, what's the real difference? They're both, essentially, synchronous.
If the Session Bean call is dispatched to a load balanced cluster, how does that scale less than a JMS solution? Is it simply easier to manage the JMS solution perhaps?
So, it's not clear to me when talking RPC vs Messaging that we're talking Apples to Orange vs Red Delicious and Yellow Delicious, particularly for interactive applications where someone is stuck waiting on the other end of the SUBMIT button. For truly asynchrounous systems, sure, fire and forget and happy day.
Anyway, that's the part I'm interested is seing better explained and illustrated.
Re: Why are Java developers ignorant of JMS and messaging in general?
Will,There are by now quite a number of white papers, blogs, and books written on the subject of AJAX where various use cases for web applications are presented arguing the need for an ability for asynchronous interaction with the server (i.e., a departure from the traditional synchronous HTTP page-based interaction that has characterized the web experience to date).
The typical argument revolves around the notion of maintaining fluidity of experience for the user. IOW, the app remains responsive to user-driven interaction even when data has been submitted to the server and some result may be pending.
Consequently, building web UIs that remain perpetually responsive to user interaction may require some total rethink of how web interfaces are designed. I build all my C# .NET rich client applications (that interact with the middle-tier via JMS) on this exact paradigm - I suspect the web developers can rise to the occasion as well.
As I pointed out, though, even with this asynchronous capability, the AJAX XmlHttpRequest mechanism is still minus quite a number of desirable features as found in JMS implementations.
BTW, the manner I use JMS is to devise event driven distributed applications. Consider a single Swing GUI application and the way events and the observer pattern are used internally to disseminate activity in a loosely coupled, asynchronous manner. Well, when you reorient the way you think about the problem, you can build large scale distributed network applications in this exact same manner. Messaging systems such as JMS serve as the bi-directional event dissipation layer.
The kind of distributed apps I'm talking about are in the aggregate more sophisticated than typical web application architecture - but that's not to say JMS-like capabilities couldn't be brought into play to improve web apps with some nice new behavior. I think the easiest way to make that happen is to construct a Java NIO bridge that can glue XmlHttpRequest into a middle-tier JMS server. For all intents and purposes the AJAX web app then becomes a full-fledged JMS messaging application with all the capabilities that that entails.
The web server, such as Tomcat, and the web framework, such as Tapestry or Wicket, are still used to deliver the web pages to the browser. But the XmlHttpRequest interactions are thereafter routed into the Java NIO bridge. Message Driven Beans are used to process incoming messages. Pretty much anything executing in the middle-tier or even the back end (for example, we let PL/SQL code running in Oracle publish messages into our Tibco JMS topics via an AQ-to-JMS bridge) can publish to reply queues and/or topics in order to "server-push" messages (events) down to the web client.
If a framework such as Tapestry or Wicket is used, then the entire application on the server-side can be implemented in Java. The JavaScript and DHTML in the browser-based web client is the sole outlier - but that's the nature of the AJAX beast.
Re: Why are Java developers ignorant of JMS and messaging in general?
> Will,>
> There are by now quite a number of white papers,
> blogs, and books written on the subject of AJAX where
> various use cases for web applications are presented
> arguing the need for an ability for asynchronous
> interaction with the server (i.e., a departure from
> the traditional synchronous HTTP page-based
> interaction that has characterized the web experience
> to date).
But even this asynchronous behavior is, in truth, synchronous. The only thing that is not happening, is the event loop isn't being locked. While it may appear to the user as an asynchronous event, to the programmer, the call itself is essentially a call to a synchronous system.
And that's my lament.
I consider your most base asynchronous example: Send an email. You make a connection, plop in your message, and off you go then. The email is on its way, and ideally will arrive.
Asynchronous, to me, implies I don't care about the results, at least not "immediately". If my message was that important, I'd call the party up on the phone, or use AIM. But if the result can wait, the plop it in the out box and wait until the result comes back. As you said, an event driven architecture.
But, if I'm on the internet looking at toasters, I, as a user, would like to know, now, whether the blue toaster was in stock. I'd like know, now, when it will arrive. I'd like to know, now, how much my order is going to cost.
All of those "nows" are a sense of immediacy that I require out of the application, as the result of each of these steps determines my next step. They're implicitly synchronous operations.
In my experience, most of people interactions with computers are similiarly synchronous. We humans aren't naturally asynchronous beings, regardless of how much multitasking we're doing today.
Certainly each of those requests (stock status, shipping status, order total) could have been processed on the back end by an asynchronous mechanism.
But that's the rub.
As a programmer, I could have written a routine that bundles up my stock request into a message, plops in onto an appropriate queue, and then blocked waiting for a response, using whatever mechanism is appropriate. But, also, as a programmer, I would have hidden most of that detail. In my servlet I'd probably have some method someplace like getStatus(String partNo) that's called like any other synchronous method. Barring a failure, when that method returned, I'd have a nice status string that I could format and render in my result page.
But lets say that getStatus was a Session Bean on an EJB server.
I'd make the getStatus call, and the proxy would connect to the EJB server, probably using a connection pool and queue. The EJB server would take the request, queue it, find an available Session Bean, and hand off the request to it. The Session Bean would grab a DB connection from a pool, again queueing up for it, and send a SQL request to the DB. The DB would parse the request, ask for some disk pages, and sleep while the OS loads those pages into memory. Once loaded, the OS notifies the thread, the DB continues it's processing, returns the data, and so on down the chain. Behind all this the various servers and OS's are scheduling threads and processes on to their respective runtimes.
Every point along the line is, essentially, an asynchronous request. But, to me, the programmer, it all appears as a synchronous call. Even if I write to my own message queues, I'd wrap them up to make them appear synchronous.
Now, with a classic GUI application, it can be a first class citizen in a messaging architecture, simply because it's already based on a messaging system. A topic or queue monitor/poller is yet another source of events along with the keyboard and mouse to which the application may respond, and creating that monitor is reasonably trivial by forking a thread and opening a persistent, bidrectional connection to the server (say, a JMS server in this case).
But browsers, as you've noted, aren't there yet. Pushing data to a browser is not a simple thing. I don't even know if the event queue in the browser is a first class citizen, not that familiar with the browser API that level. So, pardigmatically, most browser applications, even AJAX ones (from what I've seen), rely on synchronous calls.
The asynchronous nature of AJAX is the fact that XMLHttpRequest is asynchronous to the browsers event loop. If I have a button in my browser that sends an XMLHttpRequest with a callback, and I click that button 5 times, I just basically opened up 5 sockets to the server, and sent 5 synchronous messages, each waiting for a response.
So, to me, getting an AJAX application involved as a first class citizen in a messaging infrastructure seems quite involved, and certainly goes against the grain of how web servers and web browsers are designed to operate, as they rely on the stateless and even connectionless requeest/response paradigm (i.e. they don't need a permanent connection to the server).
But the fundamental question I have is the actual benefit from a developers points of view, and how (or even whether) to leverage for conventional web based applications. How, for example, is a JMS design any better from a good modern stateless design?
Let's take the example I had earlier. When the request arrives at the server, the container calls my servlet, the servlet calls the EJB, and the EJB calls the DB. Classic 3 tiers.
Scaling that, I can add a load balancer to the front to distribute raw HTTP requests to any available servlet container. The EJBs can be fronted by a cluster aware EJB proxy, load balancing EJB requests across several EJB servers, and even the DB can, to a lesser extent, be load balanced.
All of that distribution is essentially transparent to my synchronous application code.
That's why I'm interested in a MOM (Message Oriented Middleware) based JPS (Java Pet Store). We all understand how JPS works, the foundations of it architecture, the design choices made, etc.
But most importantly, we understand the domain of the JPS problem. By understanding its problem we can pay more attention to the architecture decisions made for a MOM based JPS rather than trying to learn both the MOM part and the application part.
The original question for this thread was why don't more Java developers use JMS. And most of the replies are that JMS is a wonder, etc. But if that wonder can't readily be applied to something as mundane as JPS, which I assert is the kind of applications a vast majority Java coders write, then perhaps that alone explains the lack of JMS knowledge. It simply doesn't apply to most scenarios.
But if it takes a rethinking of the application from the MOM point of view, I'm curious to see a reasonably realistic example of such a system and representative results of its benefits.
I'm stuck in the synchronous world. I can see how MOM can help in some small aspect to many systems, a small part driven using JMS. But not as a fundamental part underlying the design. And I can see how where while JMS would be useful to some parts of a system, how a person without JMS knowledge or experience would bludgeon their way through and not even miss JMS. Which can perhaps be another reason why many Java developers don't use it.
So, I understand if you have an applicaiton that is bubbling soup of event listeners, and a fat GUI application is a perfect example of such, that MOM can be a fundamentel design choice for the back end (though I have questions about call granualarity, method dispatch, etc).
But for something as inherently synchronous as a typical Web application, it's hard to see, when designing from the ground up, how mating a MOM design to a synchronous front end simplifies the application. It seems more to me to complicate it with no particular gain.