RE: Pooled Service Model enhancements

[Jean-Francois Poilpret]

I much agree with James.   Having a pooled service model that brings some enhancements to the current one is one point. Having a service that provides asynchroneous execution of services (possibly with a scheduler) is another point.   For me a service model should not be limited to work only with services that have only void methods (and also non throwing exceptions, by the way: this reminds me of the “oneway” keyword in CORBA, as far as I remember at the end nobody would use that keyword because it prevents any assurance of a method -correct- execution). My original request was really in this sense: extending the current pooled service model in a way to, primarily, avoid resource waste (after a period of heavy load for instance).   I don’t know how the pooled model is currently implemented in HiveMind, I am not sure that having it changed to use commons pool would be easy, nor advisable (it seems one of Howard’s goals is to keep dependencies to the minimum). I will try to have a quick look at it when I have time (at least to understand how service models are developed).   One additional comment about the use of concurrent packages (for an asynchroneous scheduler for instance): if it was to be a part of HiveMind core, then this would introduce still another dependency (since HiveMind is claimed to work on JDK1.3, and I see no reason why this should change until some time: I do not think we can expect everybody to switch to JDK5 until years, personally I did not try it yet!)   Cheers   From: James Carman [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 9:42 PM To: hivemind-dev@jakarta.apache.org Subject: RE: Pooled Service Model enhancements   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