Obsidian supports multiple deployment setups as described in the Getting Started guide. This can be as simple as a single node providing both scheduling and the web application, or as complicated as many scheduling nodes of different types participating in load-sharing and providing failover via a cluster.
Purpose of Each Node Type
Obsidian consists of two main processes:
- Scheduler - schedules and executes jobs, sends notifications, etc. Also exposes the Embedded API.
- Admin Web Application - provides management and monitoring UI, plus the REST API and Embedded API.
These two services may be deployed in different types of deployments. They may be provided by a single application artifact, or they may be split apart, depending on your needs.
A scheduler node represents a scheduler process running within a Java virtual machine, which determines when jobs should run, and executes them. Scheduler nodes can participate in clustering for shared job execution, but do not need to communicate with each other directly. They need to communicate with the Obsidian database and the configured SMTP server (if applicable).
This node may be the standalone artifact that is included in your Obsidian installation, or it may be embedded within your application. If you use the standalone artifact, any job code and its dependent libraries need to be added to the artifact. Conversely, if you embed the scheduler inside your application, you will need to import Obsidian's required libraries and configuration file into your project.
Many of our customers embed a scheduler node inside their own application, so that it can execute your application code without requiring a separate customized Obsidian application. Generally, when you embed Obsidian in this way, you would deploy a separate uncustomized Administration Interface.
- Scheduler, scheduler process or scheduler host - all refer to the Obsidian process running within a JVM that provides Obsidian's job scheduling services.
The administration interface represents the Obsidian web application, which provides a management user interface, and the REST API. Like a scheduler node, it needs to communicate with the Obsidian database, and the configured SMTP server (if applicable), but there is no benefit to deploying more than one of the administration interface since it provides no clustering benefits.
Typically, when you embed the scheduler component, we recommend you run a vanilla administration interface as provided in your installation package, since it does need require access to your job execution code
- Admin/administration webapp, management UI, management web application, etc - all refer to the Obsidian interface web application, deployed to a servlet container.
Combined Scheduler and Admin Interface
The simplest deployment looks like the following. It demonstrates a single node running both the scheduler process and admin interface as a single application, which would be deployed to a servlet container. The logical SMTP server is optional.
Clustered Scheduler with Separate Admin Web Application
A more complex setup with clustered scheduling comprised of multiple node types is shown below. It demonstrates a cluster of 3 scheduler nodes, one of which also serves the admin webapp. Additionally, two more admin webapp hosts provide access to the web application user interface and REST API to a different area of the network.