What’s New in Spring 3.0? - Spring Enterprise Recipes: A Problem Solution Approach - page 77

// this doesn't stop until it encounters
// an exception or its cancel()ed
scheduledThreadExecutorService.scheduleAtFixedRate(task, 0, 5,
TimeUnit.SECONDS);
}
}
If you use the version of the submit() method on the ExecutorService that accepts a Callable<T> ,
then submit() return whatever was returned from the Callable main method call() .The interface for
Callable is as follows:
package java.util.concurrent;
public interface Callable<V> {
V call() throws Exception;
}
Java EE
In the Java EE landscape, different approaches for solving these sorts of problems have been created,
often missing the point. Java EE has offered no threading issue help for a long time.
There are other solutions for these sorts of problems. Quartz (a job scheduling framework) filled the
gap by providing a solution that provided scheduling and concurrency. JCA 1.5 (or the J2EE Connector
Architecture; the JCA acronym is most used when referring to this technology, even though it was
supposed to be the acronym for the Java Cryptography Architecture) is a specification that supports
concurrency in that it provides a primitive type of gateway for integration functionality. Components
can be notified about incoming messages and respond concurrently. JCA 1.5 provides primitive, limited
Enterprise Service Bus-similar to integration features, without nearly as much of the finesse of
something like SpringSource's Spring Integration framework. That said, if you had to tie a legacy
application written in C to a Java EE application server and let it optionally participate in container
services, and wanted to do it in a reasonably portable way before 2006, it worked well.
The requirement for concurrency wasn't lost on application server vendors, though. In 2003, IBM
and BEA jointly created the Timer and WorkManager API. The API eventually became JSR-237, which
was subsequently withdrawn and merged with JSR-236 with the focus being on how to implement
concurrency in a managed (usually Java EE) environment. JSR-236 is still not final. The Service Data
Object (SDO) specification JSR-235 also had a similar solution in the works, although it is not final.
Both SDO and the WorkManager API were targeted for Java EE 1.4, although they've both progressed
independently since. The Timer and WorkManager API, also known as the CommonJ WorkManager API,
enjoys support on both WebLogic (9.0 or later) and WebSphere (6.0 or later), although they're not
necessarily portable. Finally, open source implementations of the CommonJ API have sprung up in
recent years.
Confused yet?
The issue is that there's no portable, standard, simple way of controlling threads and providing
concurrency for components in a managed environment (or a nonmanaged environment!). Even if the
discussion is framed in terms of Java SE-specific solutions, you have an overwhelming plethora of
choices to make.
Spring's Solution
In Spring 2.0, a unifying solution was introduced in the org.springframework.core.task.TaskExecutor
interface. The TaskExecutor abstraction served all requirements pretty well. Because Spring supported
Java 1.4, TaskExecutor didn't implement the java.util.concurrent.Executor interface, introduced