Came across the term NIO (introduced in Java 4, Java 7 has rolled out NIO2) in a recent project requirement. To me, there was a very thin line of difference in the concepts of having a REST Client use NIO vs. Asynchronous calls. Googling on the net did not provide a very succinct result either. Hence, based on the knowledge gathered here's the summary:
* Asynchronous implies non-real time. Imagine your newspaper-boy; he just drops the paper and goes off to the next house to deliver without waiting for you to open up and hand it over to you. That's asynchronous. Unlike the earlier times milkman who rings the bell and keeps waiting for you to appear with a container and collect the milk; which is synchronous.
*NIO - well, think of it as collecting stuff into a buffer and then taking from it. Imagine a water tap. People do not take drops from the tap; rather it is collected in some bucket or mug et al, that is buffered and then used. Just that the water in the bucket in terms of NIO happens to be the data we are interested in reading from or writing to. Hence, the use of 'buffers' in NIO.
So how does the above sit in terms of REST Client? Well, we were mainly bothered with Jersey Clients. Just note that Jersey also provides Synchronous and Asynchronous Clients. But neither are NIO. The API states it. But interestingly, Jersey has this feature of allowing the use of different Connectors (at Transport Layer). And one of these, namely GrizzlyConnectorProvider uses NIO at the Transport Layer which can be used with both Synchronous and Asynchronous Clients.
Ref# GrizzlyConnectorProvider
Aah, this is a rather short piece but the time spent in crunching out just these few facts did take us quite a while! ;)
* Asynchronous implies non-real time. Imagine your newspaper-boy; he just drops the paper and goes off to the next house to deliver without waiting for you to open up and hand it over to you. That's asynchronous. Unlike the earlier times milkman who rings the bell and keeps waiting for you to appear with a container and collect the milk; which is synchronous.
*NIO - well, think of it as collecting stuff into a buffer and then taking from it. Imagine a water tap. People do not take drops from the tap; rather it is collected in some bucket or mug et al, that is buffered and then used. Just that the water in the bucket in terms of NIO happens to be the data we are interested in reading from or writing to. Hence, the use of 'buffers' in NIO.
So how does the above sit in terms of REST Client? Well, we were mainly bothered with Jersey Clients. Just note that Jersey also provides Synchronous and Asynchronous Clients. But neither are NIO. The API states it. But interestingly, Jersey has this feature of allowing the use of different Connectors (at Transport Layer). And one of these, namely GrizzlyConnectorProvider uses NIO at the Transport Layer which can be used with both Synchronous and Asynchronous Clients.
Ref# GrizzlyConnectorProvider
Aah, this is a rather short piece but the time spent in crunching out just these few facts did take us quite a while! ;)
No comments:
Post a Comment