This chapter introduces key concepts and terminology used in the Niagara architecture.
There are typically four different programs (or processes) associated with a Niagara system. These programs and their network communication are illustrated via the arch-communication:
There are typically three network protocols that are used to integrate the four programs described above:
Encrypted versions of these protocols are available and are generally the preferred configuration default.
Niagara is hosted on a wide range of platforms from small embedded controllers to high end servers:
The Niagara architecture is designed around the concept of component oriented programming. Components are self contained units of code written in Java and packaged up for deployment as modules. Components are then wired together to define an application and executed using the station runtime.
A Niagara application designed to be run as a station is stored in an XML file called config.bog. The bog file contains a tree of components, their property configuration, and how they are wired together using links. Station databases can be created using a variety of mechanisms:
Stations which restrict their programmability to accomplish a dedicated task are often called appliances.
Note: Often the term Supevisor or Jace will be used interchangeably with station. Technically the term station describes the component runtime environment common all to all platforms, and Supervisor and Jace describe the hosting platform.
The daemon provides functionality used to commission and bootstrap a Niagara platform:
On Windows platforms, the daemon is run in the background as a Windows service. On QNX it is run as a daemon process on startup.
The most common way to access daemon functionality is through the workbench. A connection to the daemon is established via the “Open Platform” command which opens a PlatformSession to the remote machine. A suite of views on the PlatformSession provides tools for accomplishing the tasks listed above.
Another mechanism used to access daemon functionality is via the plat.exe command line utility. This utility provides much of the functionality of the workbench tools, but via a command line program suitable for scripting.
Run plat.exe
in a console for more information.
Niagara includes a powerful tool framework called the workbench. The workbench is built using the bajaui widget framework which is itself built using the standard Niagara component model.
The workbench architecture is designed to provide a common shell used to host plugins written by multiple vendors. The most common type of plugin is a view which is a viewer or editor for working with a specific type of object such as a component or file. Other plugins include sidebars and tools.
Workbench itself may be morphed into new applications using the BWbProfile
API. Profiles allow developers to reuse the workbench infrastructure to create custom applications by adding or removing menu items, toolbar buttons, sidebars, and views.
An important feature of Niagara is the ability to provide a user interface via a standard web browser such as IE or Chrome. Niagara provides both server side and client side technologies to build web UIs.
On the server side, the WebService
component provides HTTP and HTTPS support in a station runtime. The WebService provides a standard servlet engine. Servlets are deployed as components subclassed from BWebServlet
. Additional classes and APIs are built upon this foundation to provide higher level abstractions such as BServletView
.
There are two client side technologies provided by Niagara. The first is web workbench which allows the standard workbench software to be run inside a web browser using the Java Plugin. The web workbench uses a small applet called wbapplet to download modules as needed to the client machine and to host the workbench shell. These modules are cached locally on the browser’s hard drive.
In addition to the web workbench, a suite of technologies called hx is available. The hx framework is a set of server side servlets and a client side JavaScript library. Hx allows a real-time user interface to be built without use of the Java Plugin. It requires only web standards: HTML, CSS, and JavaScript.
Bajaux provides an environment for developing modern web-based user interfaces. In Niagara 4, the user interface is moving in a new direction with a heavy focus on HTML5 applications and open web technologies. A number of frameworks and utilities are provided, and are intended to give developers the power to create their own web apps, from tiny field editors to powerful, full-featured full-screen views. Find information at Building JavaScript Applications for Niagara.
The Niagara Framework includes a proprietary protocol called Fox which is used for all network communication between stations as well as between Workbench and stations. Fox is a multiplexed peer to peer protocol which sits on top of a TCP connection. The default port for Fox connections is 1911. FoxS is the encrypted protocol that encapsulates all Fox communications in a secure transmission. The default port for FoxS is 4911. Fox features include:
Niagara provides a broad suite of Java APIs used to customize and extend the station and workbench. The software stack diagram illustrates the various software layers of the architecture:
Copyright © 2000-2019 Tridium Inc. All rights reserved.