Microservices and Java EE

Microservices based architectures are everywhere these days. We learn so much about how today’s innovators, like Netflix and Amazon use these to be even more successful in generating more business. But what about all of us, who are using Java EE application servers and write classical systems? Are we all doing it wrong? And how could we make our technical designs fit for the future?

Monoliths
First of all, let’s look into those classical systems. Or called monolithic applications. Even if the word has a bad smell these days, this is the way we built software for a very long time. It basically describes the fact, that we build individual applications to fulfill a certain functionality.
And monolithic does refer to exactly what Java EE or better the initial Java 2 Enterprise Edition was designed for. Centralized applications which could be scaled and clustered but not necessary build to be resilient by design. They relied on infrastructure and operations in failure scenarios most of the time.

Traditionally, Java EE applications followed some core patterns and were separated into three main layers: presentation, business, and integration. The presentation layer was packaged in Web Application Archives (WARs) while business and integration logic went into separate Java Archives (JARs). Bundled together as one deployment unit, a so-called Enterprise Archive (EAR) was created. The technology and best practices around Java EE have always been sufficient to build a well-designed monolith application. But most enterprise-grade projects tend to lose a close focus on architecture.  This is why sometimes a well designed spaghetti ball was the best way to visualize the project dependencies and internal structures. And when this happened, we’ve quickly experienced some significant drawbacks. Because everything was too coupled and integrated even making small changes required a lot of work (or sometimes major refactorings) and before putting the reworked parts into production, the applications also had to be tested with great care and from beginning to end.
The whole application was a lot more than just programmed artifacts: it also consisted of uncountable deployment descriptors and server configuration files, in addition to properties for relevant third-party environments.

The high risks in changes and the complexity of bringing new configurations into productions lead to less and less releases. A new release saw the light of day once or twice a year. Even the team structures were heavily influenced by these monolithic software architectures. The multi-month test cycle might have been the most visible proof. But besides that, projects with lifespans longer than five years tended to have huge bugs and feature databases. And if this wasn’t hard enough, the testing was barely qualified–no acceptance tests, and hardly any written business requirements or identifiable domains in design and usability.

Handling these kinds of enterprise projects was a multiple team effort and required a lot of people to oversee the entire project. From a software design perspective, the resulting applications had a very technical layering. Business components or domains were mostly driven by existing database designs or dated business object definitions. Our industry had to learn those lessons and we managed not only to keep these enterprise monoliths under control, but also invented new paradigms and methodologies to manage them even better.

spaghettiSo, even if the word „monolith“ is considered synonym for a badly designed piece of software today, those architectures had a number of benefits. Monolithic applications are simple to develop since IDEs and other development tools are oriented around developing a single application. Its a single archive that can be shared with different teams and encapsulates all the functionality in there. Plus, the industry standard around Java EE gave enterprises solid access to the resources needed to not only build but also operate those applications. Software vendors have build a solid knowledge base around Java EE and sourcing isn’t a big issue in general. And having worked with them since more than 15 years by now, the industry is finally able to manufacture these applications in a more or less productized and standardized way. We know which build tools to use, which processes scale in large teams and how to scale those applications. And even integration testing got a lot easier since tool like Arquillian emerged. We still are paying a price for the convenience of a mature solution like Java EE. Code-bases can grow very large. When applications stay in business for longer, they get more and more complex and harder to understand for the development teams. And even if we know how to configure application servers, the one or two special settings in each project still cause major headaches in operations.

Microservices
microservicesBut our industry doesn’t stand still. And the next evolution of system architecture and design just saw the light of day a couple of years ago. With the growing complexity of centralized integration components and the additional overhead in the connected applications the search for something more lightweight and more resilient began. And the whole theory finally shifted away from big and heavyweight infrastructures and designs. Alongside with this IT departments started to revisit application servers alongside with wordy protocols and interface technologies.

