Few days back while following a nice post I came across the term "ASYNCHRONOUS, NON-BLOCKING, EVENT BASED SYSTEM".
That's indeed at the very first sight a JARGON to me.
I am very feebly acquainted with each of this terms and so thought of taking a deep dive, and the result that made me to expedite my searching quest is "NETTY".
NETTY is a framework used for rapid development of high performance and mantainable network applications. It is asynchronous and event driven in nature.
Now this definition being completly alien to me, I cannot ascertain from this point where to go next as the definition of term "ASYNCHRONOUS, NON-BLOCKING, EVENT BASED SYSTEM" is still not very clear and the context where this can be applied.
Since I have got no profound exposure to Network Programming and mostly been with HTTP protocol, so if I can relate to something that involves HTTP and Netty then may I may arrive at a better situation, and thats where I encountered RATPACK.
RATPACK is basically a toolkit (i.e. a conglomeration or collection of libraries). It is built on Java8, Netty and Reactive principles and moreover it is groovy based and has got DSL involvement. For this time being I am keeping aside the "REACTIVE" term will revisit it later.
I did start RATPACK and here is the GITHUB LINK
Using RATPACK helps in rapid development of high performance of HTTP application and most interestingly the secret behind the rapid development is its Asynchronous, Non Blocking, Event based model.
Lets go through each term separately:
1) ASYNCHRONOUS: During asynchronous call the Main Thread of execution pass on without getting stuck. The response later may be derived using Polling or Callback. For example while making Asynchronous Database call, the call i.e. the Main Thread do not wait for the resultset to arrive rather the contol passes on and later the availibility of the resultset can be obtained using Callback or Polling mechanism.
2) NON BLOCKING: Asynchronous and NON-BLOCKING are often synonymous in some context, The term NON-BLOCKING we mostly encounter while doing I/O operation. Basically during non-blocking, the call it will return immediately with whatever available and it expect the caller to execute the call again to obtain the rest of the data, i.e. the main thread of execution here too did get blocked.
3) Event Based: During NON-BLOCKING read write operations the control simply returns with whatever it has rather waiting for the whole response to arrive. The Caller needs to make the call again after sometime to get the response, but the question arises WHEN? This is where EVENTS get in. The OS returns events upon completion of Non-Blocking calls. There are libraries to wrap these events for further processing. So Non-Blocking and Events Base goes side by side.
The Reactive Manifesto being described as:
Here too the message-driven srchitecture is being followed.
While I was about to get started with RATPACK, thats when I met Vert.x, which too has Netty based architecture.
Its polyglot (so, that means I can code in Groovy too!!!!) specification along with vivid documentation and presence of varied modules is really impressive.
I have no intention of comparing RATPACK with Vert.x as both seems equally interesing to me.
The priciple on which Vert.x works is same as Node.js, i.e. EVENT Loop OR EVENT Thread. Let me confess this at the very beginning that I am no JS guy at all. But after getting some some idea on the architecture on which Node.js works is really impressive and Vert.x works on the same rule too.
I got clear idea about Event Loop from HERE
Since I come from Object Oriented Background and Spring being my passion, the first thing that came to my mind is what about "DI" principle in Vert.x .
and let me tell you Google's "Guice" the DI engine came to the rescue.
In this post I will try to explain how can be implement "Guice" at the very basic level including deploying multiple verticles using a Single Master verticle.
In the next post we will try go over the implementing Websockets with Event bus and Microservice architecture .
So Let's start.
1) Deployment and DI
2) Websockets with Vert.x Basics
3) Service Registration N Discovery
4) WebSockets Revisited
I am very feebly acquainted with each of this terms and so thought of taking a deep dive, and the result that made me to expedite my searching quest is "NETTY".
NETTY is a framework used for rapid development of high performance and mantainable network applications. It is asynchronous and event driven in nature.
Now this definition being completly alien to me, I cannot ascertain from this point where to go next as the definition of term "ASYNCHRONOUS, NON-BLOCKING, EVENT BASED SYSTEM" is still not very clear and the context where this can be applied.
Since I have got no profound exposure to Network Programming and mostly been with HTTP protocol, so if I can relate to something that involves HTTP and Netty then may I may arrive at a better situation, and thats where I encountered RATPACK.
RATPACK is basically a toolkit (i.e. a conglomeration or collection of libraries). It is built on Java8, Netty and Reactive principles and moreover it is groovy based and has got DSL involvement. For this time being I am keeping aside the "REACTIVE" term will revisit it later.
I did start RATPACK and here is the GITHUB LINK
Using RATPACK helps in rapid development of high performance of HTTP application and most interestingly the secret behind the rapid development is its Asynchronous, Non Blocking, Event based model.
Lets go through each term separately:
1) ASYNCHRONOUS: During asynchronous call the Main Thread of execution pass on without getting stuck. The response later may be derived using Polling or Callback. For example while making Asynchronous Database call, the call i.e. the Main Thread do not wait for the resultset to arrive rather the contol passes on and later the availibility of the resultset can be obtained using Callback or Polling mechanism.
2) NON BLOCKING: Asynchronous and NON-BLOCKING are often synonymous in some context, The term NON-BLOCKING we mostly encounter while doing I/O operation. Basically during non-blocking, the call it will return immediately with whatever available and it expect the caller to execute the call again to obtain the rest of the data, i.e. the main thread of execution here too did get blocked.
3) Event Based: During NON-BLOCKING read write operations the control simply returns with whatever it has rather waiting for the whole response to arrive. The Caller needs to make the call again after sometime to get the response, but the question arises WHEN? This is where EVENTS get in. The OS returns events upon completion of Non-Blocking calls. There are libraries to wrap these events for further processing. So Non-Blocking and Events Base goes side by side.
The Reactive Manifesto being described as:
While I was about to get started with RATPACK, thats when I met Vert.x, which too has Netty based architecture.
Its polyglot (so, that means I can code in Groovy too!!!!) specification along with vivid documentation and presence of varied modules is really impressive.
I have no intention of comparing RATPACK with Vert.x as both seems equally interesing to me.
The priciple on which Vert.x works is same as Node.js, i.e. EVENT Loop OR EVENT Thread. Let me confess this at the very beginning that I am no JS guy at all. But after getting some some idea on the architecture on which Node.js works is really impressive and Vert.x works on the same rule too.
I got clear idea about Event Loop from HERE
Since I come from Object Oriented Background and Spring being my passion, the first thing that came to my mind is what about "DI" principle in Vert.x .
and let me tell you Google's "Guice" the DI engine came to the rescue.
In this post I will try to explain how can be implement "Guice" at the very basic level including deploying multiple verticles using a Single Master verticle.
In the next post we will try go over the implementing Websockets with Event bus and Microservice architecture .
So Let's start.
1) Deployment and DI
2) Websockets with Vert.x Basics
3) Service Registration N Discovery
4) WebSockets Revisited
No comments:
Post a Comment