Today the dominant form of middleware in the enterprise remains traditional application servers. The challenge going forward will be integrating application servers written in Java with a new generation of so-called “cloud native” applications.
At the Red Hat Summit 2016 conference today, Red Hat moved to enhance its Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP). At the same time, Red Hat promised to make it simpler to integrate JBoss EAP with containerized middleware and applications running on Red Hat’s OpenShift platform-as-a-service (PaaS) environment.
The latest version of JBoss EAP incorporates version 7 of the Java Enterprise Edition (Java EE) application server, and provides access to JBoss Core Services Collection, a suite of Web single sign-on, HTTP load balancing, and proxy, management and monitoring tools that is being provided at no extra charge to IT organizations that have a subscription to Red Hat JBoss Middleware. Included with JBoss Core Services Collection are rights to the Red Hat JBoss Operations Network, which provides a centralized management point for all Red Hat JBoss Middleware products, Apache HTTP server, connectors for IIS and iPlanet web servers, Apache Commons Jsvc, and a single sign-on server based on the open source JBoss Keycloak project.
The latest release of JBoss EAP comes on the heels of Red Hat’s acquisition of 3Scale, a provider of application programming interface (API) management software. Rich Sharples, senior director of product management at Red Hat, says that coupled with JBoss, an OpenShift PaaS that incorporates the open source Kubernetes container orchestration framework, and the FeedHenry backend-as-a-service (BaaS) software that it acquired last year, Red Hat has laid the foundation for integrating a broad range of applications and services. JBoss EAP can deployed as a container on OpenShift alongside, for example, container applications based on Docker.
Arguably, the biggest challenge IT organizations now face is integrating legacy applications with microservices architectures based on containers such as Docker. In some cases, it may make sense to deconstruct an existing service in a way that transforms it into a microservice. At other times, entire monolithic applications may be dropped into a container. Or it may simply be more expedient to invoke those applications and services as they are using an API. Whatever the approach, Red Hat is clearly committed to providing the mechanism that enables any application to be accessed. But it’s going to be up to the individual IT organization to determine which middleware mechanism makes the most amount of sense.