What class name should we use for the unit of work?

[Dave Syer]

Hmm. The problem with that is that it often can be subdivided (e.g. into a read plus a write). Then again so can a real atom be subdivided (nucleus and electrons). I don't think I'll continue with that analogy...

[sdmiski]

How about BatchTask ?

[gmatthews]

Thingy or Job are front runners for me.

[Dave Syer]

Does anyone have any strong opinions about Tasklet? It's easy to say, and doesn't clash with other frameworks (as far as I know).

[gmatthews]

Hi Dave,

Tasklet sounds a bit lame.

"I'm just going to run a Tasklet to process 50 billion tax returns..." doesn't sound quite right. If you go with Tasklet, they'll need to have a built in constraint to only be able to process 2 or 3 fairly simple things :-)

I wondered why Job didn't appear in the survey list. Are you trying to avoid clashing with Quartz?

Job is fairly well understood, is quick to type, and doesn't over or undersell itself on the scope of what it might be doing.

[Dave Syer]

We already have a Job - it's the opposite end of the spectrum - the most divisible object in the domain. A Job is a list of Steps, and each Step is an iteration over a <insert your favourite name here>.

Tasklet makes some sense to me, but we are still open to suggestion. I dont understand the comment about the "built in constraint". What would be the point of that?

[gmatthews]

I dont understand the comment about the "built in constraint". What would be the point of that?

It was a (bad) joke.

Seriously though, can Step be recursive or nested indefinitely?

--- edit ---

or can you just nest Job objects indefinitely.

I was just having a conversation the other day with someone about how to go about introducing dependencies between Quartz Jobs.

It seems like a potential design flaw to name each level of nesting differently. I'm likely wrong but initial impressions are that everything is a Job.

Why do you want to have different names for each level?

[Alarmnummer]

We already have a Job - it's the opposite end of the spectrum - the most divisible object in the domain. A Job is a list of Steps

What is the difference between a Job and a Batch?

and each Step is an iteration over a <insert your favourite name here>.

And Steps sounds to me like a Chunk. A bunch of 'records' that are going to be processed.

Tasklet makes some sense to me, but we are still open to suggestion.

I don't like the name Tasklet very much either. It would be something Sun would coin op when the run out of imagination

But what about BatchRecord? BatchUnit, UnitAtom, ChunkPart, ChunkUnit ,OWN (Object Without a Name.. we use the same approach in Holland for music bands).

[Andreas Senft]

Hmm. Unit seems not bad. Or just Task without "-let".

[lucasward]

Just to clarify quickly, Job has one to many Steps, which has a one to one relationship with Module/Tasklet/Unit, etc. The main reason for the separation between a step and Module is to provide a clear touch-point between the framework and the developer. The Step controls transactions, storing status, etc, and delegates to the developer via the Module, giving them an opportunity to execute their logic within the constraints set forth by the step. I think, overall, some form of 'Task' is the frontrunner, name-wise. For me, Task seems like one unit; I call a task, it runs and finishes. Using the analogy provided in a previous example: "Call a task to process 50 million financial records". However, that's not what's happening, you're calling a Step to process 50 million records, which delegates to the Task 50 million times. This is where adding the '-let' to Task helps deferentiate that it's not the whole thing, but rather a part.

However, at the end of the day it's all just semantics. It's no different than the decision to use 'Servlet' as a name.

The discussion regarding 'Why split a job up into steps?' is an interesting one, and I can understand there being a little initial confusion at first. In most batch applications there always ends up being 'psuedo work streams' that exist solely because 3 or 4 jobs must be executed in sequence before any other action can be taken. For example, Job A loads data, Job B validates, Job C performs an important set of calculations, and Job D outputs or creates reports, etc. This *could* be done in one job, but usually there are important reasons why they are separated out. Now the scheduler (and thus the operators) must know about and manage all four jobs, when realistically, nothing further can happen until Job D finishes, they are effectively one job, with a lot of unnecessary complexity moved into the run tier (i.e. the scheduler). Instead, having one Job with 4 steps makes much more sense. There has been talk about creating 'collapsable' or nested Jobs that would allow you to have only the Job if there wasn't any separation needed, however, when we looked at implementing it, there was a lot of added architecture and configuration complexity, just to keep from having a Job with one Step.

I hope this sheds some light on the terms we're using and the motivations behind them.