Just some general comments.
> Now JMS for some time now has generally been
> considered the right
> approach here. The problem I have with JMS is the
> asynchronous and
> in-order nature of the spec. That is of course what
> it is designed for,
> but those features don't t specifically apply to my
> problem space.
> Order of messaging is not important, for example.
I don't believe that "in-order" is a guarantee of the specification. It's a feature of the brokers, but I don't think that it's a requirement for a broker to provide in-order delivery to be JMS compliant.
> Other problems I have with using JMS in the scenario
> are these:
> - Requires use of EJBs/MDBs (not necessarily a bad
> thing, however these
> are the only EJBs we use. without EJBs there is a
> potential to move
> from an EAR to a simpler WAR).
You're not required to use an EJB/MDB at all, you can connect directly to the JMS Server and listen for messages.
> - More complex configuration required, including but
> not limited to:
> MDB thread pool configurations, transactionality for
> MDBs, clustering
> for OpenMQ broker, authentication layer for OpenMQ,
> HADB for OpenMQ
> cluster in addition to tying OpenMQ into a Glassfish
> cluster for load
> balancing and fail-over, etc.
The implication is that you won't be configuring this with your other solution, yet you want a similar feature set. OpenMQ can be a stand alone from Glassfish. If you're clustering anything, there's configuration involved. If you're going to have more than one listener on a queue, you're going to (at least indirectly) be configuring thread instances etc. Now, they may seem different, or "easier" (perhaps simply do to familiarity), but, in the end, the process is the same. Now, OpenMQ may well be "more difficult to configure" than your option, but that doesn't mean there won't be any configuration (either through configuration files or hard coded implementations) on your solution either.
> - Security between endpoint connections can be
> difficult to configure
> - With multiple sites running 24/7 and sending
> messages to remote
> Queues, there are "keep alive" issues where
> connections become stale etc
> (stated from what we've observed during development,
> at least).
> - Using OpenMQ/JMS with a few queues and MDBs the
> application(s) can
> consume a large amount of heap and threads in the app
> server when
> configured for high throughput
I can't comment on these. If OpenMQ's tested resource requirements aren't meeting your needs, then, certainly, look elsewhere.
>
> Usually people tout things that the JMS spec provide
> such a guaranteed
> delivery and persistence, however from my standpoint
> in this situation
> they are not really relevant. JMS "persistence",
> lets say if a message
> fails to process because its next destination is not
> yet available,
> causes a rollback which simply redelivers the
> message. In a case like
> this, it's going to become the business codes
> responsibility to do
> something useful with this message so that it can be
> attempted to be
> delivered again at a later time when its destination
> may be available
> again.
That's true, but JMS persistence is more than that. It's also guaranteeing that the message will survive system failure. The basic contract (when configured) is that, much like a mail server, when the JMS server accepts a message, it's "guaranteeing" delivery "at least once". That "guarantee" is configurable as to how robust it truly is (for example, no persistence at all and message loss on server failure, cluster/failover guarantess, message order, retry limits, etc.). The more robust and more limitations you put on the JMS server, typically the lower the servers throughput because of the expense of the procedures it must do to enforce those guarantees. Having a JMS server that simply store message in RAM with no persistence whatsoever, and it zips along quite handily.
> Now, using web services to deliver a message will
> result in the same
> overall behavior; if the web service processing the
> message fails to
> connect to the next hop, it's going to need to
> persist the state of the
> message and try again later (same as if a message is
> in a
> rollback/redelivery loop on a Queue). If the app
> server that is hosting
> web service fails during processing, the requester of
> the web service
> will not receive a successful response (non HTTP 200
> OK response), and
> will need to deal with it their (same as if a JMS
> message failed to be
> delivered to the destination Queue).
The overall behavior will be whatever your back end provides, and obviously.
> Things that I think we benefit from in using
> Grizzly/HTTP/REST are:
*snip*
> A basic summary is that I believe the overhead of
> using OpenMQ/JMS to
> provide features we don't specifically need (or are
> available at
> different tier when using web services) while
> requiring more complex
> configuration and higher resource consumption make
> web services a much
> more viable option for us.
>
> I'm hoping to get some opinions on the matter, such
> as if we have any
> major holes in our logic that we just haven't
> considered.
There is one major hole that I think you haven't perhaps considered properly.
Simply put, while on the surface it seems easy, in truth Messaging is a Hard Problem. The MQ brokers spend a LOT of time getting their server to the be a) reliable, and b) perform. Resource leaks, contention, deadlocks, etc. are difficult in a single server solution. Add in clustering, failover, etc. and it gets even worse. Simply, I do not believe this is a wheel you really want to reinvent.
The moving of the message from Host A to Host B is only a minor part of the problem compared to what to do with that message once it arrives. As I mentioned, there are a lot of different options in processing messages. If you don't need all of the guarantees provided by a container, then disable them.
There are several JMS brokers out there, OpenMQ is just one. If OpenMQ isn't performing to your expectations, consider trying one of the others. Via JMS, your program logic shouldn't need to change in any dramatic way, which should help make testing other solutions easier.
This is just generic advice. Beyond the casual use I put it through in GF, I do not use OpenMQ is any heavy way. It works out of the box mostly for me, but that's not a spectacularly glowing endorsement.
But the messaging as represented by the JMS standard is a mature, and competitive space with a bevy of implementations out there, both Open Source and commercial. It can be argued that in many systems, the MQ software is THE most important piece to get right, and keep stable and performant. Having fast and reliable MOM can be the key that enables the rest of the system to be "slow and unreliable".
No diservice intended to the Grizzly team and their work, it's great software. But it's just the base level transport, and there's more to the problem than that.
If messaging is going to be a key component of your architecture, I truly think that you should consider an "off the shelf" solution.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=348712