Emerging Trend Of Java EE Microservices
The way we design our application has evolved from monolithic to microservices.
Source: http://martinfowler.com/articles/microservices/images/decentralised-data.jpg
With microservices, we have landed into the next phase of evolution phase of system architecture and web design. IT space is growing to be more complex as developers are striving to render excellent robust functionality while not compromising with the design of the solutions. With the advent of numerous smart devices, they are focusing on rendering centralized solutions. To render an unfettered solution, you need resilient as well as a lightweight solution that can endure the burden of the integrated system. This was when Java EE microservices entered.
What are Java EE microservices?
The current mobile and multipurpose requirement has changed our focus from heavyweight designs and infrastructures to the one that is supple designs. Now the wordy protocols and web interface design technologies are no revised from the application servers.
Microservices make use of simple routes and encase the logic to itself rather than using intelligent routing. There is no defined size even if the name indicates to one.
Microservices works as a platform for a singular business purpose. Microservices do not make use of full-fledged application server for effective runtime, even you need to push it harder to get comprehensive enterprise settings. A single microservice can be deployed as a single servlet or a JVM instance which can serve as the best environment for executing complex enterprise functionality.
Why microservices is an up and coming trend?
Microservices offer high scalability. One of the best things about microservices is that cloud instances are independent. Therefore, cloud platform and technology can be utilized to deploy them. You can take advantage of scalability of the cloud platform.
Singular, Robust and Supple - the best part about Microservices architecture is that it contains single business functionality, which means that even if one microservice fails, that service itself goes down and not the whole application.
If the monitoring service is utilized correctly, you can find it out very quickly and restart such microservice or have mechanism which would pass another microservices instance providing the desired functionality.
Furthermore, it's good practice to utilize a load balancing and scalability so that in case of heavy load it can be distributed to unused or new microservice instances.
Easy and swift Deploy
It works on the agile development methodology, which means you do not have to go through all the cumbersome pre-development procedures to incorporate new feature/functionality.
Easy and quick development
As we know that Microservice application is focused on one singular part of business, therefore it is easier to provide such service which encapsulates that requested logic. In case of development of this single logic, you don't have to deploy the whole monolithic application to see if the service is running as expected. All you need to do is to develop and deploy single functionality and write and run (unit) tests against it to make sure everything works, and interface it provides returns the desired results.
Now that we know that Java EE microservices are trend in way of development, we will now discuss its architecture.
The basic architecture of Java EE microservices
Source: http://blog.sysfore.com/wp-content/uploads/2016/01/Microservices-Architecture.jpg
As we know that microservices are the evolved version of monolith architecture Therefore in this section, we need to look at the difference between the monolithic application architecture and how could refactored microservice codebase look like. The architecture comprises of the following components for designing an eCommerce website:
There is a EAR file where the application is decomposed i.e. the components such as User, Catalog, and Order can be stored in separate EAR files. Depends on the granularity which is required. Each EAR file needs to have relevant classes, and configuration files that are needed for such service.
With Microservices we make use of Java EE, however, you do not need to make a commitment for a development platform on a long term to the components of a stack. This is because there is a well-defined API, which different components talk to among themselves. So basically if you keep providing that API, you can easily change the technology which is behind it and no-one could realize it.
Microservices offers easy steps to write the code and maintenance as all multiple classes belong to the same domain.
A good practice is, that there is no sharing of a database allowed here, and thus, all the archives have their own database instance. Wherefore, this has allowed each of the microservice to evolve and choose any specific data store of their choice such as NoSQL, in-memory, relational, flat file, or anything which you might find appropriate.
Microservices Service Registry
To register every component, you need a Service Registry. This is needed as there might be multiple instances of each service functioning at a given instance, and one needs to know their specific endpoint location, and this can be done only at runtime.
Several websites such as Netflix has efficiently incorporated this functionality. There are pre-defined API using which the components communicate with each other. Now communication is further divided into two components, synchronous and asynchronous. REST API are for synchronous, wherein for asynchronous there is Pub/Sub. In eCommerce, an Order component find outs the Catalog and User service and the communication between then happen using REST API.
This was one part of the functionality; wherein the clients interaction is kept in other application. In the case of eCommerce websites, it can be the Shopping Cart related actions that are kept in other application. To be able services talk one to another, Service Registries are used.
Java EE vs. SOA (Service oriented architecture)
SOA is used to reuse and expose business services at an enterprise level. Wherein, Microservice architecture is used to get a strong hold of an individual application rather than controlling the complete enterprise.
Source: http://i.stack.imgur.com/thqNG.jpg
Microservices are just a subset of SOA principles. SOA is Enterprise while microservices are just project level.
What makes Java EE microservice an advanced version monolithic architecture
Monolithic Java EE application is a single application that comprises of several EARs that communicate with each other inside one JVM.
This methodology is widely used by developers today. These applications have a yearly or a half yearly release cycle depending on the type of the environment of the application server, and you need to note monolithic application down the fact that there is a single database to store the data.
For those who have the limitations of not starting a fresh project, or they do not wish to simmer it to a smaller size, and then they can hop on to the modern architecture, where your main application is there at the application server, and this is integrated using REST API.
For those who have no such limitations can break down the functionality into smaller pieces and deploy then as individual services. For that you can consider the following points:
- Domain driven designs
- Failure resistance
- Automation of operations
- Bounded contexts
- Independence of deployments
Now there are several ways in which you can communicate with your microservices, for instance, we have aggregator or the chain method. Nowadays we have several application servers such as Vert.X, Wildfly Swarm, and others that are lightweight and provide quite an incredible environment for deploying your microservices.
Migrating from monolithic to microservices
We know that a monolith there exist multiple bounds exists but resources such as database schema and domain objects are shared. This is the reason a dependency is created between all the parts; this dependency is the reason when one is changed others also get affected due to the ripple effect. This is the reason that everything needs to build and deployed together.
So while moving from monolithic to microservices you need to break this bond and make these components distinct.
A complete rewrite is one way in which you can migrate from a monolith to a microservices architecture. This is also something that moves from the agile to a waterfall world as the replacement must be functionally complete. Which means that you cannot ship the complete project if it does not exactly matches to the already existing system.
This might have serious repercussion on your business; thus, you can take out the important features of your business or can say those that can portray a distinguished image in the market or are critical to your market image.
Thus, changing the complete project you can start with these features. You can then start replacing the code one by one rather than bounding the functionality altogether with the new code, and you can carry on the replacement until the complete code is refactored. Doing so will take you to one point where all your code will be replaced by the new one. This is quite a beneficial approach as it is based on agile and has no risk attached to it that causes unnecessary deadline delays and cost overruns.
Scaling you application
We already mentioned breaking down the monolithic approach into more manageable components. Another important issue in IT deployment is scaling of microservices.
Microservice is an architecture that uses Y-axis scaling, but here we have incorporated X-axis and Z-axis scaling as well to get the complete grasp of scaling.
Source: http://akfpartners.com/techblog/wp-content/uploads/2008/05/db_cube.jpg
X-axis scaling
X-axis scaling aims at running multiple copies of an application which is primarily different functionalities of an app that run at the rear end of the load balancer. So, if you have n copies of the application, then the scaling fragments it to handle 1/N of the load. This is quite a coming approach for scaling your application.
Y-axis scaling
Y-axis scaling aims at splitting an application into different services which is completely a different approach than X-axis and Z-axis scaling approaches as they aim to make identical copies of an app.
Z-axis scaling
As discussed earlier Z-axis scaling also uses the identical copy method for the scaling and this is what makes it similar to x-axis scaling. However, the difference it that the server is keeps the track only of the subset of the data.
Functional decomposition in scaling
Y-axis scaling which is called the third dimension of scaling is called the functional decomposition for scaling your application. In this process, a monolithic application decomposed into a small set of services.
These fragmented solutions are related interconnected to each other as they are related to each others task. In order to convert the application into services, there are several different approaches. One of them is decomposed it by a verb and then get to know services that use one use case.
Another approach is to decompose it using the noun, and this can be used to create an application that pertains to any specific entity. If you have a complex application, then you can make a hybrid combination of verb and noun based combination to carry on your decomposition process.
Bottleneck And How To Face Them
How to efficiently deal with distributed transactions apparently is the biggest challenges. However, there are some challenges that are present in Microservice architecture that you need to check before delving into it.
Operational overhead
This comes with an overhead for your operational team as rather than building a single monolithic app you need to render your resources to:
- Develop multiple microservices
- Monitor several microservices.
- Get hardware for several services.
It takes more effort to deploy several applications. Now as every problem has some or the other solution, likewise to solve this, we have tools such as uDeploy, Jenkins, Chief, Capistrano, Puppet or custom scripts that can automate the cumbersome process of deploying microservices. This is also known as one button deployment.
Alerts of the issues while integrating microservices To overcome this, we have synthetic monitoring. This alerts you whenever any micro service went down, or services stopped communicating.
Challenge of finding a bug
Finding out the error from the mammoth log files of microservices. You want to find out the bug, but the big files present in front of you becomes quite a pain. To solve this issue, you can make use of log aggregation using open source tools such as Kibana and Logstash that can make it easier for an operational team who do not use a similar solution. There are also tools such as ELK stack and Graylog2 that are used to evaluate them.
Source: https://www.elastic.co/assets/bltad8aa4eaa6a65ab9/Screen-Shot-2014-02-25-at-4.42.52-PM-1024x557.jpg
Development Resources overload
Monolithic architecture can be quite challenging to the developers in case of very big projects. To be able to run the application, you overload you application containers and IDE. This can be an obstacle to frequent deployments and scaling development. Along with that, the modules have conflicting scaling requirements, and you need to render a long term commitment to a technology stack.
Transactions
How transactions can be propagated as events Microservices make use of events to carry on this cumbersome task efficiently. Microservices push events when the state changes and they also subscribe to events. Synchronize replicated data and maintains eventual consistency across multiple aggregates. To maintain consistency, a service is required to automatically publish an event whenever a change is a domain object is encountered.
CQRS stands for Command Query Responsibility Segregation.
"CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation: a command is any method that mutates state and a query is any method that returns a value)."
—Greg Young, CQRS, Task Based UIs, Event Sourcing agh!
CQRS is a pattern how Commands get aggregated on the command side, and events are formed which are then stored at the Event Store and reach the Query side to get combined with queries to render a view.
Source: https://lh3.googleusercontent.com/S7v4kuH3Cd9pMa4d0qXoqVDzFAqSR50prgUL4htIa6COYiiFhikqepaa_rhwuAbLXA5hlA=s110
There are numerous benefits of event sourcing, and the major one is that it solves the data consistency issue in a Microservice architecture. It allows you to save atomically and publish your events. It allows the event subscribers to materialize views in SQL and NoSQL databases. It further ensures eventual consistency to the event subscribers. Along with that, it eliminates the problem of O/R mapping.
Testing of Microservices architecture
How to test microservices-based on Java EE ? Testing microservices can be a challenging task as you need to test individual service and also the how they work together (integration testing). Following are the testing process that you need to adopt to test you Java EE microservices:
Testing microservices can be fragmented into the following principles:
Unit: As its name suggest a unit test if the smallest piece of testable software in an application to check whether this behaves as it was discussed.
Integration: An Integration test cross checks whether the interaction between the elements is working with the design interfaces or not.
Component: The main purpose of a component test is to find out the scope of the software to a part of the system that is under test and test the system through code interfaces. This can also be done by isolating the code from the components that surround you.
Microservices discovery service
Microservices discovery using Apache Zookeeper ZooKeeper is a project from Apache, it is a distributed and a consistent store comprising of hierarchical configuration.
Source: http://softwareengineeringdaily.com/wp-content/uploads/2015/08/Zookeper_apache.jpg
“ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications.” ~Apache ZooKeeper
If you are a service provider, you can register yourself with ZooKeeper using a logical name and all the requisite configuration that holds URI endpoint. It comprises of other details such as QoS.
Monitoring
Monitoring Java EE microservices Java based systems allow you to utilize standard monitoring, and that is JMX (Java Management Extension). JMX robust and a well know tool for monitoring Java EE microservices. It comes with an API to alter the attributes in an application and along with that, it also publishes events whenever a problem occurs.
The best thing is, that they you can integrate it with systems that are based on SNMP as they are quite common in operations.
“SNMP (Simple Network Management Protocol) is an Internet-standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks and more.”source: wikipedia.org
Along with that, there are several other monitoring tools such as graphite that are integrated with JMX.
Source: https://camo.githubusercontent.com
Therefore, you can also use it without an Application Server. You can make use of Jolokia JMX data that can be also reached by REST as data of JSON. This is the easiest way to evaluate by making use of simple scripts of a shell.
Source: http://3.bp.blogspot.com/-aSTrhsdPK7s/T0lhNFrLycI/AAAAAAAAAiE/h866ogGiTk8/s1600/psi-probe.jpg
Getting along with application servers
(… and what is the difference from traditional deployment). Talking about the basic application development model of Java EE application is that it creates archive WAR or EAR and makes sure to deploy it on the application server. The dependencies, for instance, are encapsulated in the package for the application server and render functionalities that are needed by the application classes.
WildFly Swarm is a new project that is designed to support WildFly 9.x so as to empower it to break the WildFly AS and to use the requisite amount with your application so as to create a self-contained jar.
Source: http://wildfly-swarm.io/images/swarm_logo.jpg
There are multiple archives deployed in the development, and they can share the libraries. This is quite a simple model and has been used since quite some time now.
WildFly Swarm creates a “fat jar” in which it encapsulates all the dependencies in a JAR file. This comprises of a minimalistic version of WildFly, the application code, and the requisite dependencies. All you need is simlpy run a command java -jar to run the application.
Every Jar file could be a microservice which can be subjected to possible actions such as scale, upgrade, or even replace. Every single “fat jar” file handles a single
responsibility and therefore on the requisite dependencies in its package.
Furthermore, every JAR file makes use of polyglot persistence and makes use of the required persistence mechanism. You can pack your Java EE application as WildFly Swarm “fat jar” and do that you need to add Maven dependency and also a plugin for the same.
All in all! Microservices are the latest trend not just this the latest concept in technology, but they are have drastically changed the way we now develop applications and have considerably improved the performance, high availability and scalability.
Author
Maria Mincey, Software developer at Xicom Technologies software development company. They deliver comprehensive web applications and solutions for different industry verticals.
Related Posts
Author bio
Matej Koval is a Full stack senior Java developer, Scrum master of a team.
Experienced in Debian Linux administration and technologies like: Spring Boot, Quarkus, Kafka, Docker, Kubernetes, Angular.
More info about me: LinkedIn