BT
x Share your thoughts on trends and content!

Java EE and Microservices in 2016?

by on Feb 14, 2016 |

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

Relevance
Style

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 www.reactivemanifesto.org, 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 (baratine.io) or (github.com/baratine) 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.

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

6 Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.