Thursday, February 25, 2016

Asynchronous Streaming Request Processing in Spring MVC 4.2 + Spring Boot

With the release of Spring 4.2 version, Three new classes have been introduced to handle Requests Asynchronously of the Servlet Thread. Which are;
  1. ResponseBodyEmitter
  2. SseEmitter
  3. StreamingResponseBody
ResponseBodyEmitter enables to send DeferredResult with a compatible HttpMessageConverter. Results can be emitted from threads which are not necessarily the Servlet Request Thread of the Servlet Container.

SseEmitter is used to send Server Sent Events to the Client. Server Sent Events has a fixed format and the response type for the result will be text/event-stream.

StreamingResponseBody is used to send raw unformatted data such as bytes to the client asynchronously of the Servlet Thread.

ResponseBodyEmitter and SseEmitter has a method named complete to mark its completion and StreamingResponseBody will complete when there is no more data to send. 

All three options will be keeping alive a connection to the endpoint until the end of the request.

StreamingResponseBody is particularly useful for streaming large files such as Media Files as writing of the bytes to the Response's OutputStream will be done asynchronously. StreamingResponseBody has a writeTo(OutputStream os) call back method which needs to be overridden inorder to support streaming.

I wrote a small Spring Boot Application to showcase the StreamingResponseBody capabilities in terms of Streaming large files. The application source code can be found at www.github.com/shazin/itube. Below is a screen shot of the application.




In order to send the Video files streaming to the Projekktor player in the web page following code snippet is used.


And a Custom Web Configuration to over ride default timeout behavior to no timeout and finally configuring an AsyncTaskExecutor


References

Tuesday, February 16, 2016

The New Buzz Word in Information Technology Space - Microservices

Microservices, a word which is buzzing around information technology space almost everyday. What is this means? How did we get here?

Well to start off we need to go back to good old days to see how enterprise applications were developed. Most of the application developed at that time where Monolithic. Monolithic applications are collection of functionalities grouped together which will eventually be compiled and packaged into one single application. In Java terms a Jar/War/Ear. In a monolithic application if an application had a Web Tier, User Registration and Account Registration functionalities. All these will be packaged and deployed as a single unit. Let's see the pros and cons of this approach.

Pros of Monolithic Applications

  1. Easy steps to build (can be automated).
  2. Ease of monitoring.
  3. Centralized code repository.
  4. Code is monoglot.
Cons of Monolithic Applications
  1. As the Application becomes complex and large building can take significantly more time.
  2. During deployment of newer versions there are down times for the application.
  3. Less Flexible for change.
  4. Difficulty in scaling out. 
These cons are blockers for High Availability/Low Latency, Rapidly Evolving applications. In order to address these Software Architects tried Modular/Component programming where each functionality is developed as a separate module/component. This in fact managed to reduce the build time drastically. But the applications were still monoliths. Deploying a newer version of a module/component meant that the whole application had to stop and restarted as they are run in one process.

Enter Microservices, According to Martin Fowler microservices means;

The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.

His illustrations clearly distinguishes a Monolithic application from a Microservices architecture.

Figure 1


Having a Microservices based architecture means that your applications can;
  • Evolve rapidly and independently.
  • Deploy and test a service easily.
  • Scale out or in for demand.
  • Be polyglot (Each Microservice can be developed using separate Programming Language/Database).
  • Be developed by Small, Independent, Easy to Manage Teams
Lets have a look at Hypothetical Microservices Application. The company MS have business cases for User Registration and Account Registration. User registration has sub use cases (Persisting User, Sending Email Account Verification, Verifying Email Account) of their own which are complex and time consuming but must be flexible for change. Account Registration means maintaining the financial aspect of the User. Furthermore there is a REST API web tier open to users and partners. The following microservices architecture can be used to implement MS company application.


For implementation we can use Spring Boot as it allows to create both Web Container based as well as Stand Alone Production Ready applications using minimal coding. There are more alternatives if you are not a fan of Spring at https://github.com/mfornos/awesome-microservices

When Rabbit MQ is installed successfully, this microservices based application is ready to run. The applications are so independent there is no order to start the microservices. Just running the Main methods of all three projects would spin up the required service.

When a Create New User request is sent to the Web REST API it is enqueued in ms-user queue which will be dequeued and processed by User Registration microservice, which after finishing processing will enqueue another message in ms-account queue. Those messages will be handled by the Account Registration microservice. 


Request to REST API

Message Dequeued from Rabbit MQ queue ms-user


Message Dequeued from Rabbit MQ queue ms-account

All the microservices run on their own process and can be modified, scaled out and/or in transparently. The implementation source code can be found at https://github.com/shazin/ms

References