Microservices Architecture Implementation: Tech / Tool Stack Map

There are different tool stacks like nodeJs, Spring cloud which we can use to build microservice solutions. Since I’m having a Java background, in this post we will look how the spring cloud solution will help us to develop comprehensive microservices solution. This tool set is applied in my working environment and it’s running smoothly in Production setup.

Due to excellent tool support and easy integration capabilities Spring cloud with spring boot framework makes developer life stress-free.

Below diagram illustrates the full component stack. Will give you a very high level usage of each component in this post. Later we can dig deep in to each component.

Microservices architecture solutions implementation using Java framework: Spring Boot / Spring Cloud Components

  • RAML / Swagger / Thrift : Used to design Contract-First microservices
  • Zuul : Edge Server, Reverse proxy server. API gateway or gate keeper for external parties
  • Eureka : Act as Service registry & discovery component
  • Ribbon : Load balancer
  • Spring Cloud Config : Centralized configuration server for the MSA solution
  • OAuth2 / JWT : Security mechanisms which can be integrated with microservices
  • Hystrix : Monitoring dashboard for the services and fault tolerance configuration component
  • Redis / memchached : Distributed caching mechanisms
  • AMQP / MQTT / STOMP : Messaging protocols for asynchronous communication
  • REST / Thrift : Messaging mechanisms for synchronous communications
  • Docker / OpenStack : Deployment architectures for our microservices
  • Tomcat / Jetty : In-build servlet containers in Spring boot


With all the above tools and components we can build a production ready microservice solution in rapid speed. In the coming posts let’s try to grab more knowledge in those areas.



Read More

Introduction to Enterprise messaging (Basics) with Message Broker

With some industrial experience on Message broker related SOA integrations, thought of discussing about Enterprise messaging. Let’s start with the basics and later in the coming post let’s discuss how we can have a high available messaging architecture.


One mechanism which distributed applications can communicate is via message passing. Before we move ahead let’s check what “message” means.  A message is a structured piece of information sent from one agent to another over a communication channel. Message will have an identifier within it and it will tell the receiver the purpose or type of the message.  We can use different protocols and network standards such as HTTP, SSL, TCP/IP to do message parsing between applications.  However when we talked about enterprise messaging with message brokers, we talk about transmission control protocol. Another important fundamental concept we should know in messaging is the message handling methods. Namely Asynchronous and Synchronous. So let’s discuss it.


Asynchronous vs. Synchronous message handling

One critical thing we need to consider when planning message parsing or processing is to know whether it needs to be Asynchronous or not. First let’s see the difference between the two types.

  • Synchronous Messages:

    Synchronous messaging involves a client that waits for the server to respond to a message. Messages are able to flow in both directions, to and from. Essentially it means that synchronous messaging is a two way communication. i.e. Sender sends a message to receiver and receiver receives this message and gives reply to the sender. Sender will not send another message until it gets a reply from receiver.


  • Asynchronous Messages: Asynchronous messaging involves a client that does not wait for a message from the server. An event is used to trigger a message from a server. So even if the client is down, the messaging will complete successfully. Asynchronous Messaging means that, it is a one way communication and the flow of communication is one way only.

Depending on your business process need you can choose one of the above methods in your communication channel. Now let’s discuss about the message broker which handles all these message flows between different applications.


Message Broker

A message broker is a middleware program that translates messages from the formal messaging protocol of the publisher to the formal messaging protocol of the receiver. Message broker decouples the publisher and consumer systems. The beauty of the message broker is that it can receive messages from a publisher and it can transmit it to multiple subscribers. In addition there are key advantages on using a message broker in the middle of a message communication. They are as follows:

  • Ability to store messages when the consumer is not available to consume the messages
  • Guarantee message delivery between two parties
  • Act as a load controller in the middle of an application to ensure the consumer is not overloaded with requests. All the requests will come to the message broker and it will store them until consumer, reads them one by one with the highest rate it can consume.

Now we know what is the message broker and the importance of it. Next we will look in to the two main subscription models in messaging.


Queues and Topics

As the message handling model, message subscription model also need to be selected based on the business process requirement.  Let’s see what we need to consider when selecting the model.

Queue Topic
Point-to-point model. Publish/subscribe model.
Only one consumer gets the message. Multiple clients subscribe to the message.
Messages have to be delivered in the order sent. There is no guarantee messages have to be delivered in the order sent.
A JMS queue only guarantees that each message is processed only once. There is no guarantees that each message is processed only once. As this can be sensed from the model.
The Queue knows who the consumer or the JMS client is. The destination is known. The Topic, have multiple subscribers and there is a chance that the topic does not know all the subscribers. The destination is unknown.
The JMS client (the consumer) does not have to be active or connected to the queue all the time to receive or read the message. The subscriber / JMS client needs to the active when the messages are produced by the producer, unless the subscription was a durable subscription.
Every message successfully processed is acknowledged by the consumer. Every message successfully processed is not acknowledged by the consumer/subscriber.


Next let’s investigate on how message broker can exist in enterprise SOA.


Messaging Topologies

  • Internal Broker:

    J2EE application server contain message broker (embedded with JMS enabled application server webshere / weblogic / jboss ) and external applications call the message broker. Reliability and performance concern since its inbuild in the application server additional overhead to server resources. Messaging required threads and CPU for processing. Application server down then message broker is also down. Worthy when our queues not exposed to external applications.


  • External Broker:

    Fully fledge message broker solution. Message broker is an external server. Activemq, Sonicmq, Mulemq are some examples for those external brokers. From those we can achieve clustering, fault tolerance, scalability


  • Embedded Broker:

    application with message broker solution in build with it. Source code of your application start the message broker. Message broker part of the applications. It will be a truly localized message broker for an application.


Now we have discussed all the aspects related to message broker and enterprise messaging. In the next post we will discuss on how we can setup an External Broker Architecture with high availability and fault tolerance.



  • http://peoplesofttutorial.com/difference-between-synchronous-and-asynchronous-messaging/
  • Java Distributed Computing by Jim Farley
  • http://www.ebizq.net/topics/eai/features/1590.html
  • JD Edwards EnterpriseOne Transaction Server Reference Guide

Read More