The eyeUNIFYcore (“core”) plays a major role in the eyeUNIFY infrastructure. It is the central unit when it comes to communication between the different modules or other devices. Important data is stored persistently in the core. By leveraging the features of a Java EE 7 server, the core gains all the benefits that come with it. That includes database abstraction (use whatever database you want), incorporate a user directory like LDAP for user authentication, or secure your network traffic with TLS/SSL.
The eyeUNIFYcore implements several service interfaces that are accessible via SOAP:
- Core interface
- Events interface
- Deployment interface
- Device interface
Additionally, it defines, but does not implement, these interfaces that should be implemented by other modules:
- EventsConsumer interface
- Executor interface
The eyeUNIFYcore module comes as an enterprise archive (“eyeUNIFYcore.ear”).
Each device must implement this interface. By doing so, all modules or devices can identify each other with the information exposed through the device service. This also enables the core to automatically attach and install devices.
Attached modules can be controlled through the core service. All functions of the core service operate on a consistent abstract data model which defines a small set of different types of entities: Sources (comprising any number of channels), sinks and streams. Sources (actually its channels) describe some type of data source. Sinks describe instances that can somehow process the data from these sources. Streams link channels and sinks together. Each stream represent a channel currently being processed by a sink.
Some sinks are tightly coupled with other modules (e.g. an eyeUNIFYexec instance mapped to a sink entity) and others are completely virtual. But even though they are technically different, all sinks are handled in a consistent way. From a client’s point of view, a single physical video wall controller is used in the same way as a virtual video wall comprising many single displays, each driven by a small independent processing unit.
There are special channels as well. For example, an RTSP-channel (Real-Time Streaming Protocol) holds all necessary data to establish a connection to an RTSP network camera. Other available channel types are VNC- or capture input-channels (if you are running one of our video wall controllers)
The deployment service provides functionality to attach compatible devices to the eyeUNIFYcore. Compatible devices must at least implement the device interface. The device service exposes the data needed to automatically deploy the device. That means the device’s capabilities/services are mapped to the corresponding entities and become ready to use in an instant.
In a multi user system all relevant changes must be propagated to its users to create a consistent experience for all of them. To provide the best performance possible (in terms of latency and network usage) the events service sends push notifications about changes to its subscribers. No polling needed. To subscribe to the events service the subscriber must implement the “EventsConsumer” interface first.
To be able to receive events from the events service a subscriber needs to implement the “EventsConsumer” interface. The single “notify” operation of this interface will be called whenever a change happened in the system (e.g. when a window was resized/moved or when a new channel was created).
The executor interface describes a service for displaying channels on physical displays. For a description of this service see the eyeUNIFYexec documentation.