Java in CICS: The Inevitable Future
CICSChina 270002RWEH Visits (8162)
Java in CICS: The Inevitable Future
Author: Ivan Hargreaves in z/Jo
That presents a problem. This article is about the radical new Java support in CICS, the long-term vitality and future of application development in CICS, and making Java a first-class language in which to write CICS applications and access your wealth of CICS data.
You don't want to hear about this because you have a succession of young COBOL programmers enthusiastic about writing 3270 applications for years to come, right? Maybe not. Perhaps it's fortunate there have been huge advances in Java Virtual Machine (JVM) performance since Java was introduced to CICS. It's fortunate IBM offers the specialty processors to run Java workloads at a fraction of the cost of general processors, and that Java programmers are far more abundant than COBOL programmers.
Furthermore, CICS has introduced a radical new Java model known as JVM server that significantly enhances both the development and run-time aspects of Java in CICS.
For several releases, CICS has used a “pooled” model of Java. Each transaction wishing to run some Java is gifted a whole JVM to itself. Each transaction is also offered an Application Program Interface (API) to access CICS resources. However, to serve concurrent transactions requires multiple JVMs. The JVMs are pooled to help reduce start-up and shutdown overhead. Yet this isolation of Java programs has a cost; there are only so many JVMs you can fit in a CICS address space and only so many Java transactions a single CICS region can process.
Not anymore. JVM server runs Java the way it was meant to be run. The JVM server is essentially a single, long-running JVM placed under the control of CICS. Its defining principle is the ability to run many CICS tasks concurrently. In this new model, each CICS transaction runs as a thread in the same JVM. As you might expect, compared with the pooled model, which requires an exclusive JVM per task, the storage savings can be significant (see Figure 1).
Sound good so far? It gets better. The JVM server also scales horizontally. Multiple JVM servers can be deployed into a single CICS region. Theoretically, you could even choose to deploy hundreds of JVM servers into one CICS region. Applications can be isolated in different servers, or each JVM server can be configured with a different set of run-time components—or even different sets of middleware components—keeping each server lightweight and specific to a particular need.
But didn't we just say there are only so many JVMs you can fit in a CICS address space? We weren't talking about JVM servers in CICS Transaction Server 4.2, which take full advantage of the IBM 64-bit JVM. For these JVMs, storage can be held above the bar. No longer constrained by a 31-bit address space, you can choose to run huge applications and hundreds of JVM servers.
Yet another key advantage is the IBM 6.0.1 JVM. This JVM is optimized for the zEnterprise hardware, offering significant performance improvements over previous IBM JVMs.
These improvements lead to scalability way beyond that of previous CICS releases. The JVM server, with its reduced overhead and large above the bar heap, yields significant advantages for CICS TS 4.2.
Server-Side Java Enablement
With the advent of JVM server comes other benefits such as a significant increase in the types of Java workload that can run in CICS. Most notable is the ability to run a server application in a JVM server and handle multiple requests for service. Due to its more standard architecture, CICS TS 4.2 has been opened up to countless Java frameworks; it gives CICS the potential to plug in application servers when new capabilities become available. Another benefit of using a single, shared JVM (and particularly relevant to the application server model) is the ability to share data and state.
But isn't that what WebSphere Application Server (WAS) does? There are similarities. Both JVM server and WAS use a JVM to run applications. Allowing these applications to run in either environment would be wise, but there are notable differences. First and foremost, CICS JVM server doesn’t provide Java Enterprise Edition (Java EE, formerly J2EE) capabilities. However, for Java Standard Edition (Java SE) applications you can locate your Java applications alongside your CICS data and use your skilled Java programmers to write applications that control CICS assets directly.
One exploiter of this new JVM model is the WebSphere Operational Decision Management (WODM) product. In the CICS JVM environment, WODM provides an optimized business rule execution environment for evaluating business decisions. Typically, the business rules that are externalized would previously have been coded in an existing CICS application.
Externalizing the rules lets you manage changes in your business policies on a separate lifecycle than the typically much longer application update lifecycles. Hosting the decision server environment in a JVM server in CICS can provide the application agility so many organizations desire without the disadvantages of the application becoming dispersed across additional run-times (and the increased complexity this creates). Having the decision server run in CICS allows evaluation of the rules right where the application data resides and lets the decision lifecycle be managed as part of established CICS administration processes.
The JVMSERVER Resource
The foundation of the new model of Java in CICS is the JVMSERVER resource. The JVMSERVER resource encapsulates the JVM and provides control over its lifecycle. By keeping the JVM lifecycle distinct from the run-time, start-up costs and application bootstrap times are no longer incurred on the critical path.
The JVMSERVER resource also provides a configurable thread limit, which determines the number of threads a JVM server can run concurrently and therefore the number of tasks it can serve concurrently. By varying this value, you can throttle the number of threads (T8 Task Control Blocks [TCBs]) available for concurrent activity. Up to 256 threads are allowed per JVMSERVER. Any request that arrives while all threads are in action will cause that task to queue until a thread becomes available.
For system administrators keen to squeeze every bit of performance out of the JVM server, additional fine-tuning and low-level configuration of both the JVM and the underlying Language Environment (LE) enclave can be achieved using the LE run-time options and JVM profile artifacts. Each time the JVMSERVER resource is enabled, it rereads configuration from these files, allowing changes to the enclave characteristics or JVM settings. Typically, users may want to generate LE storage reports, or tune the JVM heap size, garbage collection model, or Just in Time (JIT) settings.
The resource also provides a convenient way to view the workload and other metrics. Thread count, maximum and current heap sizes, heap occupancy, cumulative thread count, and garbage collection are all displayed when you inquire on the resource (see Figure 2).
Finally, there’s the added benefit of standard Java debugging. Eclipse can attach a debugger to the JVM server. The single JVM makes it significantly easier to debug than the pooled model because all workloads appear as threads in the JVM. Previously, even identifying which JVM in the pool you needed was challenging.
CICS Development Environment
Anyone who has tried to write Java for CICS in the past deserves a medal. The lack of a proper development environment is quite irksome. Editing Java code on zFS (the z/OS Distributed File Service zSeries File System), if you've ever tried, is as cumbersome as eating a bar of chocolate with a fork while wearing gloves, and if you write Java code on the client, then you have File Transfer Protocol (FTP) and codepage conversion pitfalls to worry about. There’s no standard deployment mechanism, and no easy way to track what versions of code you might have uploaded to CICS. When you come from a world of code completion, syntax checking, error highlighting, color coding, dependency checking, background compiles, module outlines, and so on, how could you ever manage without it? Why should you ever manage without it?
There’s good news. CICS has provided the CICS Explorer SDK; it’s free to download and plugs right into Eclipse. You can have all the power of Eclipse while writing code to the Java CICS (JCICS) API, which provides access to CICS resources and data.
The Javadoc for the JCICS API is built-in and readily available. Moreover, the code is compiled in situ, right there in Eclipse. You don't need to worry about deploying your code to CICS; there's a wizard for that. The wizard can create and upload application code directly to the JVM server. There's a wizard in the SDK for just about any operation you want to perform.
The CICS Explorer SDK is a super-set of the CICS Explorer client, so you get all of Explorer's functionality plus the fantastic “development” benefits (see Figure 3); we'll come back to CICS Explorer SDK later.
Java's Soft Underbelly
Let's take a detour back into the realm of run-time. The humble JAR file has been the workhorse of Java packaging for many years, but truth be told, it’s a bit limited. A JAR file is really just a primitive packaging mechanism; it has no scope. There’s no way to determine dependencies between JAR files; JAR files can’t easily be versioned, nor can declarations of interfaces be made available (or consumed).
Things get worse when you have a whole herd of these JAR files roaming loose. They can really clutter up your classpath. Indeed, once loaded, should you replace one or more JARs with newer code, the JVM won't notice and it will never go back to your newer JAR to get the refreshed code. Your only option is to restart the JVM, unless you implement some fancy footwork through class loaders. The same problem arises when you want to add new applications to your classpath; it's JVM restart or fancy footwork again!
If you've had half an eye on the Java world, you probably know where we're going with this, so without further suspense, let's take a look at Open Services Gateway initiative (OSGi).
The OSGi Alliance is an open standards organization that maintains the OSGi standard. The OSGi specification is a module system and service platform for the Java programming language that implements a complete, dynamic component model.
OSGi is a framework into which you install your applications. Applications are built from components (OSGi bundles) that are scoped collections of Java classes with well-defined interfaces. The framework provides added value beyond the JVM so you can add and remove your applications without restarting the JVM. Applications can also be fully componentized via one of more OSGi bundles. For more loosely coupled interactions, particularly where replacement implementations are envisioned, you should consider registering your OSGi bundles as OSGi services so you can swap them in and out more easily.
One of the benefits of a more defined interface between OSGi bundles (especially compared to JAR files) is that any missing dependencies can be highlighted well in advance of receiving the dreaded “Cla
OSGi and CICS
Support for the OSGi standard means that applications written for the JVM server (and migrated from pooled JVMs) will be packaged as OSGi bundles. Although an OSGi bundle sounds alien and complicated, it's really just a JAR file on steroids. It’s a zipped up collection of Java classes, usually with some commonality, and some additional manifest headers. The only differentiator between a JAR and an OSGi bundle is the additional set of headers in the manifest file (see Figure 4).
An OSGi bundle is especially useful because it will still run in a non-OSGi environment; it’s really just a JAR. Conceptually, however, an OSGi bundle is more powerful than a JAR. To realize its full potential (dynamic install and upgrade, dependency checking, support for multiple versions of an application, etc.), you would want to install the bundle into an OSGi framework.
The JVM server has one of these. CICS TS 4.2 uses the Equinox version 3.6.1 implementation of an OSGi framework. The Equinox implementation, also seen in Eclipse, supports version 4 of the OSGi Service Platform specification.
CICS Explorer SDK
That brings us back to the CICS Explorer SDK, with a plug-in that delivers an end-to-end experience for developing, deploying, and managing CICS Java applications. When the plug-in is installed into the appropriate Eclipse-based IDE, users can take advantage of the concise documentation, built-in examples, and simple deployment to have a CICS application running in minutes.
An application that runs in a JVM server is developed as one or more Eclipse plug-in projects, each of which produces an OSGi bundle. An accompanying CICS bundle project is used to package, deploy, and install the finished application into a particular CICS region or CICSplex. Plat
It's worth stressing here that a CICS bundle isn’t an OSGi bundle. Rather, a CICS bundle may contain OSGi bundles and is a vehicle for deploying them into CICS and controlling their dynamic lifecycle. You may have encountered CICS bundles before (the BUNDLE resource), especially if you've looked at Atom services or event processing in CICS (see Figure 5).
The Eclipse-based development environment also offers options for customers migrating Java applications from earlier versions of CICS. Perhaps those wishing to maintain coexistence with the pooled JVM run-time can simply take advantage of the improved experience of using OSGi. Yet applications destined for JVM server must be deployed as OSGi bundles, and Eclipse offers the following techniques to help:
One click converts your existing Java project into a plug-in project. Use the PDE to check for unsupported dependencies. You can still run the deployed code in a pooled JVM by adding the OSGi bundle JAR files to the class path in your JVM profile.
Use the new project wizard to take an existing JAR file and automatically inject the required OSGi manifest file. The code doesn’t need to be recompiled, reducing the need for extensive retesting. Use this technique if you want to redeploy to both pooled JVMs and JVM servers.
Use the new project wizard to “wrapper” an existing JAR file and automatically add the required OSGi manifest file. Use this approach if licensing or other restrictions prevent artifact modification.
Whether your plans to move to JVM server are long- or short-term, you can start taking advantage of OSGi today. The Explorer SDK is aimed at both experienced Java application developers who are new to CICS and those with a CICS application development background. The plug-in extends the familiar Java developer User Interface (UI) with the documentation and tools necessary to target a CICS environment.
This article described how both significant evolutionary enhancements and fundamental architectural changes have dramatically raised the value proposition for developing CICS applications in Java. CICS provides the development environment and run-time support to reuse existing Java components to the benefit of existing and new CICS applications. In addition, the reduction of costs that can accrue from using the IBM System z Application Assist Processors (zAAP) make this an attractive workload to run in CICS.
The JVM server represents a move to a more standard Java experience in CICS to provide a server-side programming model where applications can share an “engine” as well as data between tasks.
Support for the OSGi standard means that applications written for the JVM server or migrated from pooled JVMs can be packaged as OSGi bundles to enable dynamic deployment, replacement, and versioning of applications in the JVM server without needing to restart the JVM.
The skills required to develop, debug, and monitor Java applications are based around familiar tools such as Eclipse, CICS Explorer, and Rational Application Developer for System z. The availability of standard tools for debugging, problem determination, and performance monitoring encourages skills reuse and eases knowledge transfer.
The dramatic enhancements to the Java support in CICS TS 4.2 represent a game-changing shift in the technology used to run Java applications in CICS. There has never been a better time to consider using Java applications in CICS TS.
Java support in CICS: http
CICS Explorer downloads, including the SDK: www.
Whitepaper on rules for z/OS: http
Further information on WebSphere Operational Decision Management