jsr342-experts@javaee-spec.java.net

[jsr342-experts] Batch API issue

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Fri, 25 Jan 2013 14:55:21 -0800

I'd like the advice of this group on an issue with the Batch API.

The Batch API specifies how applications can define job steps.
Job steps are combined into a batch job using an XML file that
is effectively a batch "job control language" script. The application
starts a batch job by supplying this batch JCL script to the Batch API.

There are at least two models for how an application might deal with
these batch scripts:

1. The batch scripts are an integral part of the application. They're
   supplied with the application and controlled by the application.

2. The application supplies only the batch job steps, expecting that
   an external agent (usually an administrator) constructs a batch
   script using these jobs. The application controls the execution
   of the script, but not the content of the script.

In the first case it seems obvious that the batch script XML files
should be packaged with the application and the application should
refer to them by using a resource name in the application (possibly
a name valid for Class.getResource(), possibly a name of a file in
a fixed location in the application) when using the Batch API.

In the second case, the application needs to refer to these scripts,
but the scripts aren't packaged with the application, so it's not
clear how the application should refer to them. The Batch API
specifies this case very loosely. The Batch implementation is
free to interpret the names given to it in any way it desires,
locating these batch scripts wherever and however it wants. The
names used with case #1 above are portable, assuming they
haven't been overridden in some Batch implementation-specific way.

Normally, when a Java EE application uses a resource that's external
to the application and can be configured by an administrator, we
expect the application to declare this external dependency using
(e.g.) a @Resource annotation. This creates information known to
the deployment process that alerts the deployer that an external
resource is being referenced and must be supplied.

The Batch API provides no way to expose to the deployment process
an application's dependency on an externally supplied batch script.
An application might fail at runtime because the administrator didn't
supply the expected script with the expected name.

I've proposed that the Batch API make use of @Resource to handle
this case, similarly to how we've handled other cases, but they've
rejected that proposal. They believe the loosely defined approach
that leaves all the details up to the implementation is sufficient.

Which approach do you prefer?

1. The current Batch API approach of leaving all the details
   up to the implementation.

2. Find a way (e.g., @Resource) to expose these application dependencies
   on an external batch script to the deployment process.

Let me know what you think.