JBT-01: Getting started with Java Batch

The Use Cases describe ways in which people put Java Batch to use.

Use Case: Mainframe Modernization

Mainframe Modernization refers to updating the existing assets and tooling on the IBM z platform, particularly under the z/OS and z/VSE operating systems, and to support enterprise solutions on Linux for Z and KVM LPARs. Part of IBM’s mainframe modernization program is to expose traditional assets through APIs and to enable interoperation between new applications and legacy systems. IBM contributed heavily to the Java Batch specification, and the Liberty Batch implementation and IBM’s Liberty Server play key roles in the modernization of IBM batch processing.

Java Batch is used in this scenario to translate batch jobs into technologies more familiar to younger generations of software professionals (specifically, USS on z/OS or Unix/Linux, and the Java language). In addition to addressing issues in accessing modern computing facilities on the IBM z platform, shifting these workloads to Java also addresses challenges in finding talent to support longstanding batch applications.

To support this use case, we recommend the IBM flavor of Java Batch training (see below).

Use Case: Offload Mainframe Workloads

Offload Mainframe Workloads refers to migrating batch jobs off the IBM z platform to execute on another system, such as IBM Power Systems running AIX, Linux, or IBM i operating systems, or any Unix/Linux platform. It also applies to cases when the organization wants to shift mainframe workloads from z/OS or z/VSE LPARs (or z/OS or z/VSE instances under z/VM) to Linux on Z or KVM LPARs.

Depending on the target environment and on customer preferences, this use case may be best supported with either the IBM or Spring flavor of the course, or a customized mix of the two (see below).

The training for the Offload Mainframe Workloads use case is about migrating batch jobs using Java Batch, rather than a context-free deep dive into Java Batch. The focus in on practical application. So, the course can include modules on the following topics that are not specific to Java Batch, but relevant to the migration of applications between platforms and languages:

• general good practices for migrating application code between languages and platforms, including practical techniques to ensure functionality is not “lost in translation”;
• information about JCL, Utilities, COBOL, PL/I, Assembler, and z/OS access methods (as needed) to help Java programmers understand what they are working with on the source side;
• details on procedural vs. object-oriented code structure and Java conventions for the mainframers; and
• guidance in applying development practices that are common in the Java community but largely unknown in the mainframe community, such as test-driven development and single-branch development.

Use Case: New Development

New Development refers to writing batch processes from scratch, or refactoring existing batch processes that may have been built in an ad hoc way using shell scripts and more-or-less unstructured Java code, or code written in other languages, and that need to be brought under the umbrella of a robust and consistent batch processing framework.

For this use case we recommend the Spring flavor of the training.

While large IBM mainframe shops are likely to have a significant legacy of batch processing, organizations that are starting more-or-less from scratch are more likely to have limited batch processing requirements and no established batch processing management standards or tooling. They may have ad hoc batch solutions in place, or no batch solutions in place.

So, the training for this use case provides a balance between Java Batch elements pertaining to batch process development, such as Job and Step, and elements pertaining to overall batch processing management, such as Job Repository and Job Operator, with Spring Batch as the basis.

Flavors of Java Batch Training

The “flavors” of training are designed to provide maximum value for customers using Java Batch for various purposes.

Flavor: IBM

The IBM flavor of the course uses IBM’s implementation of Java Batch, called Liberty Batch, and the IBM Liberty Server as the runtime environment for the converted batch jobs. This flavor assumes the course will be taken by staff at a company that is an IBM customer and has IBM’s development tool stack, including features to support Liberty Batch development.

We also depend on the customer to set up a suitable environment for the course exercises, as this tool stack is not freely available and we cannot set up such an environment for general use.

The IBM flavor assumes some (maybe half) the participants are experienced mainframers who are new to Java, and others are experienced Java developers who are unfamiliar with mainframe technologies, so it includes guidance on each environment tailored for consumption by people familiar with the other environment. The relative weight of this information can be tailored to the customer’s situation.

The IBM flavor further assumes the organization will already have standards and procedures in place for managing their batch workload, and the main purpose of the training is to prepare technical staff to develop Java Batch solutions, rather than to administer the Job Repository and Job Operator functions. So, there is a strong focus on the Job and Step elements of the framework, and on the “batchlet” feature.

Flavor: Spring

The Spring flavor of the course uses the Spring Batch implementation of Java Batch as well as Spring Boot, with execution either as a standalone process or in a generic servlet container. This flavor uses Java annotations for Java Batch configuration, rather than JSL written in XML.

