That's an interesting idea of using JMX as a primary application interface.
It somewhat routes around the development and deployment model (since JMX components are server centric rather than application centric).
But it does have the benefit of being portable and cross container, something, as you noted, that can't be said for either JMS or Remote EJB. (By portable I mean runtime portable, where a single client can talk to multiple hosts of different vendors).
You can MAKE (sorta) Remote EJB (or even JMS I suppose) container portable, but only if you include their runtime jars with your client (and primary complaint for this topic).
Of course, web services tend to be more firewall friendly.
One thing we've done is the past is to have webservice calls poll and block. By that I mean we send a request with the webservice, the actual server endpoint then blocks (on a JMS topic/queue) with a timeout. If the service gets a message, it tries to slurp up "some more" until it reaches a certain time out or count of messages, then send the bulks back as a result.
This gives decent responsiveness without bombarding the server with 'are we there yet' polling requests. effectively, the client gets its responses in "bursts" of activity, othewise it simply sits idle with a "long" (like 5 minute) time out. So, a completely idle client with no activity makes 12 polls per hour, which is nothing.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=265540