reacto - The Server Component
The Design Principles that has been followed while developing has been described well in its GITHUB home page.
What we will really try,is to understand the orchestration among different components of this library, which in turn will aid in getting idea about Control Flow while we use this toolkit.
There are two modules corresponding to Reacto:
1) reacto -->The Client
2) reacto-vertx --> The Server Counter Part.
reacto-vertx uses Vert.x for Service Publishing and Service discovery along with other features corresponding to Vert.x
The Heart and Soul of this toolkit is centered around two entities. They are:
1) Commands:The input to the services hosted.
2) Events: The output that the services provide while responding to valid Commands. (Basically Observable of Events)
Now the mapping between these entities, i.e. which command would produce what Stream (Observable) of Events is being maintained by another component known as CommandRegistry.
CommandRegistry with the help of a Collection maintains the aforementioned mapping. It also contributes to this mapping creation (between command and events) with its various utility methods.
One noteworthy component that this Registry uses is CommandRegistryMapper. This utility basically maps Command class to any Pojo and also Any Pojo to Event class. Using this mapper we can specify any two distinct pojos to play the role of Command its Corresponding events.(Please note we also need to specify a Function which will relate these two distinct pojos i.e. Function<pojo1, Observable<pojo2>>).
Once CommandRegistry is configured properly we are all set to publish our service.
Publishing services is carried out with VertxServer.
VertxServer carries with it the following components which aid in Service Publishing and Service Discovery:
1) ServiceOptions: Metadata of the service to be published, like name, context path, port etc.
2) ServiceRecord: Basically the idea is to create Services of Different TYPES and then publish them.
Presently two types are supported
i) "WebSocket" and
ii) "Local" Service Type”.
This component helps in creating Service Records out of the metadata i.e. ServiceOptions.VertxServer while publishing services, forms the Record out of the ServiceRecord and publishes them.
The ServiceRecord thus created has also the information of the commands that it supports so that later while invoking a service from client we can filter out services that we obtain via ServiceDiscovery based on the commands passed as input.
We will come back to this section again while discussing the Client part.
3) Router: The Vert.x router for routing requests to various handlers corresponding to request path/URL
4) HttpServer: A HttpServer is created out of Vertx to cater incoming request and is made to listen at particular port that we pass as an argument while creating the server.
5) VertxServer: This component starts/stops the HttpServer that has been created above and also publishes/un-publishes the Service with the help of VertxServiceRegistry (explored below), so that the server is now ready to serve the requests. It registers the WebSocketHandler to receive WebSocket requests. (As the client requests reaches server using WebSocket protocol). Along with this handlers for various endpoints like:
i) Making a Particular service UP or DOWN -> << root >>/service-discovery/:action
ii) To View Hystrix Dashboard -> << root >>/hystrix.stream are added.
6) CommandRegistry: CommandRegistry internally maintains a Map of CommandDescriptor and CommandExecutor. This CommandExecutor is a Functional Interface which expects a Command as input and produces Stream<Events> as output, it is synonymous with Function<Command, Stream<Event>>.
The CommandRegistry is passed as an argument to WebSocketHandler, with the help ofCommandProcessor, so that when the Command reaches the Handler the corresponding Stream of Events could be delivered to the Client using this registry.
As described earlier, we also populate the ServiceRecords during their creation (before they are published as Services) with the Command Details from the CommandRegistry so that while executing Commands we fetch those Records only (with the help of ServiceDiscovery) whose Details matches with the input Command.
7) VertxServiceRegistry: It basically plays a dual role both in Service Publishing and Executing commands. For now, lets get ideas on the first part only.
This component publishes the service and also initiates the HEARTBEAT (which refreshes a particular service at regular interval by un-publishing at first and then republishing them) with the help of its register() method. There is also a unregister() method for releasing or un-publishing the service. It implements ServiceDiscoveryLifecycle which defines the contract.
Now, when the VertxServer is started with all the necessary configurations as mentioned above, the HttpServer starts listening at the designated PORT that we pass as an argument while starting the Server and the service gets published with VertxServiceRegistry.
By default VertxServer does provide some endpoints with the following purposes:
1. << root >>/service-discovery/:action :- With the “action"Path parameter value being restricted to only “start” and “close”, this endpoint with appropriate value in the path parameter may either register/unregister the service.
2. <<root>>/hystrix.stream:-This endpoint publishes Hystrix specific data in a Dashboard.
Another interesting feature of this toolkit that I would really like to bring out here is the “StartHeartBeat”, which re-publishes the same record at every regular interval, a kind of refreshing of the record we can say. That’s pretty awesome.
This is in short about the functioning of reacto-vertx. Now to see the Server in action, we need to dive into CLIENT components and send some Commands.
Comments
Post a Comment