In September 2017, Oracle announced their decision, with the agreement of market actors like IBM and RedHat, to transfer JavaEE technologies to the Eclipse Foundation “in order to make the process of evolving these standards more agile, flexible and open” [4].
This announcement caused a earthquake among the Java community and raised questions about the future of the platform, on the positioning of Eclipse MicroProfile and about the achievement status of this transition.
Like every year, DocDoku¹ was at EclipseCon France 2018, annual meeting of Eclipse Community in Toulouse.
Every year a special focus is put on a topic. This year, the Java Enterprise Platform was under the lights.
As I’m myself always looking around for news about this platform, I took advantage of the unique day I was able to attend to focus on JakartaEE and MicroProfile.

JakartaEE

JakartaEE

At the beginning of this year, the community chose the name JakartaEE for what Oracle previously named JavaEE. Indeed Oracle wanted to keep its rights on Java trademark, that’s why a new name had to be found.
By the end of 2017 however, the Eclipse Foundation annouced the creation of the new project Eclipse Enterprise for Java (EE4J).

EE4J or JakartaEE?

Actually Eclipse Enterprise for Java [5] is the top level project for everything concerning JavaEE technologies transferred to Eclipse Foundation, that is APIs but also Reference implementations.
Eclipse JakartaEE Platform [6] is consequently a sub-project of EE4J which focuses on what was JavaEE platform specifications: The description of an execution environment based on a set of API specification.
On the same model, we can find a sub-project for each API (Servlet, EJB, …) but also for each reference implementation developed by Oracle or the Eclipse Foundation like Yasson, EclipseLink, Glassfish, Grizzly, Jersey, …

Status of the transition?

Transferring technologies is actually a longer process than one can imagine at first sight because Oracle has to achieve a lot of checking (Intellectual Property, Licensing, …) for each transfered element.
On the other hand, Oracle CTS²/TCK³ are not free.
We’re informed the transition will be a several step process:

• Make JakartaEE 8 officially JavaEE 8 Compatible.That is provide a JakartaEE Reference Implementation that pass current Oracle CTS and TCK.
• Provide free JakartaEE CTS and TCK, and make sure JakartaEE pass these free compliance tests.
• Once these two obectives completed, JakartaEE will be able to evolve following standard Eclipse Foundation project workflow.

Looking at progress status we can see the migration of most of subprojects is almost completed.

About licensing

The current Oracle licensing system (CDDL⁴ and GPL⁵v2 for API specifications and implementations, TLDA⁶ for TCK and JavaEE trademark) are going to move to Eclipse Public License (EPLv2) (and GPLv2)

How the platform is going to evolve?

API specifications won’t evolve anymore following JCP⁷ and JSRs⁸, but will evolve following Eclipse Working Group process.
Beacause of this process change, the Eclipse Foundation hopes more agility and flexibility for the platform evolution.
The strategy shall be based on a posteriori standardization of proven good ideas on the model of the the well known projetcs Hibernate, Weld, Jersey that were standardized as JPA, CDI and JAX-RS.
Note the JCP does not disappear, it continues for everything concerning JavaSE.

JakartaEE vs. MicroProfile

With JavaEE 6 came the concept of profiles (Web Profile, Full Profile), considering that some applications did not use the whole set of JavaEE technologies (especially web applications).
With Cloud Computing raising and success of micro-service architecture based on VM, Eclipse MicroProfile proposed a very lightweight profile, direct competitor to Spring Boot [7], based on a limited set of standard JavaEE APIs (CDI, JAX-RS et JSON-P) and new APIs (Config, Health, Metrics, …).

MicroProfile

Eclipse MicroProfile [8] is an alternative profile (i.e. set of API) dedicated to micro-service based applications.
At first based on a very small API set, the platform evolves as shown in the table [Table:1]

One of the strength of open specifications, like JEE, is the capacity to gather different vendors. Like with JavaEE (IBM WebSphere, RedHat JBoss/WildFly, Oracle WebLogic, …) There are several vendors providing MicroProfile implementations (see table [Table:2]).

There are various way to deploy applications with MicroProfile implementations:

• Application, dependencies and runtime are all packaged in a unique executable JAR.Format popularized by Maven et Spring Boot, the size of the archive can become so huge that this packaging may cause issues in case o f frequent deployments (continuous deployment).
• A JAR archive contains runtime and APIs, A WAR archive contains only business resources and potential third-party dependencies.As WAR file is ligther, it is faster to transfer and deploy. This deployment mode is actually similar to the way applications are deployed in JavaEE.

12-Factor Application

As a reminder, “12-Factor Application” is a methodology for efficient SAAS⁹.
The 12 factors are:

