JMS: To proxy or not to proxy inside a Schema

Question

We are an eGate SRE 5.05 shop running AIX 5.3 and working on getting on getting CAPS up and running.
Our SRE 5.05 translations are monk and 50/50 on Standard Queue vs JSM queues.
We have a few inbounds eways that go to a queue, and many outbounds off that queue ( topics).
I think using JMS Services to bridge between CAPS is a great concept. It definately works extremely well between eGate schemas. But how about using the eway connector inside a schema?
It would appear that the benefit to the proxy, is that we see the name of the collaboration/event in the JMS Administrator. The downfall to this is that when we make a change to one eway, all configurations get updated (we have registry updates turned on and make changes often enough that we need this on). Sometimes, it takes a while for all configurations to get updated, and some of the eways simply stop processing altogether. We have to stop and start those eways to get them processing again.
This configuration update does not occur to those eways that get their data via JMS eWay Connector.
Let me rephrase this question: Which is more efficient / less problematic: using JMS Queues and eWay Connectors or JMS Queues and Proxying (publishing/subscribinbg through the collaboration).

Answer 1

If you're only thinking of exploiting asynchronicity to match your web requests and load balancing to match your volumes, then your senior architect's advise may be correct. I think you're paying to use MOM to use a subset of what it provides in an application that may not be inherently MOM-leaning.
Having said that, I have to say that I completely disagree with the overall focus of Tom Laramee's JavaWorld draft you linked to below. Load balancing, caching, security, etc. are all important features to consider. However, in my opinion the primary benefit of using message oriented middleware is the decoupling of fuctionality and work schedules in large distributed systems. None of the other solutions he discusses can even come close to solving these problems the way MOM does.
I used to work at a large investment bank in the back office where we processed hundreds of thousands to over a million transactions per day. Our systems were very large and complex. Without having our system broken down into small, independent functional units (that could be independently tested and tuned) that communicated via MOM, I think the implementation would have been next to impossible, and even if possible, never maintainable. Apart from the functional decoupling, MOM queues served as excellent buffers to allow interconnected systems to work on their own schedules.
I have worked with 2 other MOM products and I have to say that out-of-the-box JMS has the simplest API that I have seen. I had a very cool database-linked, cross-platform chat application running in no time. JMS is only as complex as you need it to be. The more features you exploit, the more complex it becomes. But basic messaging is very easy.