The server portion of TIBCO® LiveView, called LiveView Server, is an extension of the server runtime for TIBCO StreamBase®. LiveView Server depends on the StreamBase server runtime to provide its underlying functionality. However, it would be a mistake to think of LiveView Server as simply an instance of the StreamBase server running a StreamBase application. While that description is accurate on one level, LiveView Server also provides the following services, above and beyond the 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 access to clients for data visualization and exportation.
For those unfamiliar with the StreamBase server runtime environment, a brief introduction follows:
-
The StreamBase server is a stream-oriented complex event processing 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. The 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 the StreamBase server is controlled by a StreamBase module usually written in the TIBCO StreamBase EventFlow™ graphical language. The StreamBase installation provides both the StreamBase server runtime and TIBCO StreamBase Studio™, an Eclipse-based development environment for developing and testing StreamBase applications.
-
The StreamBase server runtime runs applications in EventFlow 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. EventFlow 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. The data stream 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 the StreamBase server runtime 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 the StreamBase server runtime running a StreamBase application called QueryServer,
which runs in the EventFlow container named default. The QueryServer application runs as a black box system, and customers are not expected to edit, adjust, or modify the QueryServer
application. From here on, 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 data table, plus an optional table space configuration 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 EventFlow container.
-
The table specification's schema is configured as a StreamBase Query Table, running in memory.
-
The configuration file names the data table; the EventFlow container takes the same name as the table.
-
The table is populated by a data stream.
-
A runnable StreamBase archive 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.
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 called lvconf files (pronounced ell-vee-conf).
All lvconf files that constitute a single LiveView project must reside in the same src/main/liveview folder of your Studio project. When you run a LiveView Server instance, you are running the configuration defined in the
project folder that contains your lvconf files. You can also provide one or more server configuration files in HOCON format.
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.