"The NoPE-Dispatcher is designed as Layer between the different Modules / Dispatchers. They allow distributed computing or just a simple ***Service oriented Architecture*** (*SOA*). A dispatcher is used to link the modules, share data and events and provide a remote procedure call (rpc) interface.\n",
"\n",
"## Building Blocks of a Dispatcher:\n",
"\n",
"| element | description | \n",
"|-|-|\n",
"| `connectivityManager` | establishes a connection to other dispatchers and manages the status of the remotely connected dispatchers. It checks their health and removes dead dispatchers. |\n",
"| `eventDistributor` | shares events accross the network (or internally). You can use this element to listen for specific events. The subscription to those events allows `mqtt`-patterns. Additionaly, you are allowed to emit event on specific topics, or pattern based topics |\n",
"| `dataDistributor` | shares data accross the network (or internally). In comperisson to events, data is persistent and is available all the time. You can use this sub-module to listen for specific data-changes (install data-hooks), pull specific data or push data. You can pull / push data using a `mqtt`-pattern based path. |\n",
"| `rpcManager` | Used to perform `remote procedure calls` (see [here](https://de.wikipedia.org/wiki/Remote_Procedure_Call)). The manager keeps track of the available services. You must use the sub-module to register/unregister (new) services. |\n",
"| `instanceManager` | Used to create/dispose (remote) instances. The manager keeps track of the available instances in the network, allows to create `wrappers` for those instances. You must use the sub-module to register/unregister (new) instances. To allow the system to provide a service for creating instances of as specific type, you can provide a generator and provide it as `service`. |\n",
"\n",
"## Create a Dispatcher\n",
"\n",
"To start exploring the capabilities of the dispatcher we will firstly create a dispatcher with the code below:"
"The `getDispatcher`- function automatically trys to return the dispatcher as `Singleton`. This means, that their will be exactly ***1*** dispatcher in a process. To receive a second dispatcher-instance (which is for performance reasons not recommend) in your process you must set the ``singleton``-flag to `false`\n",
"The relevant Settings are described by the `INopeDispatcherOptions`. This options allows to define:\n",
"* the communication bridge. (use `getLayer` to receive a bridge with the specified layer)\n",
"* define a specific `id`\n",
"* provide a logger (otherwise the dispatcher wont log anything)\n",
"* define the timings for `heartbeats` and `checks` (see `INopeINopeConnectivityTimeOptions` for more details)\n",
"* a `defaultSelector` which is used as selector for a service provide\n",
"\n",
"## Playing with the dispatcher:\n",
"\n",
"To play with a dispatcher, you can use the `nope-js` repl tool. this tool creates a `dispatcher` and you are able to interact with the dispatcher in an interactive console."