reacto - The Client Component
The rationale behind detailing the harmony among indivudual components both at the Server and the Client side, so that readers can get a clear picture of different REACTIVE components and their flows.
RECATO is built on RxJava and Vert.x . The principles on which these two entities are based out promises Resilliency, Resposiveness, Elasticity, Event Driven Architecture and Asynchronous behaviour. All of these commits towards a more Scalable Architecture.
Service Registry is the component through which we invoke commands.
Implementations are:
1) VertxServiceRegistry.
2) LocalServiceRegistry.
Let’s examine the control flow with VertxServiceRegistry.
The Command Execution feature that VertxServiceRegistry provides is due to the implementation of ServiceRegistry interface which provides necessary methods to execute a given Command.
With the given Command as input, alongside with ServiceDiscovery , all the records are fetched which are recently updated and having Command and Event type in their Metadata same as that of the input Command, and create ServiceRecords out of them.
Based on each ServiceRecord , the EventHandlers from the EventHandlerRegistry is obtained. EventHandlersRegistry maintains a mapping of the ServiceRecord to EventHandler with Service Type as KEY.
Next CommandExecutor are created out of the EventHandlers and they execute the commands. The CommandExecutor do have the reference of EventHandlers for the corresponding ServiceRecord.
While executing Commands with the corresponding CommandExecutor, the control is delegated to the EventHandler, which in turn creates an Http Client out of the ServiceRecord that it has and opens up a WebSocket Stream through which EventHandler sends the Commands and receives the Corresponding Stream of Events.
Now, when the EventHandler sends out the Command as a byte stream over WebSocket, it reaches the WebSocket handler that we have configured earlier while setting up the server.The Handler then delegates the execution of the command to CommandProcessor (as described in the Server Section above), which finds the Function (Command -> Observable(Events)) for the corresponding input from the CommandRegistry (which has already been passed as an input to the Command Processor during setting up of the WebSocket Handler) and execute the Commands and returns the result.
Primary Components which make this flow complete are as follows:
1) EventHandlerRegistry: This registry maintains a mapping of Service Type to Function.
ServiceType which is a enum denotes whether the Service is of WebSocket type or Local and depending on that we can provide EventHandler implementation.
EventHandlerRegistry basically maintains a cache containing ServiceRecord and its corresponding EventHandler. This cache is populated for a particular Command when the Command is being executed for the very first time, so that over the subsequent execution of the same command we get the corresponding event handler from the cache, rather than creating it over again.
Please NOTE: EventHandlers always corresponds to ServiceType of a Particular ServiceRecord, and in the cache each ServiceRecord has its own instance of the EventHandler.
2) CommandExecutor: CommandExecutor which plays the role of as a facade, wraps eventHandlers and delegates the execution of Commands to them. ReactoCommandExecutor is one such entity, which carries with it the EventHandlers and the Loadbalancers.
Here, I would like to point out a pretty cool demonstration of the Functions being passed as an argument.
The execute() method which is declared in ServiceExecutor interface passes ReactoCommandExecutor.FACTORY for CommandExecutorFactory. Basically the ReactoCommandExecutor.FACTORY is the reference of the constructor of ReactoCommandExecutor, which takes List of EventHandlers and LoadBalancer as input and ReactoCommandExecutor is of type CommandExecutor and the CommandExecutorFactory which too is a Functional Interface has the same argument and return type as of ReactoCommandExecutor .
3) EventHandlers: It is the EventHandler which ultimately executes the command by opening a WebSocketStream (with the help of the Http Client created out of the ServiceRecord) and receives the response too through websockets.
4) WebSocketHandler: It is the Handler which receives the commands from EventHandler and executes those commands (by delegating them to CommandProcessor) against the corresponding function as present in the CommandRegistry and produces stream of Events and send them over to EventHandler.
5) LoadBalancer: This element is applied while executing Commands with CommandExecutors. The List of EventHandlers as obtained from the EventHandlerRegistry (while executing a particular Command) is selected sequentially by applying the loadbalancer and executes the Commands with the help of selected EventHandler.
Reacto does implement a pretty interesting way of recording the metrics while executing command as well as the overall status of the application. It does so using the Dropwizard Metrics API.
All the JVM and Memory related information, thatare fetched using MemoryManagement API (transformed into Gauge)are registered in MetricsRegistry.
While executing Commands we initiate an instance of Type ObserverMetric which is basically anObserver. While we initiate that instance, we toocreate Meters for each of the corresponding notifications (i.e. OnNext, OnCompleted, OnError) along with a Timer so that we can mark corresponding meters on receiving each notifications accordingly and obviously starting the timer at the beginning of command Execution so that we have all the details during each Command Execution.
Reacto caches each Command to be executed and its corresponding ServiceRecordswithin a Data Structure, where Commands expires after a time interval that we specify while creating the Data Structure. So if we execute the commandwithin the stipulated window we will obtain the corresponding ServiceRecords as present in the cachefrom 2nd time (as during first time there would no cache entry for the command) and if executed after the timeframe the Function which creates the ServiceRecords is executed again to fetch the fresh list which is again cached for the time period.
Another important component which is worth mentioning is CommandExecutorS (Not CommandExecutor) utility class. This interface with its static methods provides access to different types of CommandExecutorFactory like ReactoCommandExecutor, HystrixCommandExecutor.
RECATO is built on RxJava and Vert.x . The principles on which these two entities are based out promises Resilliency, Resposiveness, Elasticity, Event Driven Architecture and Asynchronous behaviour. All of these commits towards a more Scalable Architecture.
Service Registry is the component through which we invoke commands.
Implementations are:
1) VertxServiceRegistry.
2) LocalServiceRegistry.
Let’s examine the control flow with VertxServiceRegistry.
The Command Execution feature that VertxServiceRegistry provides is due to the implementation of ServiceRegistry interface which provides necessary methods to execute a given Command.
With the given Command as input, alongside with ServiceDiscovery , all the records are fetched which are recently updated and having Command and Event type in their Metadata same as that of the input Command, and create ServiceRecords out of them.
Based on each ServiceRecord , the EventHandlers from the EventHandlerRegistry is obtained. EventHandlersRegistry maintains a mapping of the ServiceRecord to EventHandler with Service Type as KEY.
Next CommandExecutor are created out of the EventHandlers and they execute the commands. The CommandExecutor do have the reference of EventHandlers for the corresponding ServiceRecord.
While executing Commands with the corresponding CommandExecutor, the control is delegated to the EventHandler, which in turn creates an Http Client out of the ServiceRecord that it has and opens up a WebSocket Stream through which EventHandler sends the Commands and receives the Corresponding Stream of Events.
Now, when the EventHandler sends out the Command as a byte stream over WebSocket, it reaches the WebSocket handler that we have configured earlier while setting up the server.The Handler then delegates the execution of the command to CommandProcessor (as described in the Server Section above), which finds the Function (Command -> Observable(Events)) for the corresponding input from the CommandRegistry (which has already been passed as an input to the Command Processor during setting up of the WebSocket Handler) and execute the Commands and returns the result.
Primary Components which make this flow complete are as follows:
1) EventHandlerRegistry: This registry maintains a mapping of Service Type to Function
ServiceType which is a enum denotes whether the Service is of WebSocket type or Local and depending on that we can provide EventHandler implementation.
EventHandlerRegistry basically maintains a cache containing ServiceRecord and its corresponding EventHandler. This cache is populated for a particular Command when the Command is being executed for the very first time, so that over the subsequent execution of the same command we get the corresponding event handler from the cache, rather than creating it over again.
Please NOTE: EventHandlers always corresponds to ServiceType of a Particular ServiceRecord, and in the cache each ServiceRecord has its own instance of the EventHandler.
2) CommandExecutor: CommandExecutor which plays the role of as a facade, wraps eventHandlers and delegates the execution of Commands to them. ReactoCommandExecutor is one such entity, which carries with it the EventHandlers and the Loadbalancers.
Here, I would like to point out a pretty cool demonstration of the Functions being passed as an argument.
The execute() method which is declared in ServiceExecutor interface passes ReactoCommandExecutor.FACTORY for CommandExecutorFactory. Basically the ReactoCommandExecutor.FACTORY is the reference of the constructor of ReactoCommandExecutor, which takes List of EventHandlers and LoadBalancer as input and ReactoCommandExecutor is of type CommandExecutor and the CommandExecutorFactory which too is a Functional Interface has the same argument and return type as of ReactoCommandExecutor .
3) EventHandlers: It is the EventHandler which ultimately executes the command by opening a WebSocketStream (with the help of the Http Client created out of the ServiceRecord) and receives the response too through websockets.
4) WebSocketHandler: It is the Handler which receives the commands from EventHandler and executes those commands (by delegating them to CommandProcessor) against the corresponding function as present in the CommandRegistry and produces stream of Events and send them over to EventHandler.
5) LoadBalancer: This element is applied while executing Commands with CommandExecutors. The List of EventHandlers as obtained from the EventHandlerRegistry (while executing a particular Command) is selected sequentially by applying the loadbalancer and executes the Commands with the help of selected EventHandler.
Reacto does implement a pretty interesting way of recording the metrics while executing command as well as the overall status of the application. It does so using the Dropwizard Metrics API.
All the JVM and Memory related information, thatare fetched using MemoryManagement API (transformed into Gauge)are registered in MetricsRegistry.
While executing Commands we initiate an instance of Type ObserverMetric which is basically anObserver. While we initiate that instance, we toocreate Meters for each of the corresponding notifications (i.e. OnNext, OnCompleted, OnError) along with a Timer so that we can mark corresponding meters on receiving each notifications accordingly and obviously starting the timer at the beginning of command Execution so that we have all the details during each Command Execution.
Reacto caches each Command to be executed and its corresponding ServiceRecordswithin a Data Structure, where Commands expires after a time interval that we specify while creating the Data Structure. So if we execute the commandwithin the stipulated window we will obtain the corresponding ServiceRecords as present in the cachefrom 2nd time (as during first time there would no cache entry for the command) and if executed after the timeframe the Function which creates the ServiceRecords is executed again to fetch the fresh list which is again cached for the time period.
Another important component which is worth mentioning is CommandExecutorS (Not CommandExecutor) utility class. This interface with its static methods provides access to different types of CommandExecutorFactory like ReactoCommandExecutor, HystrixCommandExecutor.
Comments
Post a Comment