Hi, This is really great news.
I very quickly browsed the specifications and I have a couple of questions: 1. Is there a way to define task dependencies? For instance, I should be able to queue a task B which will only be executed after the execution of task A as task B depends on task A's outputs. 2. Is there a way to specify routing strategies for distributable tasks? For instance, as an application developer, I would like to have an API to route my tasks to specific slaves. 3. Is there a way to transparently fail-over a non started task to another slave if the slave becomes unavailable?
Let me know if you need some helps to implement task distribution. FWIW, WADI has a simple distributed service invocation framework (see http://wadi.codehaus.org/wadi-core/apidocs/index.html - start with ServiceProxyFactory) which could be quite useful.
Thanks, Gianny On 15/02/2008, at 4:06 AM, Jarek Gawor wrote:
Folks, For the past few weeks I've been working on the Concurrency Utilities for Java EE specification implementation. The Concurrency Utilities for Java EE specification is a draft specification (see http://gee.cs.oswego.edu/dl/concurrencyee-interest/ for more info) that is supposed to replace the JSR-236 (Timer API) and JSR-237 (Work Manager API) specifications and become part of Java EE 6. The Concurrency Utilities for Java EE specification basically extends the java.util.concurrent.Executor API and adds managed environment qualities to the tasks executed via the Executor. That is, the background tasks can execute with the same environment as the application that started it. I have a little bit of code but it's definitely not complete or fully functional and still needs a lot of work (e.g. better integration with Geronimo, etc.). I would like to donate this code to Geronimo, and continue to work on it there as a community. Now, the cool thing is that this implementation might become the official Reference Implementation (RI) for this spec. I've talked with the IBM co-spec lead and there is a good chance of that happening if we also commit to writing a TCK for it. And I think that would be a great opportunity for Geronimo to show some leadership in the Java EE spec area. Even if the RI thing does not work out or this specification does not become part of Java EE 6, I still think this functionally would be a good addition to Geronimo. What do people think? Thoughts, any concerns? Jarek
