"tfennelly" wrote : I totally got you the first time Mark :-) 20+ years experience or not, creating a separate class (subclass or otherwise) for doing this particular job stinks IMO, sorry ;-) | Sorry, but I can guarantee you people will start doing this with services anyway and it's going to happen in JBossESB once we have full contract definition in place. We will have specific stubs for specific services. Experience counts here (just as it does for transformations ;-) anonymous wrote : | Anyway I'm actually all for getting rid of it coz I do agree that it's a broken concept, but not because of anything to do with OO, CORBA, DCE, DCOM RMI etc | | When you think about it, what's the likelihood of only having 1 DLQ in a system. Not sure if we currently support it or not, but I'd imagine that at some stage we'll need to support DLQ config on a per endpoint/Service basis (as well as a system wide default perhaps) and this method would gag on that. | Sure. I hadn't thought we'd be creating specific SI instances (convenience classes) until later down the road anyway. anonymous wrote : | I do think however that we should try make DLQ delivery as easy as possible and that people shouldn't need to manually "look up" the DLQ in their code and call any special classes. I think we should be able to associate a DLQ with one or more Services/endpoints and have the SI take care of it all from a code perspective e.g. try deliver a message through the SI.... if it fails, SI auto delivers to the service's associated DLQ, OR the calling code can manually do it via the SI instance. Auto doing it would be in line with how the likes of Weblogic does it for JMS (you can configure a DLQ per JMS Destination) and I think it's more in line with the old fire-and-forget line of thinking (otherwise it'd be fire-and-forget-unless-theres-an-error). There are different concepts rolled into what you've just said. Fire-and-forget (ignoring errors entirely) is a valid approach and we shouldn't ignore that. Many organisations send messages and don't need responses (even if they are errors) and they'll configure their message sender accordingly. There are a number of reasons for this, but the simplest one is that if the message goes missing then there'll be another one sent in a few seconds/minutes anyway; if there's an error at the processing side then a separate management infrastructure will be monitoring anyway. We should be allowing the DLQ to be used for undelivery of messages in a select way and not over using it. From a synchronous perspective, I think it's fairly clear: if you can't deliver the message then fault back to the sender and let him decide whether or not to then send it to the DLQ. Otherwise what's the point of sync deliver ;-)? If it's async then that's different. Ignoring simplifications, the sender should decide whether or not to use the DLQ by setting the call fields appropriately. If they're not set then no DLQ. If they are set then (assuming the DLQ EPR is used), we go the DLQ route. Going back to what you said about JMS, this says to me we probably want an overloaded sendAsync. sendReliableAsync would send the wrong message (no pun intended!) because it's not reliable delivery at all (unless you're using JMS with transactions as your transport). sendAsyncDLQ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070944#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...