RE: Pooled Service Model enhancements

[James Carman]

Well, I don’t really like it and I don’t think it should be part of core HiveMind, but you can feel free to implement it yourself.� I don’t like it because you really have to be careful what you’re doing when you start using asynchronous calls like this seamlessly.� Clients have no idea that the call goes on asynchronously!� I see the merits of what you’re proposing, but I think making it very explicit (using a service point and implementing Runnable or providing some reflective mechanism) is a bit safer.� It’s one thing to manage what specific INSTANCE of an implementation object is used behind the scenes to carry out the logic of a method call (the job of a service model), but it’s a completely different thing to seamlessly switch the method call to asynchronous behind the scenes.� Not only that, but you have to make sure your methods are ALL void methods in your service interface.� Also, what do you do with exceptions that are thrown during execution of the service method?� What about transactions?   -----Original Message----- From: Pablo Lalloni [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 10:12 AM To: hivemind-dev Subject: RE: Pooled Service Model enhancements   El lun, 25-10-2004 a las 10:37, James Carman escribi�: What if the service interface’s method returns something?  How can it be asynchronous? Of course, asynchronous calls doesn't expect to return a value... that's the whole point.   I agree that the Executor interface could be used as a service itself, but to use that idea as a service model doesn’t work IMHO.  My suggestion would be to expose the Executor (or actually ExecutorService in JDK 5.0) interface as a service in your registry (as you’ve already done it seems) and let other services use it.  A service model itself cannot be asynchronous, as it is a mechanism for performing a method call (which is inherently synchronous) on an object.  Even when you call the Executor.execute() method, it’s a synchronous call.  The method does what it’s supposed to do (adds the Runnable to a queue or something) and returns.  I partially agree with you, but I think that wrapping the asynch/pool/queue behaviour in the service-model would make things a lot cleaner and shorter... no need the extra SPs, no need to implement runnable, etc... Of course the methods called with this model/s should not return any value but void. -- Pablo I. Lalloni Tel�fono +54 (11) 4347-3177 Proyecto Pampa Direcci�n Inform�tica Tributaria AFIP