cics link to Liberty JVM Server

CICS TS 5.3 APAR PI63005 delivers this capability.

Hello,
one further comment to the importance of this RFE from our Point of view:
Within CICS we have a number of background transactions running. Within these background transactions we want to reuse existing error checking Java code which is running within WAS applications running on AIX.
Our first try was to transport the complete java application package from WAS to CICS JVMServer. The CICS background transaction always “calls” the Java error checking code at some point within the transaction flow via EXEC CICS LINK into the java code. Because our application architects are on the way using Liberty they demand for liberty within CICS. Which is there, but the ability to call into this liberty code is not possible at the moment.
The conclusion at the moment is that a CICS-centric solution with Java code reuse within Liberty is not possible. If this will not been realized in the very near future (CICS TS 5.3 with PTF) a CICS –centric solution for our CICS background transactions cannot be realized. Once a solution is implemented it will hardly considered for a migration back to CICS.
For our installation PL1 calls into Liberty Java programs would be a huge step further into the direction of using the modern features of the z platform.
Since we want to use Java-code inside CICS-Transactions and providing WebServices inside the CICS (PL1-centric logic with a ws-interface to get rid off the distributed mq and websphere infrastructure), we do not want to use two techniques in providing these solutions (OSGI and liberty). Therefore it is important for us to have not only the java webservices called from outside but also the possibility to call java from cics in liberty
best regards
Peter

CICS TS 5.3 was announced on Oct 5th 2015. See announcement letter http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS215-363

Whilst Link to Liberty will not be in the CICS TS 5.3 GA code base, the announcement letter contained the following statement of direction:

IBM makes the following statements of general direction:

• IBM intends to deliver support for Java applications that exploit Java EE 7 Full Platform features when running in the WebSphere Liberty profile that is integrated with IBM CICS Transaction Server for z/OS (CICS TS).

• IBM intends to deliver additional Java EE 7 components and technologies for the CICS TS hosted WebSphere Liberty profile through continuous delivery of new features in the coming months. These additional components and technologies are intended to include support for Java EE 7 Web Profile features, support for JMS 2.0 with IBM MQ for z/OS, and the ability to LINK from a CICS TS COBOL program to a CICS TS hosted Liberty application.

IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remain at our sole discretion.

Hi, I posted a comment/question back in early August asking for insight on the direction or process on this RFE? Could someone respond, please?

Thanks,
Bill

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

Hi,

I wanted to check on the status of this RFE. What direction is it moving? Are the things that you and "Dish" talked about a possible reality? I work at the same company as Dish, and we wanted to get an idea where this RFE stands.

Thanks,
Bill

Short answer is yes. The transactional context is honoured. Typically, we wouldnt be using a requiresNew and would expect the EJB to be part of the original transaction (or the LINK request). If the EJB was called from another EJB, yes we would expect them to be withing that original JTA context. Does that answer your question?

To help us progress this item, it would be useful to know if their is a requirement that LINK requests to Java components should honour the transactional nature of the EJB container. So for instance if the target method in an EJB was marked as RequiresNew should a LINK to this method start a new CICS UOW and should this be associated with a JTA transaction context as if the request had come from another EJB.

Hello,
We are looking to COBOL to Java inter-operability in CICS. Today our workload is not on CICS but we are building a lot of Java artitifacts in Java and would like our COBOL applications to consume them "natively". We were looking at CICS as an option (we have already looked at JVM Server but bundling in OSGi has been challenging). If we can have EJB's in CICS that could potentially gives us a way to LINK from COBOL to Java from a WAR.
So if you are looking for use cases, we have one.

In the following comment, we assume that when talking about "EBA", an artefact that runs in Liberty and is equal to an OSGi-Bundle in a JVMServer (Java-Main-Class is specified, ...) is meant. When talking about a "WAR-Component", a JAX-WS (SOAP) and/or JAX-RS (JSON, ...) WebService packaged in a way that it also runs in "distributed" Liberty (on AIX, ...) and is accessible via http is meant.

As our developers are experienced in building JAX-RS and JAX-WS WebServices, we see the need that the Java-Developers can implement their Services as WAR-Components. COBOL/C-Developers need to access these services in these WAR-Files via CICS LINK. In this case, CICS should take care of the necessary marshalling from COBOL/C to JAVA.

To sum up, we have the requirement to be able to LINK from a COBOL/C Program to a JAX-WS/JAX-RS-Service implemented in a WAR-Component.

This RFE is being used to track the work to allowing existing CICS (i.e. COBOL) applications to call into a Web application components in a LibertyJVM server using a procedural call.
To help us progress this item, it would be useful to know if the packaging of the Java component is important to the solution, as currently Java components deployed into a Liberty JVM server can be pacakged as WARs (dynamic Web projects) or EBAs (OSGi application projects) . Specifically is there any requirement to support access into WAR components in addition to OSGi packaged components in an EBA?

