2008/5/9 Rajith Attapattu <[EMAIL PROTECTED]>: >> I agree, I even think a lot of this could be done without requiring casting >> to our own APIs, e.g. we could provide special topics/queues that permit >> apps to access/manipulate broker wiring using ordinary JMS messages. >> > > +1. This is my prefered way to do it as opposed to an extended JMS API where > you have to cast down to specific classes.
I don't quite understand this. Perhaps I don't fully appreciate what you are doing but surely using JMS like this is harder than using an extended JMS API with few advantages? You end up having custom code anyway that isn't portable since other JMS implementations (e.g Sonic) will not understand the special messages you send, plus error handling is much more complex - what do you do when the user gets something wrong? Send a response message that they have to handle? Is that really easier than throwing an exception that they can handle from a regular method? I don't see "pure JMS" as a goal in itself. If you need to expose features or semantics that go beyond JMS you are non-portable. I hope in time that when AMQP becomes ubiquitous that Sun will produce a version of JMS with our extensions in it. RG
