In this post I want to introduce simple solution that allows you to keep your application architecture clean. For those of you who haven’t heard about Clean Architecture approach I recommend to read Uncle Bobs article. The main idea is to defer the decision of selecting storage engine we choose for our application, because the database is only a detail. It’s not important if it will be SQL, NoSQL or graph database. A database in our application is only the detail which should be easy to change. Premature selection of a database can have negative influence for creating our domain model. For example if we use Hibernate which is JPA implementation and we start writing code from creating Hibernate entities, it will lead us then to high coupling between our core elements and ORM framework. Postponing decision about a database can change our point of view on domain model and stop future degradation of code base.

Earlier in 2015 Red Hat made initial release of their new project called WildFly Swarm. This solution allows to run JavaEE based applications as microservices. It’s a competitor for many frameworks like Spring-boot or Dropwizard which are used for creating small application based on microservices architecture very fast. The application server now can be embedded into your application jar with all his dependencies or you can deploy your applications war into standalone WildFly application server instance as before. It’s a big step for JavaEE world and I hope that it will silence all people who were complaining about JavaEE fat application servers.

About a month ago I was at JDD conference which took place in Cracow. JDD is a two-day, Java focused, international based conference. There you have a chance to speak with many Java enthusiasts, exchange your experiences with attendees and speakers from all over the world. The conference was consisted of four parallel paths so everyone could find something interesting for himself. There were many technical lectures as well as soft topics, workshops and interactive trainings. I enjoyed the conference and I’m looking forward to the next edition.

In time of microservices, it’s relevant how we think about securing remote communication between multiple applications and how we react on network/application failure as a client. If our application depends on many external services and communicates with them remotely, it should be protected in case of network problems or unavailability of the application. One of the basic solutions is to use CircuitBreaker pattern, you can find more detailed description on Martin Fowler’s website http://martinfowler.com/bliki/CircuitBreaker.html.

Today I want to show you how easily you can monitor your JMS queues on WildFly 8 application server. JMS provides some statistics data like total added messages, messages pending in queue or number of consumers connected to queue. We can gather and analyze those data in our monitoring system.

We could also create triggers for the purpose of alerting us when there are no consumers for the queue. This could easily end up with queue swelling thousands of messages. We will use Dropwizard Metrics library which is very nice and easy for gathering and measuring data in our application. We will expose this data through REST as JSON. We won’t rely on JMX protocol because protocol used for providing data for monitoring should be technology agnostic. While providing data for monitoring system, we should use standard protocol for every technology, in our case, it will be HTTP.

I’ve got an idea that writing a blog should be my next step in improving myself. I’ll write mostly about technical stuff like java, jvm, microservices, frameworks but also about my thoughts about other relevant things. I treat my blog as an archive for my ideas, proof of concepts and thoughts that I want to share with other programmers. Even if nobody reads it, it will be a nice practice for me.