The technical design went back to more handy artifacts and services with the proven impracticality of most of the service implementation in SOA- and ESB-based projects. Instead of intelligent routing and transformations, microservices use simple routes and encapsulate logic in the endpoint itself. And even if the name implies a defined size, there isn’t one.  Microservices are about having a single business purpose. And even more vexing for enterprise settings, the most effective runtime for microservices isn’t necessarily a full-blown application server. It might just be a servlet engine or that the JVM is already sufficient as an execution environment. With the growing runtime variations and the broader variety of programming language choices, this development turned into yet another operations nightmare. And even developers today are a little lost when it comes to defining microservices and how to apply this design to existing applications.

Microservices are designed to be small, stateless, in(ter)dependent & fully contained applications. Ideally able to deploy them everywhere, because the deployment contains all the needed parts.

Microservices are designed to be small.  But defining “small” is subjective.  Some of the estimation techniques like lines of code, function points, use cases may be used.  But generally “small” isn’t about size.
In the book Building Microservices the author Sam Newman suggests a few techniques to define the size of microservice, they are:

  • small enough to be owned by a small agile development team,
  • re-writable within one or two agile sprints ( typically two to four weeks) or
  • the complexity does not require to further divide the service up

A stateless application handles every request with the information contained only within it. Microservices must be stateless and it must service the request without remembering the previous communications from the external system.

Microservices must service the request independently, it may collaborate with other microservices within the eco-system.  For example, a microservice that generates a unique report after interacting with other microservices is an interdependent system. In this scenario, other microservices which only provide the necessary data to reporting microservices may be independent services. A full stack application is individually deploy-able. It has its own server, network & hosting environment.  The business logic, data model and the service interface (API / UI) must be part of the entire system.  A Microservice must be a full stack application.

Why now? And why me?
“I’ve been going through enough already and the next Java EE version is already under development. We’re not even using latest Java EE 7. There are so many productivity features coming: I don’t care if I build a monolith if it just does the job and we can handle it.” And I do understand these thoughts. I like Java EE as much as you probably do and I was really intrigued to find out why microservices evolved lately. The answer to those two questions might not be a simple one: But lets try:

Looking at all the problems in our industry and the still very high amount of projects failing, it is perfectly fine to understand the need to grow and eliminate problems. A big part of new hypes and revamped methodologies is the human will to grow.

And instead of “never touch a running system” our industry usually want’s to do something better than the last time.
So, to answer the second part of the question first: “You probably want to look into this, because not doing anything isn’t a solution.”

As a developer, architect or QA engineer we basically all signed up for live long learning. And I can only speak for myself at this point, but this is a very big part of why I like this job so much. The first part of the question isn’t so easy to answer.

Innovation and constant improvement are the drivers behind enterprises and enterprise-grade projects. Without innovation, there will be outdated and expensive infrastructure components (e.g., host systems) that are kept alive way longer than the software they are running was designed for. Without constant validation of the status quo, there will be implicit or explicit vendor lock-in. Aging middleware runs into extended support and only a few suppliers will still be able to provide know-how to develop for it. Platform stacks that stay behind the latest standards attempt to introduce quick and dirty solutions that ultimately produce technical debt. The most prominent and quickest moving projects in the microservices space are Open Source projects. Netflix OSS, Spring, Camel, Fabric8 and others are prominent examples. And it became a lot easier to operate polyglot full-stack applications with today’s PaaS offerings which are also backed by Open Source projects like Docker and Kubernetes. In our fast paced world the lead times for legally induced software changes or simple bug fixes are shrinking. Very few enterprises still have the luxury to work with month long production cycles and the need for software to generate real value for business emerges even more. And this is not only true for completely software driven companies like Uber, NetFlix, Amazon and others.

We need to build systems for flexibility and resiliency, not just efficiency and robustness.  And we need to start building them today with what we have.

And I really want to make sure you’re reading this statement the right way: I am not saying, that everything from today on is a microservice.

  • But we should be aware of the areas where they can help and be able to
  • change existing applications towards the new approach when it makes sense.
  • and we want to be able to be a good consultant for those asking about the topic

And Java EE isn’t going anywhere soon. It will be complemented and the polyglot world will be moving in in various places, but we’re not going to get rid of it soon.  And this is the good news.

Learn more about how to evolve your Java EE applications into microservices by downloading my free eBook from developers.redhat.com. Make sure to re-watch my O’Reilly Webcast about “Java EE Microservices Architecture”  and also follow my blog.eisele.net with some more technical information about WildFly Swarm, Docker and Kubernetes with OpenShift.

