SiteWhere is the Open Platform for the Internet of Things. It allows
you to manage a large number of devices, communicate with them over
many transports and protocols, persist device data in big data storage,
and interact with the data via REST services. SiteWhere also provides
a comprehensive framework for integrating device data with other
systems and performing analytics on the data. The system is designed
to scale gracefully to any number of devices and is easily extended
to include new types of devices and methods of communication.
This charm deploys SiteWhere and allows many
reltionships to be configured such as:
In the near future, connection to an HBase cluster will also be supported.
The SiteWhere charm allows for the following options:
# Deploy the charms
juju deploy cs:~sitewhere/trusty/sitewhere sitewhere
juju deploy cs:~tasdomas/trusty/mosquitto
juju deploy mongodb
# Add relationships
juju add-relation sitewhere mongodb
juju add-relation sitewhere mosquitto
# Use an externally specified configuration
juju set sitewhere config-url=https://goo.gl/wqU7Ep
SiteWhere is intended to scale gracefully from a single node to hundreds of nodes that process
device event data in parallel. In a scale-out scenario, there are generally one or more
processing groups that consist of frontend nodes that are decoding device events
and processor nodes that store and process the events. This is accomplished using
SiteWhere's built-in support for Hazelcast to allow the processing to be partitioned.
All nodes are deployed using the same charm, only differing in the remote configuration file
that controls which components SiteWhere uses for processing. Frontend nodes are configured to
allow data in one of many protocols and formats
to be pulled into the system, converting them into a common format, then forwarding via a Hazelccast
queue to the processor nodes. The processor nodes are configured to read from the Hazelcast
queue, store events in a big data persistence store, then perform the configued processing steps.
Many processing options are avabilable including complex event processing, forwarding to
Apache Solr for indexing, processing via ESBs such as MuleSoft's
AnyPoint platform, or handing off to
any of the other systems integrated with SiteWhere. The processor nodes pull from the Hazelcast
queue in round-robin fashion, allowing highly parallelized processing.
Below is an example of a frontend node configuration file:
Frontend Node Configuration Example
Below is an example of a processing node configuration file:
Processing Node Configuration Example
Note that the frontend node forwards inbound events to the Hazecast queue and the processing node
listens on the queue to receive events to process.
There are some gotchas that can come in to play when processing is disbursed over many
processing nodes. When customizing configurations, it is important to note that the ourbound
processing chain for a single node only interacts with the events processed on that node. In
some cases this can lead to undesired results. For instance, in complex event processing
using Siddhi, the processor examines a live stream of events to look for patterns. When
events are disbursed across many nodes, the patterns are no longer detected. If complex event
processing is desired, the events from all processing nodes should be forwarded to either an
external Siddhi instance, or a single node that is dedicated to complex event processing.