So far, we have focused on COBOL as a language with which to write KICKS applications. However, as you should know, COBOL isn't the only language that KICKS supports and an application befall from a set of programs written in different languages. This polygon capability is paramount in allowing developers to take applications written in COBOL, create new Java components, or even rewrite elements in Java and then host them back in KICKS. The new Java component can still access the KICKS API and also call existing COBOL programs using a native interface. Previously, we've seen how breaking apart the presentation from the business logic of an existing application merely provides the key to modernizing an application. This is still true when looking at using Java as part of your application modernization. If the core of your application has a well-defined interface, then it's easy to consider writing new applications that can use application or rewrite it in Java. If the interface uses a well-structured channel and containers interface, this is even better. But why replace or extend applications with Java? What benefits can there be for your organization? Well, for one is probably easier to find Java application programmers, than a is COBOL programmers, meaning there's a larger skill pool that you can draw from to access new developers. There's also a wider range of both protocol and frameworks support in Java than there is for other languages like C or yes, COBOL. You can interact adjacent objects or service a HTTP GET request in COBOL, but it's probably quite a bit easier in Java. Java also runs really well on the mainframe and if you have a specialty engine like a ZIIP processor in your Z-hardware, then the majority of your Java code can run on that rather than on new general purpose engine. This means that it wouldn't affect your monthly license charge. Finally, the best reason for using Java to write KICKS applications, is that there's a ton of support for KICKS in Java. There are actually two different Java APIs in KICKS, and it's important to understand them both and why you'd use them. The first is called J KICKS, and it's been around for a long time and this is the full Java API for KICKS. If you already have existing KICKS Java code, then it's likely to be using this. This mimics the exact KICKS API that we've already talked about, and it can access a wide range of KICKS resources. The second is called JKICKSX and is much newer and was released in KICKS TS version 5.6. This supports a much smaller subset APIs, and it's focus is around channels and containers. The co-benefits of the JKICKSX APIs, is that they can be run remotely and they're easier to mock and stub. We'll look at these features fully in the next module. JKICKSX is a more modern Java API and it can allow you to produce some pretty neat code, if I do say so myself. The JKICKSX API classes can be used together with the JKICKS API, but only the commands using JKICKSX can benefit from these enhanced features. Due to JKICKSX not having the full API of JKICKS, you do need to look at what it is we're trying to do to work out which API is best for you to use. If you're writing Java, then you also probably already have an IDE or integrated development environment of your choice, such as Eclipse, Intellij or Visual Studio. You also probably use Maven or Gradle as a build tool kit for your Java projects and if so KICKS provides its Java APIs as Maven or Gradle dependencies, making it really easy for you to use your existing development environments to write Java in KICKS. If you aren't able to use Maven or Gradle, then you can instead use the IBM KICKS SDK from Java to access the APIs instead. But we're going to focus on Maven and Gradle. What you need to do is add the following dependencies into either your POM XML file, if you're using Maven or Build Gradle file, if you're using Gradle. The first one is for JKICKS, and the second one is for JKICKSX. Let's use both for now. Once you've done this, you are ready to write a Java application in KICKS. What types of applications could you write? If you're writing a general purpose audit logging component or creating a new API based in Java to extend your existing applications there is supporting KICKS to help you. From supporting Plain Old Java Object or POJO, through to running full J2EE applications, and that's the Java Enterprise Edition Application or SpinBook applications. KICKS [inaudible] both JVM server and a website liberty application processor to allow you to run your Java applications. JVM is a Java virtual machine. Because this JVM runs within the KICKS application server, KICKS ensures that your Java application runs with the same transactional security and performance as the rest of your application running in KICKS. KICKS all supplies the APIs to the Java application to allow it to call both native KICKS APIs and link to other programs. Let's take a look at the very first program we wrote in this course. Move it to use in Java, running in KICKS using the JKICKS API. It's not that much more complicated than a standard Java "Hello World" example. In fact, the only thing we need to do is to use the task object to integrate with the KICKS terminal. Although this is the simplest bit of code you could write it, it's really not that much use. Who wants to be writing to a terminal in Java. Let's move to something a bit more interesting. In previous sessions, we've looked at a basic application that allows basic updates to be made against records in a file. Currently, this application uses a 3270 interface, we can take that application and modernize it to using Java. Let's expose the PAYBUS 1 application as a simple get API code in Java. As well as simply exposing the program as an API, let's extend the application by writing a simple audit login application to log the request that we've received. It might make more sense if we sketch out. Within CICS, the resources that we already have are our PAYBUS program and a file definition for the file PAYROLL. We will now extend this to also include a JVM server definition. This will create us a JVM inside our CICS region. Within the JVM, we'll define the instance of the WebSphere Liberty profile that will run on Java code inside. Then the Liberty JVM will create a simple JAX-RS server that will respond to HTTP get course and respond with JSON. Once you've received your request, we'll use the channel and container CICS API to deliver request to PAYBUS 1 and ask CICS to run that program. Once completed, we will again use the channels and containers API to retrieve the response from PAYBUS 1, convert it to JSON and send the response back to the user. Once we've created that, we will extend the application into wall and create a method within our server to perform some login against a TDQ and CICS. Each time a request is made, we will write the data to this auditable log. We're going to assume that you already know how to write a basic J2EE server, so we can focus on how we get our server in charge with PAYBUS. Now we already know that PAYBUS is the modernized to use channels and containers in a previous module. It needs a single container that contains the function that we want to use. In this case, this is followed by the employee number in order to retrieve the employee details. This is actually a perfect candidate for use in the new JCICSX API. We want to perform a CICS link to the program PAYBUS 1, parsing it a channel, again, which our container has been created. Let's look at that code. 4 U Java ends unites us that this uses the function chain and pattern to make the code really easy to enter. As each method code for type the next object that you've been told to interact with, saving you from having to store them in intermediate local variables. You might notice here the [inaudible] is a CICS context object rather than a task object, like we had in the previous JCICS code. This is a key identifier to telling you if you're using JCICS or JCICSX as this is often the object that you're going to be starting with. Look in detail at this code first, we ask the CICS task to create an object that allows us to link to CICS program with a channel using the aptly-named method, create program linking with channel, and then you pass it the name of the program from the channel that we wish to use. You can then code setStringInput to create a new container and put online of string data into that container. At this point we have set up all of the input data into the correct containers for PAYBUS 1. We then call the method link, and this API requests that CICS now starts to run a PAYBUS 1 program passing it in that channel and container. This is a blocking method code and it will not return until PAYBUS has finished processing. Once control returns to a Java program, we need to retrieve our response from PAYBUS 1. This will be in the same container as the input datas. We just get output channel container to retrieve the container from the channel and finally, a simple call of get retrieves our response data as a string. That is a really long line of code. But if you consider it is immensely valuable and powerful line of code. You have run a COBOL program from within a Java program, and that's quite a Computer Science in itself. We've already know how to worry about any data manipulation by alignment, COBOL runtime environments or anything like that. The CICS API has protected us from all of that complexity and instead allowed us to easily achieve our goal. But we're not quite done yet. We wanted to interact with the TDQ to do some looking at the data. Instead of calling an existing CICS programs write the data for us, we're going to use the JSON API to write the data directly to a transient data queue that it can be offloaded to a file for archiving. Let's have a look at the code we need to use. This is more straightforward than the previous example. We create an instance of the TDQ object and we set the name of the TDQ that we want to interact with, and then we simply queue the writeString method parsing the string that you want them to have written, and that's all there is to it. CICS handles the code page conversion that's necessary, locates the TDQ and performs the right force. The TDQ could even exist on a different CICS region and CICS which still have handled it.