In our view, Liberty is not only positioned as a server for the "presentation" but also for "business logic". We assume, that in the future, Liberty will offer more capabilities than JVMServer. We would like to use Liberty as our standard-runtime for Java in CICS.
To make use of this “business logic” in Liberty from legacy applications (COBOL, ASSEMBLER, ...) we need to be able to call this “business logic” from within COBOL in in an easy, fast and highly integrated way and so we need to be able to LINK from COBOL to this “business logic”.
So our requirement is to use Java-logic in Liberty in the same way as we can do currently with JVMServer, i. e. define a ppt-entry for Liberty-classes.

So would you like to see a single JVM environment with all the capability that Liberty has which can be used as a first, second or even third tier i.e. presentation, business logic or data access in the application architecture?

In our view, Liberty is becoming the premier runtime-environment for Java-applications in CICS. It supports (and hopefully continues to extend the support) more and more of the “state-of-the-art” Java-APIs like BeanValidation, … . A “pure JVM”-Environment (as offered by the JVM-Server) does not offer enough functionality for our developers as we want to port more and more WebSphere-Businesslogic (using JNDI, JPA, JMS, …) to CICS. To be able to use this Java-Businesslogic also from COBOL in an easy, fast and highly integrated way (which for us is the value-proposition for Java in CICS), we need to be able to LINK from COBOL to this Java-Businesslogic.

I think there are 2 scenarios here:
1. Similar to http://ibmtvdemo.edgesuite.net/software/htp/cics/2014_06_05_2311_Cloud_web_application_concurre.mp4 the PL/I or COBOL is packaged in the same application as the Java deployed to Liberty so EXEC CICS LINK is the right choice as you should get the same version. The demo shows Java -> COBOL using LINK while this RFE would allow the reverse. Also using LINK means the PL/I programmer is not aware of how the PROGRAM is implemented
2. The Java is a separate shared component with its own entry points so you can use INVOKE APPLICATION and choose the version.

A small upgrade for this: It should not be an Exec Cics Link, but more the new Context of an INVOKE APPLICATION. Of a todays point of view an Cics Link is not the best thing here, because it is not possible to give a version to this context.

Possible Scenarios:

1) PL1 to Liberty
2) LIberty to PL1
3) Liberty to Liberty

Maybe other customers also need this contexts:

4) PL1 to OSGI
5) OSGI to Liberty
6) Liberty to OSGI

For Wüstenrot, we don't have OSGI yet and at the moment this is not clear. I will make an update of this RFE for Point 4 to 6 as possible.

We are interested in all three options in the following directions:

1. „Your topic 3: To develop non-web Java applications using the APIs and features provided by Liberty (such as JNDI, JPA etc)”
Additional info: To have a consolidated runtime, it would be nice if the “non-web Java application” would also run in Liberty. In our opinion, Liberty should not only accept input from “the web” but also from “CICS LINK” (a new “inbound channel” within Liberty?)

2. “Your topic 1: Allowing existing CICS applications to call into a Web application components in the same CICS region using a procedural call (such as LINK with COMMAREA or channel)”
Additional info: It should be possible that the “Web application component” participates in the same “unit of work” as the “existing CICS application”.

3. “Your topic 2: Allowing existing CICS applications to more call into Web application components in the same CICS region using the HTTPRequest interfaces already exposed... (Note this is already possible today, but has no local optimizations)”
Additional info: Yes, it is possible today using HTTPRequest, but we think that "Local optimization" is very important for high frequented applications.

We are mainly interested in your point 1. allow an EXEC CICS Link from a PL/1 Program to a Liberty and backwards.

We have allready used the 2nd point in Cics 5.1. It works, but this is not the best way doing it. We think a more direct way would be better.

Why do we do this? At the moment we use this with the primefaces push technology to allow a 3270 Terminal to push to a web browser.

At the moment it looks like, that in the next 2 to 10 years we will have a mixed environment. (3270 and browser/gui) and we need a way to to easy interact between this to user interfaces. For a example a user has an application in a 3270 and now he wants to select a customer for a product in this application. This application now jumps into liberty and pushes the customer selection into the browser. There he selects a customer and the the application with the selected customer continues in the 3270.

The main reason for this is, that you don't program immediately every PL/1 Program in Java. The company don't has this resources, but you will take parts and change them.

Our main architecture should give the possibility with the platform/application context to say ok just inquire an application over an entry point, and afterwards the application decides where it is running.

This sort of Component based design should give different teams the ability to independently change their components.

We are discussing this requirement in further details and it would be useful to know if those who have voted on this are interested in the following options:

1. Allowing existing CICS applications to call into a Web application components in the same CICS region using a procedural call (such as LINK with COMMAREA or channel)
2. Allowing existing CICS applications to more call into Web application components in the same CICS region using the HTTPRequest interfaces already exposed... (Note this is already possible today, but has no local optimizations)
3. To develop non-web Java applications using the APIs and features provided by Liberty (such as JNDI, JPA etc)

If there are multiple options, then relative priority would be useful to know

Liberty is becoming the premier platform for "Java in CICS" as it will support various important features like JNDI, JTA, JMS, ... . It is important to get the functionality to also call into this environment from COBOL.