Baselines

General Description

The SmartTUBE SDP server includes a number of components, like Data Server, Cache Server, Reporting Module, etc. Components are located in the Components Container (see SmartSDPCompcontainer Components Container) controlled by ccadmin utility (see Control through ccadmin utility).

The Components are:

• SmartSDPDataModelCore – the component serves as a container for main entities and services of SmartTUBE SDP server.
• SmartSDPDataServer – the component performs the functions of JSON RPC server for handling entities and services of SmartTUBE SDP server.
• SmartSDPCacheServer – the component performs the functions of a server providing access to data and services via API.
• SmartSDPReport – the component performs the functions designed for receiving reports.

Operation and Interaction of Components

Components of SmartTUBE SDP server operate within Components Container (CC) as modules. Each of these components must:

• Implement system interfaces and some of the functional interfaces. The main class of the component must implement ISDPComponent and ISDPPropertiesOwner interfaces described in smartsdp.components package of SmartSDPCommon module (smartsdp-common.jar). Besides the two specified interfaces the main class of the component may inherit from any class and implement any other interfaces. For example, the main class of the component may inherit from HttpServlet class and therefore be a servlet.
• Be prepared for deployment as a JAR file.
• Have a configuration file describing the sequence of component deployment and the data for installing the initial values of its properties and connections. The component is created, initialized and launched based on this file.

Component configuration file is a text file in JSON format containing component’s metadata and settings. During component deployment the configuration file is placed in CC directory /conf/modules and read from there during CC launch (the configuration file of CC itself is placed in the root of /conf directory).

The name of the configuration file must have <ComponentName>.config format. The name of the configuration file (without the suffix) in fact serves as a component identifier within this CC; one can use it to refer to the component from other components’ configuration files. More than one copy of the same component can be launched in this way with different identifiers and settings.

The configuration file must have the common part which is the same for all configuration files and a part relevant only for a specific component (described in the Component Configuration Settings sub-topics.

The most frequently used SmartTUBE business logic settings are located in the system.conf file.

Interaction of components via message exchange

Remote interaction of SmartTUBE server components in most cases is based on exchanging messages, which is implemented via Akka Framework (http://akka.io).

Akka implements ideas and principles of the Actor Model. In Akka, an addressee or a source of the message is Actor. It is defined by an Akka address with the following format:

akka.tcp://akka_system_name@host:port/user/actor_name, where

• akka_system_name is the name of the Akka system (application).
• host is the host where this node of Akka system is deployed.
• port is the port where this node of Akka system is “listening”.
• actor_name is the name of the addressee / source.

If a component is implemented as a node of the Akka system the configuration file sets the values of parameters describing such a node.

See details at http://akka.io/docs/

Configuration Reloading

The most frequently used SmartTUBE business logic settings are located in the system.conf file. And most of these settings are retrieved by components “on the fly” (without constant saving to Java variables). After making changes to the file, you may need to update it on the SmartTUBE nodes (data-servers and cache-servers) without restarting them. To do this you can use one of the following ways:

1. Using SmartTUBE Admin Console:
   Click the Reload configs button in the lower-right corner of the Administration > Cache Servers page.
2. Using HTTP method:

   Request the following method in any convenient way (for example, using a web browser):

   http://[sdp_host]:8089/api/admin/reloadConfigAllNodes

3. Using local console (updates the configuration only on the current node):
   1. If the SmartTUBE is running as a daemon, you can use the ccadmin utility:
      

# usage: java jar ccadmin.jar -h<host> -p<port> -c<command> -t<timeoutSec> java -jar ccadmin.jar -hlocalhost -p4440 -creloadConfigOneNode -t20

2. If the SmartTUBE is running as a command line, use the console in/out:

… Input ‘quit’ for exit … reloadConfigOneNode

SmartSDPCompcontainer Components Container

Purpose

Components Container (CC) of SmartTUBE server is designed for:

• Dynamic uploading and downloading of server components.
• Providing interaction of server components by establishing inter-component connections.

After loading and connection the components can interact with each other via program interfaces provided by them. CC also provides components with access to services of its level via program interfaces.

CC can be controlled with ccadmin utility, see the Control through ccadmin utility section.

The following terms are used below:

• Container-Install-Directory – directory for installing CC.

• Component-Install-Directory – directory for installing the component.

Use

CC is a JAR file launched with the command:

java -jar smartsdp-comp-cont.jar

Configuration file

container.conf

The file is located in the root of Container-Install-Directory/conf directory.

The configuration file reference is provided in the Components Container section.

Initialization and operation

Configuration files of all components designed for deployment under the control of this Components Container (CC) must be located in Container-Install-Directory/conf/modules directory. The composition of components that are going to operate under control of this CC is in fact determined by configuration files found in this directory.

JAR file of each component must be placed in Component-Install-Directory/bin directory.

JAR files of external libraries the component is dependent on must be placed in the Component-Install-Directory/lib library.

During the launch CC:

1. Reads configuration files of components in sequence from the Container-Install-Directory/conf/modules directory.
2. Analyzes each file.
3. Based on the acquired data, creates the structure of component meta-data, the list of features and links.
4. Checks the presence of the component’s JAR file in the Component-Install-Directory/bin directory specified in the configuration file of the component and JAR files of external libraries the component is dependent on in the Component-Install-Directory/lib directory.
5. If all checks have been successful, component metadata is included in the list.
6. The list is sorted by value of loadOnStartup components field.
7. Components are created, initialized (values of requested features and connections are installed) and launched in sequence, according to the list. Initialization is performed according to the data from the configuration file of each component.
8. If component launch was successful it is included in the list of launched components.

The link (for setting up connection between components) may be installed only on the already launched component. That is why it is required to set the value of the component’s loadOnStartup feature where the link is created so that it is greater than the value of this feature of the component referenced in the link.

After launching all components CC goes to command waiting cycle. Commands can be given via command line.

Control through commands via command line

CC recognizes the following commands:

run config-file-name-without-ext

run command launches the component whose configuration file’s name is reflected in the command parameter. At this moment the configuration file, component’s JAR file and JAR files of external libraries the component is dependent on must be located in the respective directories (see above).

stop launched-component-name

stop command stops the component whose name is reflected in the command parameter. Important: links installed on this component become invalid; CC does not track this.

list (ls)

list command displays the list of launched components in the console, specifying for each of them the name of the component, JAR file, main class and list of components referencing it.

Example of output:

1) Redirector:   JAR: SmartRedirector.jar, MAIN CLASS: smartlabs.redirector.main.SmartRedirector,      2) ContentDBManager:   JAR: SmartContentDBManager.jar, MAIN CLASS: smartlabs.contentdbmanager.main.SmartContentDBManager,             REF: Redirector by prop ‘contentDBManager’       …