1. One codebase, under revision control(Codebase)
2. Explicitly declared and isolated dependencies (Dependencies)
3. Do not store configuration in the code (Config)
4. Backing services seen as attached resources (Backing services)
5. Strict separation between application build, release and execution (Build, release,run
6. Application processes are stateless Processes
7. Services are exposed via network ports (Port Binding)
8. Application is based on concurrent processes (Concurrency)
9. The application can be started and stopped properly, even in case of crash (Disposability)
10. Keep every deployment environments (development, staging, production) as similar as possible (Dev/Prod parity)
11. Logs seen as an event flow, independent of the way events are stored (Logs)
12. Administration processes run in the same environment than the application (Admin Process)

Emily Jiang [2] shows MicroProfile and Kubernetes allow to implement an application according to these principles.

Codebase

Application source code is managed by Git (on GitHub).

Dependencies

Application build and dependecies are managed by Maven.

Config

Kubernetes’ configmaps and Config l’API are use to inject configuration properties.

Build-Release-Run

A Continuous Integration pipeline manages application packaging for each environment.

Processes

REST API is used to implement stateless processes.

Port Binding

Kubernetes and Config API manage port binding.

Concurrency

microservice based architecture and Kubernetes allow application scaling.

Disposable

Fault Tolerance API make the application resilient to crashes.

Dev/Prod Parity

Using Kubernetes Helm environments are similar.

Logs

Using ELK¹⁰, logs are indexed and can be browsed easily.

Admin Process

Kubernetes standard tooling(kubectl exec) allows running administration processes.

Stateless security with JWT

Security is a very important aspect for most enterprise applications. That’s probably why this aspect is taken into account since the very begining of JavaEE Platform.
Micro-service architecture (“SOA with a sexy name” as Jean-Louis Monteiro [3] said) makes no exception, but statelessness required for scalability imposes new practices.
Jean-Louis discussed the different way to manage authentication and identity propagation:

Basic Auth

This simple authentication method has several drawbacks:
– The login/password pair is transfered for each request

– A DOS atttack is possible for the security registry

OAuth 2.0

Based on token pair (access/refresh) create finally something similar to HTTP session as every generated token has to be stored on the server side. This consumes memory and CPU time as every micro-service has to check tokens.

JWT

This is a token format, similar to SAML but based on JSON. JWT tokens contain signed and potentially encrypted data. In this case, signed data (i.e. the token can’t be altered) are stored on the client-side.

Mixing JWT + OAuth 2.0 reduces a lot the needed resources on the server-side as only token references need to be stored on the server-side (for revocation management) and each micro-service can verify token signature by itself.
A demo of the implementation of this mechanism with the JWT propagation API from Eclipse MicroProfile completed this presentation.

JakartaEE + IOT

How Internet Of Things can benefit from JavaEE technologies.
Payara Micro [11] is a declination of Glassfish based Payara Server, dedicated to containerized micro-services.
This tiny application server is MicroProfile compatible, but dispite its size (less than 70Mo), supports also clustering, JCA connectors, JCache, EJB Timer and CDI remote events.
How an JavaEE application server can be so light? The answer was by removing support for legacy API not pertinent for this kind of application.
Lightweight and enterprise features, we observe with the demo an application aggregating data from moisture sensors, deployed on RaspberryPi like nano-computer.
CDI Remote Events, JCA connector for asynchronous message exchange (MQTT), REST services are present to demonstrate that JavaEE technologies have their place in the constrained resources world of IOT.

Kubernetes: Return on Experience

The Eclipse Foundation is migrating its Continuous Integration Platform from Cloodbees Jenkins Enterprise to a solution based on Kubernetes cluster (OpenShift).
From his migration experience Mikaël Barbero prensents a excellent introduction to Kubernetes [1].
Kubernetes [15] is an Open Source system for container orchestration. It allows to automate deployment, configuration, management and scaling of containerized micro-services based applications.
Unlike JavaEE platform where the container, i.e. the Java Virtual Machine, is limited to run bytecode, more Kubernetes VM containers, e.g. docker VM, are more generic as they are OS, language, platform independents.
Where JavaEE servers were able to manages the life-cycle of JVM in a cluster, Kubernetes manages approximately the same work with different kind of VM containers like docker container in the presented case.
We oversee how usages evolved in the last past years: Instead of depending on JavaEE application servers capabilities, limited more or less to the Java World, a third party tooling is preferred for managing any kind of systems in VM containers, i.e. in a way similar to cloud computing platforms.

Conclusion

We can read here or there a lot of articles that oppose the pretending monolithic nature of JavaEE to granular micro-service architecture.
However JEE (JavaEE or JakartaEE) does not describe how a compatible execution environment must be implemented but only defines a set of API for which an implementation (whatever it is) must be available and a packaging format. Each JEE component kind is already potentially distributable, so why can’t we consider JEE as a PAASPlatform As A Service on which we could deploy micro-service based application?
Is it because the platform is too difficult to fragment as it was done with the two standard profiles? Is it because of the need for ascending compatibility? Is it because modularization mechanisms was not available yet in the underlying JavaSE?
MicroProfile success (or competitors like SpringBoot or DropWizard) learn us that:

• We should be able to chose the exact set of technologies required by an application component (and provision only these technologies).Dynamic modules systems (e.g. OSGI) used in application servers allow yet to load only required resources, however a domain configuration is always a difficult task we would prefer delegating to non Java tooling.
• Micro-service based or not, Enterprise applications require solutions to make Enterprise specific aspects (like security, transaction, fault tolerance, monitoring, logging, …) easy to implement.We just need to look at MicroProfile Evolution to be convicted of this point. If these new APIs match new usages, they may also benefit to JakartaEE and then a convergence should occurs. Howerver does the MicroProfile is going to stay “micro” if more and more API are integrated?
• Sun/Oracle or Eclipse Foundation standardization strategy allows to federate various vendors efforts and improve portability and interoperability.

Now that JavaEE is going to be free from a specific vendor like Oracle, EclipseCon attendees’ enthusiasm was an evidence.
Thank to container based virtualization systems, able to run various component, java based or not, thank to tools able to manage complex Cloud-like infrastructures, in my opinion, modularity is the future challenge for JakartaEE. It could be defining new profiles as MicroProfile, or more interesting, it could be proposing a completely modularized platform where parts could be chosen à la carte, similarly to what have been done with JavaSE.
Tomorrow deploying a JakartaEE application would consist to automatically discover required API from the packaging and provision strictly necessary to run the application?
Finally, I’d like to thank the whole Eclipse Foundation team who, once again succeeded to organized a fantastic event.
To all speakers: Bravo for the quality and diversity of the presentations.

References