Bill Shannon <bill.shannon_at_oracle.com> wrote on 01/25/2013 04:55:21 PM:
> 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.
I assume noone has an issue with using a standard packaging of scripts
in an application module (e.g. META-INF/batch-jobs) and using
getResource() to access them. This has been a standard practice for
resource access for ages. I can't see much value that @Resource
would provide in this case, though eventually, @Resource might prove
useful (once we get modularity).
> 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.
I think it is perfectly valid to allow the spec to define extension
points that vendors may use. In this case, the mechanism allows
vendors to provide batch jobs and job management without being
limited to application packaged scripts. In addition, it allows for
cases where batch jobs and scripts may be computed dynamically by
the application logic and not necessarily known at app deployment
time.
Thanks,
Jim Knutson
WebSphere Java EE Architect