SpringParadigm

1) Index creation or deletion: For Nested Type (Index name is Book) and Parent - Child Relationship (Index name is ParChild) @RequestMapping(value="/addIndex",method = RequestMethod.POST) def addBookIndex(@RequestParam(name = "indexName")String indexName){ logger.info "****** Adding Book Index: $indexName in ELASTIC DB......" def result = elasticsearchTemplate.createIndex(indexName) logger.info "****** Result is: $result " result } @RequestMapping(value="/deleteIndex",method = RequestMethod.POST) def deleteBookIndex(@RequestParam(name = "indexName")String indexName){ logger.info "****** Deleting Book Index: $indexName in ELASTIC DB......" def result = elasticsearchTemplate.deleteIndex(indexName) logger.info "****** Result is: $result " result } 2) Creating Mapping Type Whenever we save a doc

ElasticSearch quite a familiar term. The first question that comes in our mind is: 1) What ElasticSearch is? & 2) Why should we use it? So to answer the first question, I would like to describe ElasticSearch as a wrapper over Apache Lucene (Apache Lucene is a high performance, text search engine library written in Java). So, ElasticSearch in its core is a distributed full-text search engine which is incredibly easy to scale (because of its well designed anatomy), returns results at a lightning speed (because of its analyzers which tokenize the texts and creates a reverse indexing just like the indexing of a book, a variety of analyzers are available), schema free in nature and supports JSON. The best part about elastic search which I experienced is all its functionalities are being exposed as REST services. ElasticSearch is a distributed NO SQL database where every input to it goes in JSON format and it has its very own way of storing data in data file

Learning OAuth2 security protocol has always been one of my prime objectives. After integrating JWT token with Spring Security, I thought of giving a try with learning OAuth2 with Spring Security, as Spring Security provides implementation for OAuth2. To know the basics of OAuth2 I followed this. This article along with Aaron Parecki's blog really helped me in getting the concept behind this security protocol. Let's revise the components involved here: •Resource Owner •Client •Resource Server •Authorization Server and the grant types are: •Authorization Code •Implicit •Resource Owner Password Credentials •Client Credentials We have implemented both the Resource and Authorization server at the same endpoint for the sake of simplicity, however we can implement them separately too. And out of the four grant types I have been successful in experimenting with the last two only. I will try to share those experience here. I have selected JWT as

Spring Security has always been one of my favourites which I explore often, since the time of xml configuration. This time I tried to implement Security with JWT token using Spring Security module (Java config) and I must say the java config has changed much since the time of XML configuration. Let’s chalk out the high level flow first: 1) User at first will fetch the JWT token from the URL: http://localhost:8080/SpringToken/auth by passing the user id and password in json format in the request body. We will make this URL “permit all” in Spring Security so that Spring does not enforce any authentication or authorization rule for this URL and anonymous authentication is implemented with AnonymousAuthenticationToken. This URL invokes a Handler method which generates JWT token sets it in the Security Context holder and returns it to the client. 2) The client while making subsequent request to access resources need to set the token in the request header named X-Aut

Logging is always being considered as a fundametal and inherent part of any application, irrespective of the language and platform chosen. By the question arises that "Why Logs are very important???" Beacause I think it is the logs that help us get the real time impression of our application behaviour, i.e the user stimulus, the system responding to it, all the data that are being acted upon etc. In a word the I can say not only the Lifecycle of the application but the human interactions too gets recorded while logging. So Logging is basically the process of recording application actions and state. The stream of events that gets captured while logging becomes a very important source of application's current state and the state to which it needs to be evolved. Today Logging becomes the source of data analytics and data mines are emerging out from it which is helps us to make the application behave in a more intelligent manner. But for all these to happen, we

Yes, the POST name The Final FALLBACK is absolutely inline with what we will discuss here. We are talking about HYSTRIX-THE CIRCUIT BREAKER , which provides the FALLBACK functionality in Microservices architecture. The Code can be accessed at GITHUB Hystrix - The Circuit Breaker: The fallback mechanism is one of the most prominent and important partner in a microservice landscape and it can be implemented with Hystrix in Spring Ecosystem. The vivid documentation can well be found at the official Site. Here is the basic implementation of Circuit Breaker with Hystrix. Our architectural landscape is almost similar to the following: The incoming request first arrives at the “GATEKEEPER”(ZUUL has also got RIBBON) , which routes it to the Feign Client, which is both “HYSTRIX” and “RIBBON” enabled. The “RIBBON” does the Load Balancing work smartly, and which we can see in action, if more than one instance of the service (here AUTH-SERVICE) is being deployed. Now,

This post will be dedicated to Centralized Configuration Management for Microservices architecture. The Codebase is present at GITHUB Spring-Cloud-Config: Spring Cloud Config provides us a Centralized way of managing configuration details or properties for different services. Other services can refer to this service for managing their configuration. The Starter Class looks like: @SpringBootApplication @EnableEurekaClient @EnableConfigServer public class ConfigStarter { public static void main(String[] args){ SpringApplication.run(ConfigStarter.class, args); } } We have defined configuration for our AUTH-SERVICE only. However we can define configuration properties for any number of services we like. Within src/main/resources we have defines config folder and define two properties file: 1) auth-service.yml 2) auth-service-dev.yml The first property file will be referred by AUTH-SERVICE when it was initialized in default profile, and the second

Clients are such an important part of any business architecture, because it is for them all the services are meant and we remain always committed in fulfilling their ends, and if they provide an easy interface to interact with them, then sure I cannot ask for more. To access the microservices, we either use: 1. Restemplate based client 2. Feign Based client. We will discuss both of them here. I have uploaded my code base at GITHUB When talking about clients that can access the services rather microservices registered in Eureka, the first approach we have taken is with “RESTTemplate” . The RESTTemplate that we have used (rather injected) in Spring-Cloud-Client is auto configured by Spring Cloud and uses Netflix Ribbon to do the micro-service lookup. Ribbon is the software based load balancer implemented at the client side helps to pick a microservice based on service-name (as registered with the Eureka) specified with the property: spring

Hi Friends!!!, It has been really long since last I wrote for Spring HATEOAS , and along with that I really want to apologize for not completing it and soon I am going to post all my finding on that. But before going into that I thought why not Refurbish ourseleves with something new, something really interesting. Here it is, Spring Cloud Spring is always considered as an onestop need for all the requirements, and when I say that I mean in each and every aspect, which makes Spring essentially an ecosystem. Spring Cloud is no exception to that. Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems. 1) configuration management 2) service discovery 3) circuit breakers 4) intelligent routing 5) micro-proxy 6) control bus 7) one-time tokens 8) global locks 9) leadership election 10) distributed sessions 11) Cluster state. With the MICROSERVICES gaining popularity at a fast pace, becau