Reactive Services is a framework that support the development of distributed applications over the .NET/Mono frameworks, following the principles of the Reactive Manifesto and ready for cloud distribution.
Reactive Services applications present the following characteristics:
Applications developed over the Reactive Services framework are modular and ready for cloud distribution by default. That happens due to the heavy focus on asynchronous communication, through message buses, which serves as a guide to the developers to build the applications in the right way.
By default, the communication accross Reactive Services applications and its components happens through these message buses using the patterns Publish/Subscribe, Request/Response and Send/Receive, which allow the implementation of most types of integration behaviors.
Each application can be scaled in different ways. It is possible to instanciate multiple copies of the same application, on the same or on different servers, and let the Reactive Services framework handle the distribution of jobs between these instances. It is also possible to split a single application in multiple workers, which can also be replicated and distributed to better accomodate the work load.
Reactive Services applications presents different levels of supervision. At first, each application can be composed of one or more computational unit. Each computational unit will be a separate process for the operational system. Inside each computational unit one or more workers can be executed. Each worker is responsible for the execution of a single kind of job.
All jobs executed inside a computational unit are supervised and in case one of them fails, it can be have its execution retried before the failure be considered permanent. It is also possible that a job that failed in one computational unit be retried by another computational unit, that can even be running in a different server.
Besides that, the computational units themselves are also supervised. In case its process crashes or stops responding, the computational unit is relaunched by the Reactive Services bootstrap process.
And this can be taken even further by placing the whole application, a bootstrap process and its computational units, inside a container platform that supervise and restart its containers in the case of a failure on the whole thing.
Every communication accross Reactive services applications and its components is meant to be made through a messaging middleware that follows the AMQP protocol. By default, this middleware is the RabbitMQ, which provides secure channels through TLS/SSL and authentication and authorization rules to protect its communications.
Most components of the Reactive Services framework are designed to allow them to be replaced by alternative implementations. That allow the framework to be extensible and fit the needs of its users.
It is possible, for example, to replace the ReactiveServices.MessageBus.RabbitMQ.dll module by a ReactiveServices.MessageBus.ActiveMQ.dll module and then use ActiveMQ as its message bus.
Due to its distributed nature, Reactive Services applications can be installed in individual containers, which leverage the use of all distribution and management resources of such container platform.
- Adherence to the Reactive Manifesto
The Reactive Manifesto describes a criteria to define an application as reactive. Reactive applications are ready for cloud distribution, presenting responsiveness, resilience, elasticity and message driven characteristics, necessary for this kind of application.
To know more about the framework visit its repository on github at http://github.com/reactiveservices.
Sponsored by Concert Technologies SA