Java applications in a Liberty JVM server

CICS® provides a Java EE application server that can run lightweight Java™ servlets and JavaServer Pages. Developers can use the rich features of the Liberty in CICS specifications to write Java EE applications for CICS. The application server runs in a JVM server and is built on WebSphere® Application Server Liberty.

Liberty is a lightweight application server for application development that starts quickly and can run on different platforms. It is optimized for Java developers to quickly develop and test applications, requiring a minimal amount of effort to configure and start the web server. Java developers package the application and web server together for simple deployment by using Eclipse tools that are freely available. Web services support available includes Java API for RESTful Web Services (JAX-RS) and Java API for XML Web Services (JAX-WS). For more information about Liberty, see Liberty overview.

Liberty is installed with CICS to run as a application server in a JVM server. The Liberty JVM server supports a subset of the features that are available in Liberty; you can run OSGi applications, Java servlets, and JSP pages. For more information about what features are supported, see Liberty features.

You might want to use the Liberty JVM server and associated tools for any of the following reasons:
  • You want to modernize the presentation interfaces of your CICS application, replacing 3270 screens with web browser and RESTful clients.
  • You want to use Java standards-based development tools to package, co-locate, and manage a web client with other existing CICS applications.
  • You already use Liberty applications in WebSphere Application Server and want to port them to run in CICS.
  • You already use Jetty or similar servlet engines in CICS and want to migrate to an application server that is based on Liberty.
  • You want to use data source definitions to access DB2® databases from Java. See Defining the CICS DB2 connection.
  • You want to coordinate updates made to CICS recoverable resources with updates made to a remote resource manager via a type 4 JDBC database driver, using the Java Transaction API (JTA).
  • You want to develop services that follow REpresentational State Transfer (REST) principles using JAX-RS.
  • You want to develop applications through support of a standard, annotation-based model using JAX-WS.
  • You want to develop Java EE applications that send and receive secure messages via JMS.

CICS exception handling in Liberty applications

Liberty applications can use several different transactional APIs, including the JCICS API. Most Liberty components (except for EJBs) require the explicit use of the Java Transactions API (JTA) to coordinate transactions across those APIs. For example, if you need JCICS and remote JDBC activity to rollback following an Exception issued in application code, you must start a JTA transaction before interacting with the JDBC connection.

CICS implements an automatic rollback-CICS-transactions-on-Exception policy for simple servlets hosted in Liberty. This policy ensures that CICS transactions roll back if an Exception is thrown from an ordinary servlet. This is sufficient to provide basic transactional integration for simple servlets that use the JCICS API, but the policy does not address some of the more complicated scenarios you might encounter.

For example, the rollback-CICS-transactions-on-Exception policy doesn't integrate with other non-CICS resource adapters such as remote JDBC and JCA connections. If you need to coordinate transactions between CICS and other resource managers, you must use JTA to explicitly coordinate the transactions. This causes Liberty, CICS, and the remote transaction managers, to jointly negotiate whether to commit or rollback the transactions.

The rollback-CICS-transactions-on-Exception policy is available for simple servlets, but isn't available to the entire range of extensibility points available in a Liberty environment. Advanced users who exploit other plugin, callback, and extension points might not experience automated rollback of the CICS transaction when throwing an Exception. If you need predictable transactionality for Exceptions thrown from such components, use JTA to coordinate the transactions; an alternative option is to issue an explicit JCICS Abend to force CICS to rollback the CICS transaction for application detected errors.

CICS tasks for Liberty applications

In order for a Liberty application to use the JCICS API and other CICS resources, such as a JDBC DataSource with type 2 connectivity, requests must run under a CICS task. CICS creates a task for an application request at different times, dependent on the type of request. For HTTP requests, a task is created before the Liberty application is invoked. For other types of requests, for example message-driven beans (MDBs), inbound JCA, and remote EJBs, a task is created as required.

If the application does not interact with CICS, no CICS task is created for non-HTTP requests.

CICS performs the following actions when a CICS task is created:
  • The CICS transaction security check occurs.
  • CICS monitoring begins for the task.
  • CICS trace for the task starts.
  • The name of the Java thread is changed to include the CICS task number and transaction ID.
For non-HTTP applications, these actions occur the first time a JCICS API or a JDBC DataSource with type 2 connectivity is used. If the application does not interact with CICS, no CICS monitoring or transaction security occurs.

CICS abend handling for uncaught Java exceptions does not apply unless there is a CICS task. If an application throws an exception before the JCICS API or a JDBC DataSource with type 2 connectivity is used, no AJ05 abend occurs.