Lightweight Integration with Java EE and Camel

Enterprise Java has different flavors and perspectives. Starting at the plain platform technology, which is well known as Java EE over to different frameworks and integration aspects and finally use-cases which involve data-centric user interfaces or specific visualizations. The most prominent problem which isn’t solved by Java EE itself is “integration”. There are plenty of products out there from well know vendors which solve all kinds of integration problems and promise to deliver complete solutions. As a developer, all you need from time to time is a solution that just works. This is the ultimate “Getting Started Resource” for Java EE developers when it comes to system integration.

A Bit Of Integration Theory
Integration challenges are nothing new. Since there has been different kinds of system and the need to combine their data into another one, this has been a central topic. Gregor Hohpe and Bobby Woolf started to collect a set of basic patterns they used to solve their customers integration problems with. These Enterprise Integration Patterns (EIPs) can be considered the bible of integration. It tries to find a common vocabulary and body of knowledge around asynchronous messaging architectures by defining 65 integration pattern. Forrester calls those “The core language of EAI”.

What Is Apache Camel?
Apache Camel offers you the interfaces for the EIPs, the base objects, commonly needed implementations, debugging tools, a configuration system, and many other helpers which will save you a ton of time when you want to implement your solution to follow the EIPs. It’s a complete production-ready framework. But it does not stop at those initially defined 65 patterns. It extends those with over 150 ready-to-use components which solve different problems around endpoints or system or technology integration. At a high level Camel consists of a CamelContext which contains a collection of Component instances. A Component is essentially a factory of Endpoint instances. You can explicitly configure Component instances in Java code or an IoC container like Spring, Guice or CDI, or they can be auto-discovered using URIs.

Why Should A Java EE Developer Care?
Enterprise projects require us to do so. Dealing with all sorts of system integrations always has been a challenging topic. You can either chose the complex road by using messaging systems and wiring them into your application and implement everything yourself or go the heavyweight road by using different products. I have been a fan of more pragmatic solutions since ever. And this is what Camel actually is: Comparably lightweight, easy to bootstrap and coming with a huge amount of pre-built integration components which let the developer focus on solving the business requirement behind it. Without having to learn new APIs or tooling. Camel comes with either a Java-based Fluent API, Spring or Blueprint XML Configuration files, and even a Scala DSL. So no matter which base you start to jump off from, you’ll always find something that you already know.

How To Get Started?
Did I got you? Want to give it a try? That’s easy, too. You have different ways according to the frameworks and platform you use. Looking back at the post title, this is going to focus on Java EE.
So, first thing you can do is just bootstrap Camel yourself. All you need is the core camel dependency and the cdi-camel dependency. Setting up a plain Java EE 7 maven project and adding those two is more than sufficient.

