A Job is an instance that encapsulates an entire batch

process. A job is typically put together using a Job

Specification Language and consists of multiple steps. The

Job Specification Language for JSR 352 is implemented with XML

and is referred as "Job XML".





is an instance that encapsulates an entire batch process. A job is typically put together using a and consists of multiple steps. The Job Specification Language for JSR 352 is implemented with XML and is referred as "Job XML". A Step is a domain object that encapsulates an

independent, sequential phase of a job. A step contains all of

the information necessary to define and control the actual batch

processing.

is a domain object that encapsulates an independent, sequential phase of a job. A step contains all of the information necessary to define and control the actual batch processing. JobOperator provides an interface to manage all aspects

of job processing, including operational commands, such as

start, restart, and stop, as well as job repository commands,

such as retrieval of job and step executions.

provides an interface to manage all aspects of job processing, including operational commands, such as start, restart, and stop, as well as job repository commands, such as retrieval of job and step executions. JobRepository holds information about jobs current

running and jobs that run in the past. JobOperator provides

access to this repository.





holds information about jobs current running and jobs that run in the past. JobOperator provides access to this repository. Reader-Processor-Writer pattern is the primary pattern

and is called as Chunk-oriented processing. In

this, ItemReader reads one item at a time, ItemProcessor

processes the item based upon the business logic, such as

calculate account balance and hands it to ItemWriter for

aggregation. Once the 'chunk' number of items are aggregated,

they are written out, and the transaction is committed.







JSR 352 also defines roll-your-own batch pattern, called as Batchlet.

This batch pattern is invoked once, runs to completion, and

returns an exit status. This pattern must implement and honor a

"cancel" callback to enable operational termination of the

Batchlet.







<job id="myJob" xmlns="http://batch.jsr352/jsl">

<step id="myStep" >

<chunk reader="MyItemReader"

writer="MyItemWriter"

processor="MyItemProcessor"

buffer-size="5"

checkpoint-policy="item"

commit-interval="10" />

</step>

</job>





The <job> has an "id" attribute that defines the logical

name of the job and is used for identification purposes.





name of the job and is used for identification purposes. Each <job> can multiple <step>s where each

<step> identifies a job step and it's characteristics.

Each <step> has an "id" attribute that defines the logical

name of the job and is used for identification purposes.





<step> identifies a job step and it's characteristics. Each <step> has an "id" attribute that defines the logical name of the job and is used for identification purposes. A <step> may have <chunk> or <batchlet>

element, this <step> has a <chunk>. A <chunk>

identifies a chunk type step and implements the

reader-processor-writer pattern of batch.





element, this <step> has a <chunk>. A <chunk> identifies a chunk type step and implements the reader-processor-writer pattern of batch. The "reader", "processor", and "writer" attributes specify the

class names of an item reader, processor, and writer

respectively.

class names of an item reader, processor, and writer respectively. "buffer-size" specifies number of items to read and buffer

before writing. When enough items have been read to fill the

buffer, the buffer is emptied to a list and the configured

ItemWriter is invoked with the list of items.

before writing. When enough items have been read to fill the buffer, the buffer is emptied to a list and the configured ItemWriter is invoked with the list of items. "checkpoint-policy" attribute specifies the checkpoint policy

that governs commit behavior for this chunk. Valid values are

"item", "time" and "custom". The "item" policy means chunk is

checkpointed after a specified number of items are processed.

The "time" policy means the chunk is committed after a specified

amount of time. The "custom" policy means the chunk is

checkpointed according to a checkpoint algorithm implementation.

The default policy is "item".

that governs commit behavior for this chunk. Valid values are "item", "time" and "custom". The "item" policy means chunk is checkpointed after a specified number of items are processed. The "time" policy means the chunk is committed after a specified amount of time. The "custom" policy means the chunk is checkpointed according to a checkpoint algorithm implementation. The default policy is "item". "commit-interval" specifies the commit interval for the

specified checkpointed policy. The unit meaning of the

commit-interval specifies depends on the specified checkpoint

policy. For "item" policy, commit-interval specifies a number of

items. For "time" policy, commit- interval specifies a number of

seconds. The commit-interval attribute is ignored for "custom"

policy.







When the configured checkpoint policy directs it is time to

checkpoint, all the items read and processed so far are passed

to the "writer".

Batch processing is execution of series of "jobs" that is suitablefor non-interactive, bulk-oriented and long-running tasks. Typicalexamples are end-of-month bank statement generation, end-of-day jobssuch as interest calculation, and ETL (extract-transform-load) in adata warehouse. These tasks are typically data or computationallyintensive, execute sequentially or in parallel, and may be initiatedthrough various invocation models, including ad-hoc, scheduled, andon-demand. JSR 352 willdefine a programming model for batch applications and a runtime forscheduling and executing jobs. This blog will explain the mainconcepts in JSR 352.The diagram below highlight the key concepts of a batch processingarchitecture.src="//cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/Image/8173030e73f6629907c602dc88f86b0f/jsr352_schematic.png"height="248" width="600">A Job XML for a chunk-oriented processing may look like:

