geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: Concurrency Utilities for Java EE
Date Fri, 15 Feb 2008 00:02:25 GMT
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


Mime
View raw message