<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
<version>${camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-cdi</artifactId>
<version>${camel.version}</version>
</dependency>

Next thing you need to do is find a place to inject your first CamelContext.


@Inject
CdiCamelContext context;

After everything is injected, you can start adding routes to it. A more complete example can be found in my CamelEE7 project on GitHub. Just fork it an go ahead. This one will work on a random Java EE application server. If you are on WildFly already, you can also take full advantage of the WildFly-Camel subsystem.

The WildFly Camel Subsystem
The strategy of wildfly-camel is, that a user can “just use” the camel core/component APIs in deployments that WildFly supports already. In other words, Camel should “just work” in standard Java EE deployments. The binaries are be provided by the platform. The deployment should not need to worry about module/wiring details.
Defining and Deploying Camel Contexts can be done in different ways. You either can directly define a Context in your standalone-camel.xml server configuration or deploy it as part of your web-app either as a single XML file with a predefined -camel-context.xml file suffix or as part of another WildFly supported deployment as META-INF/jboss-camel-context.xml file.
The WildFly Camel test suite uses the WildFly Arquillian managed container. This can connect to an already running WildFly instance or alternatively start up a standalone server instance when needed. A number of test enrichers have been implemented that allow you have these WildFly Camel specific types injected into your Arquillian test cases; you can inject a CamelContextFactory or a CamelContextRegistry as an  @ArquillianResource.
If you want to get started with that you can take a more detailed look at my more detailed blog-post.

Finding Examples

If you are excited and got everything up and running it is time to dig into some examples. First place to look at is the example directory in the distribution. There is an example for everything that you might need.
One of the most important use-cases is the tight integration with ActiveMQ. And assuming that you have something like a bunch of JMS messages that need to be converted into Files that are stored in a filesystem: This is a perfect Camel job. You need to configure the ActiveMQ component additional to what you’ve seen above and it allows messages to be sent to a JMS Queue or Topic or messages to be consumed from a JMS Queue or Topic using Apache ActiveMQ.
Teh following code shows you what it takes to convert a JMS messages from the test.queue queue into the file component which consumes them and stores them to disk.


context.addRoutes(new RouteBuilder() {
public void configure() {
from("test-jms:queue:test.queue").to("file://test");
}
});

Imagine to do this yourself. Want more sophisticated examples? With Twitter integration? Or different other technologies? There are plenty of examples out there to pick from. Probably one of the most exciting aspects of Camel. It is lightweight, stable and out there since years. Make sure to also follow the mailing-lists and the discussion forums.

This post is part of the Java Advent Calendar and is licensed under the Creative Commons 3.0 Attribution license. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on!

Project Avatar – The next Java EE Feature?

It is this time of the year again. Christmas holidays are approaching fast and the Java Advent Calender is filling up constantly. Today it’s on me to write my surprise post. I’m Markus, also known as @myfear and I’ve been working with and around Java EE and a bunch of related servers since many years. Beside the daily work I started more actively contributing to the Java EE Expert Group with the Java EE 7 release. With EE 7 out the door since a while it is already time to start planning for the next revision of the platform which will most likely be called Java EE 8. Oracle set up a community survey with which they would like to get input from the community on the relative importance of some of the features they intend to add. First of all this should encourage the interested reader to participate and take the survey. One particular point in it is all about support for HTML 5 based, dynamic applications. While WebSocket and JSON Processing already made it into Java EE 7 there is another feature particularly in GlassFish and WebLogic (via Jersey) at the moment which has some potential to be standardized. The Server Sent Events (SSE). It already is part of the HTML5 spec and would be a very good candidate for standardization. But Oracle is thinking even further and is asking if there would be enough support and interest to actually standardize the use of JavaScript on  Java EE servers. When this kind of question started to appear at JavaOne 2012 it was basically referred to as Node.jar on Nashorn. Since this September we know the real name: Project Avatar.

Avatar At A Glance
Project Avatar provides a JavaScript services layer zeroed in on supporting REST, WebSockets and Server-Sent Events, and a rich client side framework that assumes very minor JavaScript knowledge. The services side is focused on building data services using JavaScript, while the optional client side is entirely focused on supporting HTML5 and TSA (Thin Server Architecture).

Project Avatar (Source: avatar.java.net)

Thin Server Architecture
With the introduction of HTML5, CSS3 and fast JavaScript engines, modern browsers have become a powerful platform. In the advent of the so called single-page application (SPA), also known as single-page interface (SPI) the design of modern user interfaces shifted away from server side generation to web applications or web sites that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application. An SPA moves logic from the server to the client. This results in the role of the web server evolving into a pure data API or web service. This architectural approach has been coined “Thin Server Architecture” to indicate that complexity moved from the server to the client while reducing overall system complexity.

What is really in Avatar?
But Avatar is far more than just a TSA approach. It basically consists of three parts. The foundation is build by the upcoming Java 8 and it’s included JavaScript implementation called Nashorn. On top of it is the Avatar Runtime including an additional compiler layer and a Servlet API based server. Those abstractions  enable it to be hosted on various runtimes. Avatar applications are comprised of either client side ‘views’, server side ‘services’ or both. Importantly, there is no inherent coupling between them which enables views to communicate with existing services and for services to be consumed by any type of client. An application ‘archive’ is deployed on the server and is compiled to generate JavaScript tailored to the application. Generated JavaScript for views handles data-binding with the DOM/UI as well as data-management to remote services and local storage. The Avatar archives are somewhat similar to Java EE web-archives. They consist of a WEB-INF folder, an avatar.properties file in the root and either a views directory and/or a service directory. Both file-system directories or .zip (.war) files are supported by Avatar.

All that is left on the Server – Services
An service extends either a REST, WebSocket or Push (SSE) abstraction and it’s life-cycle is completely handled by the framework. Service implementations can leverage built-in Node modules as well as most third-party modules. Thanks to Nashorn’s support for direct invocation of Java code you can also use most Java libraries directly.

The Client Side – Views
A view is the HTML required by the browser. It also contains custom ‘data-‘ HTML extensions and simple JavaScript models. Those views get translated by a (server-side) compiler before sending the complete SPA HTML file including the custom generated JavaScript to the browser.

Putting it all together. A Simple Example.
Oracle provides a decent set of examples and documentation for Avatar which basically is enough to get you started. First thing to try it out yourself is a JDK 8 Early Access Build for your OS. At the time of writing I tried it with the latest Developer Preview b118. After installing you need to get the latest GlassFish Open Source Edition 4.0 server and unzip it into a suitable location. Make sure it runs with the installed JDK 8 by either putting <jdk8>/bin to your PATH environment variable or adding the following entry to the <gf4>/glassfish/config asenv.bat/conf

set AS_JAVA=<jdk8>

No go ahead to download latest avatar-1.0-ea.zip and expand it to the <gf4>/glassfish/ directory. After that you need to set a AVATAR_HOME environment variable and point it to the <gf4> install directory. And make sure to add %AVATAR_HOME%glassfishbin to your PATH environment variable.
If all of that is done you can switch to your workspace folder and issue the following command to have Avatar creating a simple example app for you:

avatar new --example=hello

It creates a basic “hello” application which only consists of a view. It is a good place to start exploring and you can directly start your Glassfish instance afterwards and deploy the application as you would with every typical Java EE application:


asadmin start-domain


asadmin deploy hello

The “hello-example” app.

Pointing your browser to http://localhost:8080/hello will display the application. You can start editing the view located at <workspace>/hello/view/src/hello.html directly. While the server is running Avatar takes care of re-compiling it directly for the next request. This ensures a rapid development. This behavior is controlled by the “debug=true” property in the avatar.properties file and can be altered for productive systems. Further on, setting it to false causes all .js and .css files to be minimized before delivery.
At least if you first download and add the required YUI Compressor (jar download) to Avatar first. Due to license restrictions it hasn’t been bundled. Simply put it into <gf4>/glassfish/modules/avatar-ext/lib. You might need to create that directory first.

Beside this very simple example without any service at all there are more complex ones available with the distribution at %AVATAR_HOME%/Project-Avatar-examples/. For convenience reasons there is a complete examples.ear available which can be directly deployed and tested. To access the samples simply prefix the example name with “demo-“. So the “rest” example can be accessed via http://localhost:8080/demo-rest/.

TodoMVC – Example App with Avatar

You have to look out for different features to be showcased in the different examples. If you want to know how Avatar handles persistence you can exactly look into the rest example which uses a FileDataProvider to save the items. Another interesting example is the TodoMVC based app (http://localhost:8080/demo-todo/). It showcases a more complex view which also has been styled.

What is next?
As of today nobody knows what is going to happen with Avatar. The community feedback hasn’t been tremendously loud or excited in general. I guess the reason for it is that nobody really knows what to do with it. The biggest drawback as of today is, that it only runs with GlassFish which will further limit adoption and community interest. Given the fact, that SSE isn’t part of the Java EE specification it might make it even more difficult to port it to other app-server. Even if the license (GPL2 with Classpath Exception) should allow it. Back to the initial survey and the thought about specifying a server side JavaScript integration with Java EE, you know at least have a brief idea about what Oracle is talking if they are talking about Avatar. Go ahead and take that survey and tell them what you are thinking about having that kind of stuff in Java EE.

I wish you a happy holiday season and a new year filled with peace and prosperity.

Meta: this post is part of the Java Advent Calendar and is licensed under the Creative Commons 3.0 Attribution license. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on!