quit (q)

quit command launches the process of stopping CC: each launched component is sent a quit signal after which CC stops.

Control through ccadmin utility

Purpose

This utility is designed to control the Components Container (CC) through commands received by CC via TCP/IP.

Usage

The utility is provided as a JAR file and launched by the command:

java -jar ccadmin.jar -h<host> -p<port> -c<command> -t<timeout>, where:

• host is the IP address of the host where CC is launched (by default localhost).
• port is the TCP/IP port where CC receives commands via TCP/IP.
• command are commands received by CC. Possible commands:
  • q | quit – stopping CC.
  • ls | list – recording the list of launched components into the logbook (level of record itemization must be INFO or higher).
  • run:<Component> – launching component with the name of “Component” (the name of component’s configuration file is used as a name).
  • stop:<Component> – stopping component with the name of “Component” (the name of component’s configuration file is used as a name).
  • timeout – CC response waiting time (by default 30 seconds). Timeout is registered when the time runs out.

If the command is executed successfully, ccadmin returns Exit Code equal to 0. Otherwise ccadmin returns:

• 1 – if timeout of waiting for a response was exceeded,
• 2 and more – if another error occurred when running the program.

SmartSDPDataModelCore Component

Purpose

This component defines the business model for controlling entities and services with SmartSDPDataServer component. Entities of SmartTUBE server are entities in terms of JPA (Java Persistence API).

Deployment

The component is essentially an sdp-datamodel-core.jar JAR file placed in the Components Container (CC) in its modules directory.

Usage

The services of this component are not used by other components of the SmartTUBE server.

Dependencies

This component has no dependencies on the services of other components of the SmartTUBE server.

Configuration File

data-model-core.conf

See more details on components’ configuration files in the Operation and Interaction of Components section.

The configuration file reference is provided in the Data Model Core section.

SmartSDPDataServer Component

Purpose

This component (Java HttpServlet) performs the functions of JSON RPC (Remote Procedure Call) server for handling entities and services of SmartTUBE server.

The server makes it possible to:

1. Identify and authorize the user.
2. Request meta-data of server objects (entities and services).
3. Execute pre-defined (implemented by the server) methods of handling entities (create, update, delete, list, find, count, page).
4. Perform additional (implemented “manually”) methods of entities and services.

Implemented Interfaces

The component provides integration with IPTV/OTT end-user devices according to the SmartTUBE End-User Device API.

Usage

The services of this component are not used by other components of the SmartTUBE server.

Dependencies

This component has no dependencies on the services of other components of the SmartTUBE server.

Configuration File

data-server.conf

See more details on components’ configuration files in the Operation and Interaction of Components section.

The configuration file reference is provided in the SmartTUBE JSON Data Server section.

SmartSDPCacheServer Component

Purpose

This component performs the functions of a server providing access to data and services via API.

Deployment

The component is essentially an sdp-cache-server.jar JAR file placed in the Components Container (CC) in its modules directory.

Implemented Interfaces

The component provides integration with IPTV/OTT end-user devices according to the SmartTUBE End-User Device API.

Usage

The services of this component are not used by other components of the SmartTUBE server.

Dependencies

This component has no dependencies on the services of other components of the SmartTUBE server.

Configuration File

cache-server.conf

See more details on components’ configuration files in the Operation and Interaction of Components section.

The configuration file reference is provided in the Cache Server section.

SmartSDPReport Component

Purpose

This component performs the functions designed for receiving reports.

Implementation

The library is developed in Java, version 8.

Deployment

The component is essentially an sdp-report.jar JAR file placed in the Components Container (CC) in its modules directory.

Usage

The services of this component are not used by other components of the SmartTUBE server.

Dependencies

This component has dependencies on the SmartSDPDataServer services.

Configuration File

report.conf

See more details on components’ configuration files in the Operation and Interaction of Components chapter.

The configuration file reference is provided in the Reporting Module subsection.