Exdecuting time consuming task in EJB

[Simon]

Hi,

I am develpoing a Java application that enables the user to assemble
certain kinds of workflows and execute these. The execution of such a
process can take a long time (several hours).

Now, I want to transform this application to an enterprise version. The
user can assemble the workflow on its client, hand it over to the
server, and the server executes it (immediately, or at a scheduled time,
or regularly, etc.). The user can monitor the progress using a thin web
client and collect the results when the workflow finishes.

Clearly, these processes must be executed asynchronously and
concurrently. It would also be good to have control over the scheduler
so the user can inspect and potentially modify the queue. Furthermore,
workflows, as they are currently implemented, spawn threads to execute
subtasks in parallel (using an Executor).

It appears to me that executing and scheduling can be performed using a
EJB Timer (possibly with zero delay), although I must give up control
over ther scheduler. However, spawning threads from an EJB seems to be
evil, if I understand the documentation correctly. I am not sure that
this would do any harm in my case since the individual workflows do not
interact with each other, and, while they are running, not even with a
database, but I am relatively new to Java EE.

My questions are these:

- Is a Java EE the right environment for my problem?

- Is there an enterprise server that has good support for concurrency
and long-running tasks?

I would very much appreciate your comments.
Cheers,
Simon

 

[Arne Vajhøj]

I am develpoing a Java application that enables the user to assemble
certain kinds of workflows and execute these. The execution of such a
process can take a long time (several hours).

Now, I want to transform this application to an enterprise version. The
user can assemble the workflow on its client, hand it over to the
server, and the server executes it (immediately, or at a scheduled time,
or regularly, etc.). The user can monitor the progress using a thin web
client and collect the results when the workflow finishes.

Clearly, these processes must be executed asynchronously and
concurrently. It would also be good to have control over the scheduler
so the user can inspect and potentially modify the queue. Furthermore,
workflows, as they are currently implemented, spawn threads to execute
subtasks in parallel (using an Executor).

It appears to me that executing and scheduling can be performed using a
EJB Timer (possibly with zero delay), although I must give up control
over ther scheduler. However, spawning threads from an EJB seems to be
evil, if I understand the documentation correctly.

It is not just evil - it is strictly forbidden.

I am not sure that
this would do any harm in my case since the individual workflows do not
interact with each other, and, while they are running, not even with a
database, but I am relatively new to Java EE.

The app server manages threads based on an assumption that components
plays by the rule.

My questions are these:

- Is a Java EE the right environment for my problem?

- Is there an enterprise server that has good support for concurrency
and long-running tasks?

I think you should look as message queues, JMS and message driven beans.

Arne

 

[Arved Sandstrom]

Hi,

I am develpoing a Java application that enables the user to assemble
certain kinds of workflows and execute these. The execution of such a
process can take a long time (several hours).

Now, I want to transform this application to an enterprise version. The
user can assemble the workflow on its client, hand it over to the
server, and the server executes it (immediately, or at a scheduled time,
or regularly, etc.). The user can monitor the progress using a thin web
client and collect the results when the workflow finishes.

Clearly, these processes must be executed asynchronously and
concurrently. It would also be good to have control over the scheduler
so the user can inspect and potentially modify the queue. Furthermore,
workflows, as they are currently implemented, spawn threads to execute
subtasks in parallel (using an Executor).

It appears to me that executing and scheduling can be performed using a
EJB Timer (possibly with zero delay), although I must give up control
over ther scheduler. However, spawning threads from an EJB seems to be
evil, if I understand the documentation correctly. I am not sure that
this would do any harm in my case since the individual workflows do not
interact with each other, and, while they are running, not even with a
database, but I am relatively new to Java EE.

My questions are these:

- Is a Java EE the right environment for my problem?

- Is there an enterprise server that has good support for concurrency
and long-running tasks?

I would very much appreciate your comments.
Cheers,
Simon

Schedulers such as Quartz are routinely used in J2EE environments. A
decent scheduler will also provide the ability to monitor it.

For the purposes of your overall question, think of the scheduler as a
blackbox service. Having done so, consider whether J2EE is a good
environment for the actual workflow code - the various tasks. I can't
see how it would not be.

In the J2EE environment I would certainly not be creating threads to
execute tasks. Let your scheduler and your J2EE server take care of that
for you. For example, two "subtasks" executing in parallel is nothing
more than the scheduler asking the J2EE server to invoke method X on EJB
A, and method Y on EJB B, at the same time (I'm assuming EJBs but they
could be MDBs or servlets). EJB A and EJB B could be the same thing, and
if SLSBs they could be the same instance, used twice in a row...what do
you care? Your workflow process won't proceed until it gets results back
from both subtasks - that's the logical implication of "parallel" for
your purposes.

Let the scheduler and server take care of the details...all your
workflow needs to do is instruct the scheduler what to do, and provide
the right executable components to the J2EE server.

I hope this helps.

AHS