- Eclipse MicroProfile 1.2 is now supported in CICS TS V5.4
- Support available in CICS through APAR PI91554
CICS TS V5.4 now supports Eclipse MicroProfile 1.2, enabling developers to write Java-based microservices and host them in CICS Liberty JVM servers.
In recent years a new paradigm has formed for developing service orientated applications: the microservice. Fueled by new technologies for provisioning containerised applications in the cloud, there has been a large shift in architectures. Even Enterprise Java has followed these shifts, releasing new specifications like JAX-RS and JSON-P to aid developers to write webservices. The biggest change has been in the Enterprise Java runtimes, becoming smaller and more configurable. Eclipse MicroProfile has been born out of these runtimes coming together to share the ideas and implementations between the platforms in a new, community driven, specification.
This support is available in WebSphere Liberty version 18.104.22.168, and available in CICS through APAR PI91554.
What’s the difference between Java EE and Eclipse MicroProfile?
The Java Platform, Enterprise Edition, provides the APIs and runtime environment for large-scale, multi-tiered, scalable, reliable, and secure network applications. Supported applications include web, EJBs, and Java batch applications. Supported features include Servlets, JavaServer Pages, REST and SOAP web services, XML, e-mail, messaging, and transactions, amongst others.
Eclipse MicroProfile is built on top of existing Java EE APIs. It provides APIs for resilient and secure microservices. Supported features include REST web services, JSON processing, fault tolerance, JSON web tokens (JWT), health monitoring and application configuration. MicroProfile also takes advantage of new language features released in Java SE 8. In CICS, both Java EE and Eclipse MicroProfile are provided by WebSphere Application Server Liberty for z/OS, managed by the JVMSERVER resource.
It’s important to note that Java EE and MicroProfile are not competing standards, they both target different architectures and styles of development and are both managed by the Eclipse Foundation. There are already plans in place to add MicroProfile features into future Java EE releases.
The monolith and the microservice
In this modern world of cloud, containers and virtualisation the architecture of having services separated into small, loosely coupled, parts has become increasingly popular. Services communicate using a language-agnostic protocol in an agreed data format. Typically HTTP and JSON are used, but are not limited to them. Some microservices use a cross memory protocol and a binary data format – similar to CICS distributed program link!
Microservices are designed to be the opposite of a monolithic architecture, a web of interconnected parts which do a singular, specific, function. As opposed to a single black box which does everything. Splitting out services allows development to be done in parallel by different development teams, it allows multiple services of the same type to be run, scaling the system horizontally. It even allows resilience to be built into the system, so a failure in a single node doesn’t need to disrupt the entire web.
MicroProfile brings in new capabilities into the enterprise world to enhance the developer experience of building Java microservices: Fault Tolerance provides strategies for coping with failures when invoking other nodes, such as retries, fallbacks and circuit breakers. JWT Propagation enhances the existing JSON Web Token technologies to include role based access control (RBAC) for microservices. Health Check allows state of microservices to be published for consumption by cloud orchestration frameworks. Metrics allows the microservice to export monitoring data, and Config allows applications to read configuration data and respond to changes with needing to recompile.
Using a microservices architecture brings new challenges; the biggest known challenges in microservices is co-ordinating resource updates across several different services. The current advice is to avoid transactions which span multiple services, instead favoring event-based approaches to manage updates that propagate through services. This means many of the MicroProfile features do not guarantee transactionality, particularly the Fault Tolerance specification; transaction boundaries are not created for the CICS UOW on these methods. For example, updates in a method annotated
@Retry will not run in a separate CICS UOW. If failure occurs and the retry method is driven more than once, the transactional resource is (undesirably) updated more than once. Fault Tolerance is designed to manage calls to other microservices and not for updating transaction resources, our advice is to avoid making updates to CICS resources in methods annotated
CICS provides the opportunity to host Eclipse MicroProfile microservices in close proximity to data and services on the mainframe with good integration with existing data, services, and workloads. The CICS team are continuing to look at what is coming next for Java and microservices, and weâ€™d love to hear about your experiences in the comments below.