Server:Concepts

From FlexRule Wiki
Jump to: navigation, search

Concepts

FlexRule Server will setup a platform for managing business logic (rules, decisions, flow,...). It exposes these logic as a REST API for execution. It also provides capability for managing and monitoring different part of its infrastructure as well as your business logic.

Generally, FlexRule Server has two individual processes.

  1. Master
  2. Agent

Each of them is responsible for different tasks.

Frs-architecture.png

General Process

FlexRule Server offers a business logic server which has tow main responsibilities:

  1. Management: Allows managing logic and nodes
  2. Execution: Runs the logic models by providing values and returning the results

FlexRule Server is built on top of two different types of nodes to process requests:

  1. Master Server node
  2. Execution agents node

They can be installed on one machine, but ideally, you distribute them across your network on different machines for scaling the execution process. When a requests come to a Master, it looks into the pool, and selects a free and healthy agents and send the execution requests to the agent. Once the agent executed the logic, it returns the result back to the Master and master sends the result to the requester.

Master

Master Server has different parts:

  1. API
    1. Executing logic
    2. Managing resources (e.g. Packages, Users, Accounts, Permissions...)
    3. Monitoring Health (e.g. Database, Master server, agents...)
  2. Logic Repository

Agent

ExecAgent is the processing node that executes the logic. They use FlexRule Runtime to load and execute logic. You don't necessarily need Agent node. You can add it later on for sacalability purpose.

Bulbgraph.pngWhen using FlexRule Server the Agent node might not be needed for your project. Then you can setup the Master to execute the logic itself and send back the results. Check One Node deployment strategy.

Deployment Strategy

There are many difference choices of deployment for FlexRule Server. Which each are designed to answer difference architectural concerns.

One Node

When a simple deployment is required One Node can be used to deploy a Server with minimum configuration and setup. In this model is the Master only model. In this scenario the Master itself will take care of both management and execution of logic.

Deploy-master-only.png

You only need to install the Master on a machine.

Two Nodes

Balancing between Management and Execution responsibility of Server can be implemented by using this deployment strategy. This allows you to split management and execution responsibility into two Nodes.

Deploy-master-one-agent.png

You need to install a Master and an Agent. The Agent can be either on the same machine than Master or different one.

Master with Distributed Agents

This deployment strategy enables for the high-availability scenarios. This mode allows you to create a cluster of processing power for your logic. Which a Master when receives the execution requests, it will distribute them to Agents for processing.

Deploy-master-agents.png

You need to install Master and Agents on different machines.

Distributed Masters and Agents

This deployment strategy allows for high-availability and fault-tolerance. Which you can build up multiple clusters of Master-Agents (Master with Distributed Agents strategy) and put them behind a load balancer that it routes requests to a particular cluster. If a master of a cluster is done, then your load balancer can route the request to other available cluster.

Deploy-multi-master-agents.png

You need to install multiple of Master with Distributed Agents cluster. This strategy requires sharing the Database between Master nodes. By default, each Master node has it's own database. To setup a database across all the Master nodes, you need to use MS-SQL database provider on Master nodes.