Java EE and Microservices in 2016?

| by Mark Little Follow 14 Followers on Feb 14, 2016. Estimated reading time: 3 minutes |

It's not too far into 2016 to revisit a predication for the year made late last year. Back in December, Steve Millidge from C2B2, made the prediction that 2016 would be the year of Java EE microservices. To a degree this was based on Steve's session at JavaOne, where he spoke about precisely that topic. Plus Steve is co-founder of Payara, which they're also aiming at Java EE developers interested in microservices. Steve is also of the view that there's very little difference between SOA and microservices, something we've heard and reported on before. As he mentions in the video:

"Microservices isn't different from SOA. It's still about SOA".

Now of course there's the argument that due to his background and current focus, Steve may find it hard to be objective. However, as far back as 2014 when microservices were still in their relative infancy, Adam Bien wrote about the perfect Java EE Microservice:

[...] a perfect JavaEE microservice is single [Entity Control Boundary] component within a WAR deployed on a single server/domain. In such a case you could release and redeploy individual components (aka microservices) independently. Direct method invocations between WARs are not possible, so the WARs are forced to use e.g. JAX-RS to communicate with each other.

We interviewed Markus Eisele late last year about Microservices, DevOps and Java EE, where he discussed how he believes Java EE has an important role to play in the evolving microservices landscape. And there are a number of other approaches to writing microservices with Java EE, including TomEE and WildFly-Swarm. One of the Duke's Choice Award winners at JavaOne 2015 was KumuluzEE, a framework for Java EE microservices as co-founder Matjaz Juric explained:

KumuluzEE is the first framework for micro services using standard Java APIs. A microservice architecture focuses on developing applications into services and deploying these independently; a true micro service architecture is not possible in Java EE without a framework that automates deployment and configuration.

It's interesting to examine a few other examples of where people are looking at microservices and Java EE because some are not staying strictly within the realms of traditional Java EE. For instance, back in 2014 Alex Soto discussed how Java EE and RxJava were a great approach. However, not everyone is convinced that using Java EE enables developers to embrace microservices. As Rick Hightower said:

If you are deploying a WAR file to a Java EE container then you are probably not doing microservice development. If you have more than one WAR file in the container or an EAR file, then you are definitely not doing microservice development. If you are deploying your service as an AMI or docker container and your microservice has a main method, then you might be writing a microservice.

And Rick also doesn't believe that microservices are the same as SOA:

In fact, it in many ways it is directly the opposite. For example SOA often embraces WSDL which is a very strongly typed and rigid way to define a service endpoint. WSDL and XML schema takes all of the X out of XML.

Of course we've discussed many times how SOA and Web Services are often unrelated. However, Rick and others do believe that Java EE is simply too bloated or otherwise unwieldy to be the right basis from which to build microservices. Jeppe Cramon believes there are further fundamental aspects of Java EE which make it a poor basis:

If we combine (synchronous) 2 way communication with small / micro-services, modelled according to e.g. the rule 1 class = 1 service, we are actually sent back to the 1990s with Corba and J2EE and distributed objects. Unfortunately, it seems that new generations of developers, who did not experience distributed objects and therefore not take part in the realization of how bad the idea was, is trying to repeat the history. This time only with new technologies, such as HTTP instead of RMI or IIOP.

Now if microservices and SOA are closely related perhaps there's also an argument that microservices can be approached from a technology agnostic manner as some did with SOA. What do you think? Could 2016 be the year of microservices and Java EE? What role, if any, does Java EE have to play in microservices?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Mutually Exclusive by Greg Liebowitz

The only logical explanation for selecting Java EE on a project in 2016 is to protect one's job security. Microservices, as with DevOps, requires forward-thinking management and developers.

Re: Mutually Exclusive by Rafael Chaves

Honest question: what is wrong with implementing a microservice with JAX-RS and JPA (originally introduced in JavaEE)?

If anything, I'd say using an industry standard with abundance of seasoned professionals makes one more easily replaceable than if using many of the fast moving/bleeding edge alternatives.

Re: Mutually Exclusive by Gareth Rowlands

There's nothing so terrible about JAX-RS or JPA per se. But they're not necessarily going to be the most appropriate technology for any given microservice. And they tend to imply the rest of the monolithic JEE stack. I mean, if you're deploying WARs, you're likely deploying to an application server, and there's a good chance that brings a lot of stuff along with it. You really want to avoid hard dependencies on products (such as the app server or even Java). For example, environment variables are typically a better bet for configuration than JNDI. If you are doing Java, you probably want Spring, not JEE.

