This project is read-only.

Reactor Service Grid

Reactor Service Grid is a service composition and deployment grid that streamlines developing, composing, deploying and managing services. Reactor Services are comprised of "Service Parts". Service Parts are pieces of pluggable logic that define a service's purpose and capabilities.


Reactor Service Grid Concepts

Reactor Service

It starts with one base component, the ReactorService. This service can be run as a console app for testing or as a Windows Service for staging and production. The ReactorService is a service shell that upon startup, obtains common service parts that make up all services. By creating common parts and making them available to all services, it ensures all services contain a consistent set of base functionality and internal components. Once all Common Service Parts have been loaded, the service then seeks out Extension Service Parts that are assigned to that particular instance. These Extension Service Parts define the service's purpose and capabilities.

Reactor Core

Another very key component to this system is the Reactor Core. The Reactor Core is a specialized version of the ReactorService that is provided a set of Extension Service Parts that give it the ability to monitor services, control service lifetimes, and adopt services. Each physical or virtual server that is to participate in the Reactor Services Platform will have one Reactor Core running on it. This will be the last time services will need to be manually installed on these servers.


Encompassing SOA Framework

This composition, deployment, and management architecture is built upon an Enterprise Service Bus to facilitate the delivery of commands and events. Service models can be saved in such a manner that plugging new services into, say a CQRS style architecture, is easy and consistent. Picture a modeled service called CommandHandlerService that can be further composed of CommandHandler Service Parts. This makes maintaining and growing a CQRS or other service oriented architecture easier. The management UI provides, at any time, a view into the architecture and what services are performing what actions.


Service Bus

Out of the box, the Reactor Services Grid utilizes the default implementation of Reactor Service Bus, a part of the Reactor Platform. The Reactor Service Bus can utilize several underlying transports and an adapter can be written to adapt Reactor's service bus to virtually any other queue, broker, or service bus rather easily.



The Reactor Management Studio is a WPF client application that allows personnel to view running Reactor Cores and the services that are overseen by them, and deploy more child services. Allows the user to upload new Service Parts into a catalog, and compose services from these parts. Once a service and its capabilities has been modeled, an AdoptServiceCommand is sent to the Reactor Core the user designates as this new service's overseer. That Reactor Core processes the command by composing the modeled service out of parts in the catalog and runs it as a Windows Service locally. Reactor Cores can be commanded to adopt, drop, and transfer services based on need.

Future releases could include features that make deployment of modeled services based on server performance statistics, such as utilization and availability. Another feature would be to make it a true processing grid by having services import Service Parts for specific needs in a process-distributed manner. Yet another feature would be to model the design of the Reactor Services Grid in a visual designer, save it for later, or commit it. This ability would allow architectural diagrams to always be accurate because they're used to deploy services and, in reverse, the diagrams would be generated based on existing architecture. Move a service or recompose a service's parts, regenerate the diagram, and bring to the next meeting where you have to discuss the view of the current architecture.

Last edited Feb 22, 2011 at 9:46 PM by akilhoffer, version 6


No comments yet.