yoshitaka272 - Fotolia
How Java EE development has kept up with microservices
Java EE is mature technology, but it will continue to evolve in ways that can fit nicely into a microservices architecture.
The Java programming language is mature technology but one that continues to grow and evolve. Now, with the rise of microservices, there are questions as to whether or not Java EE development can keep pace with modern demands.
Robert Roeser, CEO and co-founder at Netifi, said Java, in its current form, cannot meet the needs of a microservices architecture. For this reason, companies like Netflix and others that rely on microservices must fill in the gaps where Java is lacking. This need gave rise to developments such as the Spring framework, which delivers some advances, albeit nothing cloud-native. The Cloud Native Compute Foundation is a prime example of a group that took action and made strides toward a more modern and accessible cloud-native universe.
Roeser, who was a pioneer at Netflix when it moved to a cloud-based microservices architecture, said microservices represent a sea change compared with traditional monolithic app development. The challenge it presents, however, is how to connect everything from the data center to the client. That assembly is especially tough if it's unclear whether the client faces toward the web, a phone or a bot, he said.
Java EE isn't out for the count
But not everyone takes as harsh a view of Java as Roeser. Mark Little, vice president of engineering and CTO of JBoss middleware at Red Hat, said it's wrong to think that, since Java EE development predates microservices and service-oriented architecture, it is not suitable for microservices at all.
This misconception comes from an inability to differentiate between Java EE as a set of standards and Java EE as a set of implementations, Little said. "The specifications that form the standard have been developed to be modular, allowing for many different implementations," he said.
This is exemplified by the Java Persistence API found within Java EE and modern implementations, like Hibernate and EclipseLink, Little said. To claim full Java EE compliance, Little added that you need to add all of these specifications.
While that approach sometimes results in so-called monolithic implementations, it does not have to. Some frameworks and stacks that are popular for microservices projects cannot claim Java EE compliance, Little said. They can, however, use various specification implementations within themselves. "For example, Hibernate is not just used within WildFly and EAP [Enterprise Application Platform]," he said.
In 20 years, Java EE development has gone through several iterations and added many features. For instance, open source projects, like Hibernate and Spring, were designed to sit on top of Java EE and address initial shortcomings with specifications, particularly in the of persistence.
"Java EE grew to include functionality from these projects to maintain its appeal to developers," said Simon Ritter, deputy CTO of Azul Systems, a Sunnyvale, Calif.-based company that develops runtime platforms for executing Java-based applications. "Likewise, when web services became a popular technology, Java EE was expanded to include this."
Enterprise application development teams are still in the early stages of microservices architecture adoption. However, the Java EE specifications did not provide support in time, Ritter said. As a result, the Eclipse Foundation developed the MicroProfile specification outside the Java Community Process.
Fortunately, Oracle also donated Java EE specifications, reference implementations and Technology Compatibility Kits to Eclipse so that it could develop these specs at a pace that catered to developer needs, Ritter said. "Due to copyright issues, it was not possible to continue to call the set of specifications Java EE, which is why we now have Jakarta EE," he said.
Java examples in microservices architecture
A well-designed microservices architecture allows for a wide range of implementations, said Randy Heffner, analyst at Forrester Research in Cambridge, Mass. As such, there are multiple places where Java might show up, such as in a blended architecture.
Most major enterprises must slowly build a microservices architecture over time, and teams can't always create everything from scratch. As such, new functions built with a pure microservices design often must be combined with legacy functions that use APIs to blend naturally into a microservices-based application, Heffner said.
Developers might also need to extract important subsystems or components from legacy Java apps, Heffner said. However, this subsystem might still require most of the Java EE infrastructure and may not yet be a candidate for new forms of Java-based deployment. "Nonetheless, containerizing the subsystem surfaces important aspects of microservices benefit," he said.
Java SE does provide a promising approach, however. "Along the road to Java EE, many developers eschewed the larger EE framework and wrote their code with the thinner Java SE," Heffner said. "Such code may be converted into microservices in a lighter way."
Ritter sees Jakarta EE as the most common Java use case in microservices. "Given the Eclipse Foundation's close links with the wider Java community, I would expect to see Jakarta EE continue to develop to address the needs of enterprise developers looking to use a microservices architecture for application development," he said.
