LiveView Server is an extension of StreamBase Server, and depends on it to provide its underlying functionality. However, it would be a mistake to think of LiveView Server as simply an instance of StreamBase Server running a StreamBase application. While that description is true on one level, LiveView Server also provides, above and beyond StreamBase Server's streams interface:
-
A data layer, which provides data abstraction.
-
A services layer, which provides alerting and monitoring tools.
-
A client layer, which provides clients for data visualization and exportation.
For those unfamiliar with StreamBase Server, a brief introduction follows:
-
StreamBase Server is a stream-oriented complex event processing (CEP) engine. It accepts one or more streams of structured data, and manipulates, calculates, and processes the data stream as it passes through the server, then optionally emits one or more streams of output data. StreamBase Server allows decisions to be made on streamed data as it streams, without waiting for the data to be stored in a database.
-
The processing of the data stream inside StreamBase Server is controlled by a StreamBase application usually written in the EventFlow graphical language, sometimes supplemented with portions in the SQL-like, textual StreamSQL language. For most platforms, a StreamBase installation provides both StreamBase Server and StreamBase Studio, an Eclipse-based development environment for developing and testing StreamBase applications.
-
StreamBase Server runs applications in containers. If you do not specify a container, your application runs in a default container named
default. You can split complex applications into multiple containers. Containers can be started and stopped as independent units running in the overall server. -
Incoming data streams are expected to be in the StreamBase tuple format of hierarchical name-value pairs that uses a defined schema and includes support for complex streams with sub-tuple and list data types in addition to simple, scalar data types. Plug-in programs called adapters translate data streams from an incoming data format to the StreamBase tuple protocol, or from tuples to an outgoing data format. Input adapters are treated logically like input streams, while output adapters are treated logically like output streams.
-
StreamBase provides a feed simulation mechanism that allows you to develop and test applications by either replaying a captured data feed or generating a synthetic feed with placeholder data. This permits development without having to connect to a live incoming data stream, such as a market data feed with live trade data.
-
StreamBase client applications access StreamBase Server at input stream and output stream access points. StreamBase clients enqueue data to input streams or dequeue data from output streams.
At its heart, LiveView Server is an instance of StreamBase Server running a StreamBase application called QueryServer, which
runs in the default container. The QueryServer application runs as a black box system, and customers are not expected to edit, adjust, or modify
the QueryServer application. Hereafter, LiveView Server is described as a single entity, instead of a server running an application.
LiveView Server's task is to configure one or more data tables and thereafter to accept queries to tables and return results. A LiveView table is generated from a data source. A data source in LiveView is not an external data set; rather, the data source for a table is something that you declare when you configure the table.
However, LiveView Server cannot run on its own, and cannot even start without at least a minimum set of configuration specifications.
When LiveView Server starts, its first task is to compile your provided set of configuration files into one or more working LiveView tables. You provide one configuration file for each table, plus one or more optional configurations that define table spaces used by some or all of your data tables. LiveView Server takes each table's configuration, and compiles it to run as follows:
-
The server clones portions of itself into a runnable table module that manages input to and output from the data table, and accepts queries and returns responses.
-
Each table module is configured to run in its own container.
-
The table specification's schema is configured as a StreamBase Query Table, running in memory by default.
-
The configuration file names the table; the container takes the same name as the table.
-
The table is populated by a data stream.
-
A StreamBase archive (an sbar file) is generated from the configured table module for faster startup of the table if its configuration does not change.
-
If the table's specification includes a data source or application specification that will feed data into the table, then a stream of data begins flowing into the table. In the absence of such a specification, the table is empty and awaits input data.
On subsequent starts, LiveView Server recompiles only the configuration files that have changed, if any.
The LiveView configuration files you provide are written with an XML grammar. Each file's basename must be the same as the
table name specified in the file, and the file extension must be .lvconf. LiveView configuration files are often called lvconf files.
All lvconf files that constitute a single LiveView project must reside in the same folder. When you run a LiveView Server instance, you are running the configuration defined in the project folder that contains your lvconf files. If you are familiar with StreamBase Server, you can also provide a server configuration file in the same folder that holds your lvconf files.
A running LiveView Server provides a services layer based on a REST interface to an embedded web server. LiveView client programs connect using this REST interface, including client programs you develop in Java or a .NET language.