With this flavor of training, we assume participants will be able to access the public Internet during the class so they can work together on the same Github repository.

Due to the design approach of the Spring Batch implementation, this flavor of training focuses more on the “chunk” feature than the “batchlet” feature of the framework.

Choosing an implementation

Several implementations of Java Batch are available, and each is different. Spring Batch existed before JSR 352 was written, and the specification owes a great deal to that earlier product. Spring Batch now conforms with the specification. The Spring Batch implementation in conjunction with Spring Boot offers more capabilities and flexibility than other implementations, as well as configuration through Java annotations and Spring autowiring rather than JSL XML. The Eclipse-based Spring Tool Suite (STS) has “smarts” about Spring Batch as well as other Spring packages, but there is no difficulty in using other development tools that many Java programmers prefer, such as JetBrains IntelliJ IDEA, Microsoft VSCode, Vim, or Emacs.

Customers in an IBM mainframe environment who are already set up with IBM development tools and need to incorporate traditional mainframe assets (MVS Utilities, VSAM, etc.) with the new batch processes will achieve better outcomes with IBM’s Liberty Batch implementation, especially when the target platform for the Java Batch jobs is IBM z, but also in certain other cases. The Liberty Batch implementation, in conjunction with the Liberty Server and additional Java jars such as the JZOS library, provides integration with traditional IBM mainframe assets (MVS utilities, VSAM, etc.) and a familiar developer experience based on IBM Rational tools that extend the Eclipse IDE, with wizards and smart editors to support Liberty Batch development.

JSR-352 was a joint effort of Pivotal, the company mainly supporting Spring; IBM, the company with the most knowledge of batch processing; and GlassFish. IBM’s Christopher Vignola led the team and ensured the rich experience in batch processing that IBM brought to the table was incorporated. Mahesh Kannan of GlassFish did most of the Java EE integration for the reference implementation. Unsurprisingly, Java Batch is compatible with IBM systems, the Spring ecosystem, and the Java EE standard, although this breadth necessarily means particular implementations of Java Batch will be quite different in their details. Some background information about the origin of JSR-352 is documented in an Oracle blog post from 2014.

Tobias Flohre (not associated with us) offers some guidelines for choosing a Java Batch implementation in his 2013 article, “10 criteria for choosing the right implementation of the JSR-352 (Java Batch)”.

Developer experience considerations

In some cases, the developer experience is a “given,” as the organization already has standard tooling and procedures in place. In other cases, the developer experience may be a consideration when deciding on a Java Batch implementation.

The implementations are sufficiently unique that the developer experience can vary considerably. Working with Spring Batch, one builds “chunk” batch steps out of small building blocks, mainly through configuration with relatively little hand-coded Java. The implementation emphasizes composition and delegation. In most cases, this approach makes for pretty straightforward development work and ease of maintenance, but sometimes configuring a chunk step that processes multiple inputs and outputs can become cumbersome. In contrast, working with Liberty Batch, one uses the “batchlet” feature at least as much as the “chunk” feature, writes proportionally more Java code, and uses additional Java jars to access IBM mainframe assets in the job steps. Complicated processing is more often written by hand than composed from pre-built building blocks.

Those differences – the granularity of the building blocks and the relative use of batchlet vs. chunk – make maintaining JSL XML easier with the Liberty Batch implementation, and maintaining configuration in the form of Java annotations easier with the Spring Batch implementation. When a batchlet handles most of the complexity of a step, the JSL needed to configure the step is simpler. When the step is composed from multiple pre-built pieces, the configuration is more complicated. It’s a question of where the complexity resides – in the code or in the configuration. IBM Rational development tools include a JSL XML editor that facilitates creating and maintaining the XML, and the Spring Batch implementation includes “builder” classes that facilitate creating and maintaining Java-based configuration.

The development tooling affects the developer experience, too. In the IBM Rational world, one builds batch jobs and steps by using wizards that generate boilerplate Java classes and JSL. In the Spring Batch world, one uses “smart” editor/IDE features to help customize and assemble pre-built implementation classes and configure them to work together through Java annotations and factory classes.

In addition, Spring Batch is more often used in organizations that make significant use of Open Source projects, while Liberty Batch is more often used in organizations that limit the use of Open Source for reasons of security and support. That means people working with Spring Batch spend some time integrating libraries and coping with compatibility issues, while those working with Liberty Batch spend some time reinventing wheels in order to avoid using external libraries.

In short, there is no “best” implementation, but there is probably a “fit for purpose” implementation that will support your needs.