Re: Mutually Exclusive by Rafael Chaves

Fair enough, thanks for expanding.

I tend to prefer building Java micro-services using JAX-RS and JPA, but then deploy them as standalone Jetty-based apps as a fat-jar (while also packaging the app as a WAR, leaving the door open for container-based deployment in clients/environments that require so).

Re: Mutually Exclusive by Sam Siddiqi

Well, programming to APIs is all you need to do. The whole point about the container is that it hosts your application, and so your application doesn't depend on the container other than providing certain capabilities (e.g. transaction management, dependency injection, Servlets, etc). That's not a direct dependency, and holds true for any application framework.

I've also had no problems with using environment variables in Java EE, JBoss in particular, and felt no compelling need to use JNDI directly, thanks to CDI.

The programmatic aspects of Java EE have matured nicely. Where your millage will vary is on the vendor-specific stories, such as ease of management of clusters, and monitoring. Wildfly's domain mode does a nice job here.

I agree in principle, it may not be the most appropriate choice of tech, but Java EE and the .Net stacks are both general purpose stacks which can probably be adapted to meet your use-cases, and I see this being equally true in the context of a micro-services architectural style.

Use what you know. Switch when something else does the job better. NOT because the cool kids are using it, or because some toy example looks nice in some blog. Organizations invest a lot in these technical choices, from training to infrastructure. It would be a shame to throw it away based on mere perceptions without at least validating if the stack can satisfy the architectural needs and use cases.

Re: Mutually Exclusive by Sean Wiley

I work for Caucho, makers of the Resin Application Server. From our standpoint, we still see a large number of deployments still using the tried and tested technologies of JavaEE / Spring.

One of the biggest hurdles we've seen for developing "MicroServices" is what technologies (JSRs) / framework should be used as a basis. A lot of the principles of MicroServices are rooted in SOA, and eloquently expressed at, but when it goes beyond theory and into implementation, developers are using traditional technology stacks.

Part of this is due to their already existing platform dependency and part is due to the familiarity developers already have for handling topics such as scalability, sessions, transactions, service discovery, etc. Of course, traditional stacks are not without their faults as they are not only monolithic in development, but also leave applications exposed to cache coherency, threading, & numerous integration points & dependencies.

While the Resin Application Server will remain a focus of ours for years to come, I thought it useful to introduce our other completely Open Source reactive framework Baratine as what we see as the true SOA successor. Baratine ( or ( reworks the thread & data model to take a POJO approach where services have no outside dependencies, including the datasource. This allows for minimal code as you can build fully non-blocking REST API services writing straightforward Java 8 code, but also opens the potential to having completely self-contained services that do not need synchronization blocks for backend concurrent data access (huge performance/usability boost).

Baratine can be embedded in JavaEE frameworks or used standalone, for a better understanding I suggest looking at our "Exposing Lucene library as a MicroService with Baratine" paper on this site, or looking at the Auction MicroService under our github.

With MicroServices, developers are looking to leverage what they already know & have installed in this new-age IoT, polyglot, self-contained, & reactive world of web services. However, if tools such as JAX-RS / JPA are required for development, you'll ultimately be left with the same types of applications ( & problems ) you were building before "MicroServices" became a buzzword, just on a smaller scale.

JavaEE and Microservices by Richard Hightower

I am not anti-Java EE. Everything has a context. Technology changes, opinions change, and things move in different directions. I should probably qualify some of those statements about Java EE based on my current experience. I lean towards Kafka, Vert.x, Reakt, QBit, and Akka. I have seen some really well-done microservices using JAX-RS async and more of a Java EE stack but still did not use war or ear files per se. I am okay with SOA the concept. SOA the movement and where people took it was a bit looney, but I could probably soften some statements around that too. I have even softened on my stance about WSDL after implementing Swagger support for QBit (by request and paid for by a company), working with the Amazon API gateway (which supports swagger), and also working with Avro Schema and the Kafka Schema Registry. I still feel if you are not doing async then you can't really benefit from microservices. I also think stacks like Vert.x,, QBit and Akka support this model better than Java EE. But Java EE is pervasive and you can certainly develop microservices with it. At one point QBit could run on top of Vert.x or the Servlet API. The statements were more about legacy Java EE not what could be done, but what is usually done.

Re: Mutually Exclusive by Richard Hightower

I agree. I am a big fan of Caucho and
Great tech. Great engineering and a great company.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you