"tfennelly" wrote : "mark.little(a)jboss.com" wrote : Why not subtype ServiceInvoker and have a specific DLQServiceInvoker? | | Hmmmm... I dunno... I actually intentionally didn't do that because I'd consider that overkill. | I think it breaks the abstraction. When we spoke you agreed it was one SI instance per service per client. Now we've got a class specific method that allows you to call the DLQ? Doesn't look right to me. SI is essentially a client stub to a service. Why should there be a specific method on the class to talk to a specific service? If we go that route then we'll be encouraging static methods for transformation, registry, transactions etc. etc. If you look at the equivalents to this in CORBA, DCE, DCOM, RMI etc. you'll see what I mean. They have specific instances per service type if needed. Let's go that route and don't pollute the SI space. anonymous wrote : | But more importantly, it would be exploding an API around ServiceInvoker, which I think is a really bad idea. We obviously shouldn't stop people extending SI, but I think we should only introduce multiple SIs into the core API as a very last resort, which this is obviously not. | I don't think you're quite understanding what I mean. I'm not suggesting introducing a new SI. I'm suggesting instroducing a specific instance of a SI class that *only* contacts the DLQ. You can't do anything else with it: all you can do it send messages to the DLQ. I don't see how this is a really bad idea? It's fairly common practice in every distributed system I've had experience with over the past 20+ years. Neither is it an extension to SI. It's a trivial implementation (in pseduo-code): | class DLQServiceInvoker extends ServiceInvoker | { | public DLQServiceInvoker () | { | super(whatever needed to bind the base class to the DLQ); | } | } | (Maybe override sendSync if we don't believe that should be used for the DLQ). Then stick it in a org.jboss.soa.esb.client.(specific)services package and we're done. A heck of a lot better than a static operation on the class IMO and in line with OO principles. anonymous wrote : | If there's a general consensus against having this as a static method on ServiceInvoker, then I'd vote for just getting rid of it altogether and documenting how to do it somewhere (in the SerivceInvoker Javadoc ;-) ). I def wouldn't be voting for creating separate sub classes for doing this type of thing. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070937#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...