Here is a simple reader:



@ItemReader

public class MyItemReader {

private static int id;

MyCheckPoint checkpoint = null;



@Open

void open(MyCheckPoint checkpoint) {

this.checkpoint = checkpoint;

System.out.println(getClass().getName() + ".open: " + checkpoint.getItemCount());

}



@ReadItem

MyBatchRecord read() {

checkpoint.incrementByOne();

return new MyBatchRecord(++id);

}



@CheckpointInfo

MyCheckPoint getCheckPoint() {

return checkpoint;

}

}



Methods marked with @Open , @ReadItem ,

and @CheckpointInfo are required.



Here is a simple processor that rejects every other item:



@ItemProcessor

public class MyItemProcessor {

@ProcessItem

MyBatchRecord process(MyBatchRecord record) {

return (record.getId() % 2 == 0) ? record : null;

}

}





And here is a simple writer:



@ItemWriter

public class MyItemWriter {

MyCheckPoint checkpoint = null;



@Open

void open(MyCheckPoint checkpoint) {

this.checkpoint = checkpoint;

System.out.println(getClass().getName() + ".open: " + checkpoint.getItemCount());

}



@WriteItems

void write(List<MyBatchRecord> list) {

System.out.println("Writing the chunk...");

for (MyBatchRecord record : list) {

System.out.println(record.getId());

}

checkpoint.increment(list.size());

System.out.println("... done.");

}



@CheckpointInfo

MyCheckPoint getCheckPoint() {

return checkpoint;

}

}



Finally a simple implementation of MyCheckpoint :



public class MyCheckPoint {

int itemCount;



public int getItemCount() {

return itemCount;

}



public void setItemCount(int itemCount) {

this.itemCount = itemCount;

}



void incrementByOne() {

itemCount++;

}



void increment(int size) {

itemCount += size;

}

}





Together, MyItemReader , MyItemWriter ,

MyItemProcessor , MyCheckPoint , and batch.xml ,

will read/process/write 5 items and commit when 10 such items have

been processed.



JSR 352

specification defines several other concepts such as how Job

XML can define sequencing of jobs, listeners to interpose on job

execution, transaction management, and running jobs in partitioned

and concurrent modes. Subsequent blog will explain some of those

concepts.



A complete replay of href="https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=4105">Java

Batch for Cost-Optimized Business Efficiency from JavaOne

2012 can be href="https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=4105">seen

here (click on CON4105_mp4_4105_001 in Media).



Each feature will be added to the JSR subject to EG approval. You

can share your feedback to href="http://java.net/projects/jbatch/lists/public/archive">public@jbatch.java.net.



The APIs and implementation of JSR 352 are not integrated in href="http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/">GlassFish

4 promoted builds yet.

Here are some more references for you:

Here are some other Java EE 7 primers published so far:



href="https://blogs.oracle.com/arungupta/entry/simple_jms_2_0_sample">Simple

JMS 2.0 Sample (TOTD #191)



JMS 2.0 Sample (TOTD #191) href="https://blogs.oracle.com/arungupta/entry/what_s_new_in_servlet">What's

New in Servlet 3.1 ?



New in Servlet 3.1 ? href="https://blogs.oracle.com/arungupta/entry/concurrency_utilities_for_java_ee">Concurrency

Utilities for Java EE (JSR 236)

Utilities for Java EE (JSR 236) href="https://blogs.oracle.com/arungupta/entry/collaborative_whiteboard_using_websocket_in">Collaborative

Whiteboard using WebSocket in GlassFish 4 (TOTD #189)



Whiteboard using WebSocket in GlassFish 4 (TOTD #189) href="https://blogs.oracle.com/arungupta/entry/non_blocking_i_o_using">Non-blocking

I/O using Servlet 3.1 (TOTD #188)

I/O using Servlet 3.1 (TOTD #188) href="https://blogs.oracle.com/arungupta/entry/what_s_new_in_ejb">What's

New in EJB 3.2 ?

New in EJB 3.2 ? href="https://blogs.oracle.com/arungupta/entry/jpa_2_1_schema_generation">JPA

2.1 Schema Generation (TOTD #187)

2.1 Schema Generation (TOTD #187) href="https://blogs.oracle.com/arungupta/entry/websocket_applications_using_java_jsr">WebSocket

Applications using Java (JSR 356)

Applications using Java (JSR 356) href="https://blogs.oracle.com/arungupta/entry/jersey_2_in_glassfish_4">Jersey

2 in GlassFish 4 (TOTD #182)

2 in GlassFish 4 (TOTD #182) href="https://blogs.oracle.com/arungupta/entry/websockets_and_java_ee_7">WebSocket

and Java EE 7 (TOTD #181)

and Java EE 7 (TOTD #181) href="https://blogs.oracle.com/arungupta/entry/json_p_java_api_for">Java

API for JSON Processing (JSR 353)

API for JSON Processing (JSR 353) href="https://blogs.oracle.com/arungupta/entry/jms_2_0_early_draft">JMS

2.0 Early Draft (JSR 343)





And of course, more on their way! Do you want to see any particularone first ?