blob: 81326be59678015fddbe9b53d914418fb4957b33 [file] [log] [blame]
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Concepts on Eclipse Hono&amp;trade;</title>
<link>https://www.eclipse.org/hono/docs/concepts/</link>
<description>Recent content in Concepts on Eclipse Hono&amp;trade;</description>
<generator>Hugo -- gohugo.io</generator>
<language>en-us</language><atom:link href="https://www.eclipse.org/hono/docs/concepts/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>Device Identity</title>
<link>https://www.eclipse.org/hono/docs/concepts/device-identity/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://www.eclipse.org/hono/docs/concepts/device-identity/</guid>
<description>&lt;p&gt;This page describes how devices are represented and identified throughout Hono and its APIs.&lt;/p&gt;</description>
</item>
<item>
<title>Multi-Tenancy</title>
<link>https://www.eclipse.org/hono/docs/concepts/tenancy/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://www.eclipse.org/hono/docs/concepts/tenancy/</guid>
<description>Hono is designed to structure the set of all internally managed data and data streams into strictly isolated subsets. This includes the registration data and credentials of devices, internal users that are used for authentication, and the Business Applications that are part of such subsets as well.
This way of strict isolation is generally known as multi-tenancy, where a tenant is the term for such a subset. Such an isolation is essential for enabling a scalable distributed architecture to handle independent subsets as if each subset had its own installation (which would be much harder to maintain and would not benefit from runtime cost sharing).</description>
</item>
<item>
<title>Device Provisioning</title>
<link>https://www.eclipse.org/hono/docs/concepts/device-provisioning/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://www.eclipse.org/hono/docs/concepts/device-provisioning/</guid>
<description>This page describes how devices are provisioned in Hono, i.e. how their digital representation is generated. For each device, registration information is stored that defines a device identity. Each device belongs to exactly one tenant. Each device must have at least one set of credentials that are used to authenticate to Hono.
To get an understanding of what is meant by the terms tenant, device registration and credentials, it is recommended to read the Device Identity page first.</description>
</item>
<item>
<title>Connecting Devices</title>
<link>https://www.eclipse.org/hono/docs/concepts/connecting-devices/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://www.eclipse.org/hono/docs/concepts/connecting-devices/</guid>
<description>One of the most important features of Eclipse Hono™ is to abstract away the specific communication protocols used by devices. This page describes the different ways of how devices can be connected to Hono.
Before a device can connect to Hono and upload data or receive commands from downstream applications, it needs to be provisioned to the system. As part of device provisioning, the device is associated with the tenant that it belongs to and gets assigned a logical identifier which is unique within the tenant.</description>
</item>
<item>
<title>Device Notifications</title>
<link>https://www.eclipse.org/hono/docs/concepts/device-notifications/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://www.eclipse.org/hono/docs/concepts/device-notifications/</guid>
<description>&lt;p&gt;&lt;em&gt;Business Applications&lt;/em&gt; need to know when an attempt to send a command to device is feasible, e.g. because the device is then known to be connected to a protocol adapter. &lt;em&gt;Devices&lt;/em&gt; and &lt;em&gt;Protocol Adapters&lt;/em&gt; can indicate to &lt;em&gt;Business Applications&lt;/em&gt; a device&amp;rsquo;s intent to e.g. receive commands using specific &lt;em&gt;notifications&lt;/em&gt;.&lt;/p&gt;</description>
</item>
<item>
<title>Command &amp; Control</title>
<link>https://www.eclipse.org/hono/docs/concepts/command-and-control/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://www.eclipse.org/hono/docs/concepts/command-and-control/</guid>
<description>&lt;p&gt;&lt;em&gt;Business applications&lt;/em&gt; can send commands to devices following the &lt;a href=&#34;https://www.eclipse.org/hono/docs/hono/docs/api/command-and-control/&#34;&gt;Command &amp;amp; Control API&lt;/a&gt;. This concept page describes how this API is used by applications to send commands and describes how Hono&amp;rsquo;s protocol adapters process the commands so that they reach their target device.&lt;/p&gt;</description>
</item>
<item>
<title>Resource limits</title>
<link>https://www.eclipse.org/hono/docs/concepts/resource-limits/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://www.eclipse.org/hono/docs/concepts/resource-limits/</guid>
<description>Resource limits such as the maximum number of device connections allowed per tenant or the allowed data volume of the messages over a period of time per tenant can be set in Hono.
Hono specifies an API ResourceLimitChecks that is used by the protocol adapters for the verification of the configured resource limits. A default implementation of this API is shipped with Hono. This default implementation uses the live metrics data retrieved from a Prometheus server to verify the resource-limits, if configured.</description>
</item>
<item>
<title>Connection Events</title>
<link>https://www.eclipse.org/hono/docs/concepts/connection-events/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<guid>https://www.eclipse.org/hono/docs/concepts/connection-events/</guid>
<description>Hono&amp;rsquo;s protocol adapters can use connection events to indicate the connection status of a device. In particular, an adapter can notify downstream components about a newly established connection with a device or about a device having disconnected.
The connection status of devices using stateful protocols like MQTT and AMQP can usually be determined quite easily because these protocols often require peers to explicitly open or close a connection and often also support a kind of heart beat which can be used to determine if a connection is still alive.</description>
</item>
</channel>
</rss>