blob: 1b88e6811eff8e8fa4f56d3eafbc39ea0973bf33 [file] [log] [blame]
<!DOCTYPE html>
<html lang="en-us">
<head>
<meta charset="utf-8">
<meta name="robots" content="all,follow">
<meta name="googlebot" content="index,follow,snippet,archive">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Release Notes :: Eclipse Hono&trade;</title>
<meta name="author" content="" />
<meta name="description" content="A set of micro-services for connecting millions of devices.">
<meta name="generator" content="Hugo 0.54.0" />
<link href='//fonts.googleapis.com/css?family=Roboto:400,100,100italic,300,300italic,500,700,800' rel='stylesheet' type='text/css'>
<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.8.2/css/all.css" integrity="sha384-oS3vJWv+0UjzBfQzYUhtDYW+Pj2yciDJxpsK1OYPAYjqT085Qq/1cq5FLXAZQ7Ay" crossorigin="anonymous">
<link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">
<link href="/hono/css/animate.css" rel="stylesheet">
<link href="/hono/css/style.hono.css" rel="stylesheet" id="theme-stylesheet">
<link href="/hono/css/custom.css" rel="stylesheet">
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
<script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
<![endif]-->
<link rel="apple-touch-icon" sizes="180x180" href="/hono/favicon/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="48x48" href="/hono/favicon/favicon-48x48.png">
<link rel="icon" type="image/png" sizes="32x32" href="/hono/favicon/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/hono/favicon/favicon-16x16.png">
<link rel="manifest" href="/hono/favicon/site.webmanifest">
<link rel="mask-icon" href="/hono/favicon/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/hono/favicon/favicon.ico">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="/hono/favicon/browserconfig.xml">
<meta name="theme-color" content="#ffffff">
<link href="/hono/css/owl.carousel.css" rel="stylesheet">
<link href="/hono/css/owl.theme.css" rel="stylesheet">
<link rel="alternate" href="https://www.eclipse.org/hono//index.xml" type="application/rss+xml" title="Eclipse Hono&amp;trade;">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@EclipseHono">
<meta name="twitter:title" content="Release Notes :: Eclipse Hono&amp;trade;">
<meta name="twitter:image" content="https://www.eclipse.org/hono/img/twitter_image.png">
<meta name="twitter:description" content="A set of micro-services for connecting millions of devices.">
<meta property="og:title" content="Release Notes :: Eclipse Hono&amp;trade;" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://www.eclipse.org/hono/release-notes//" />
<meta property="og:image" content="https://www.eclipse.org/hono/img/twitter_image.png" />
<link rel="stylesheet" href="https://www.eclipse.org/eclipse.org-common/themes/solstice/public/stylesheets/vendor/cookieconsent/cookieconsent.min.css">
</head>
<body>
<div id="all">
<header>
<div class="navbar-affixed-top" data-spy="affix" data-offset-top="70">
<div class="navbar navbar-default yamm" role="navigation" id="navbar">
<div class="container">
<div class="navbar-header">
<a class="navbar-brand home" href="https://www.eclipse.org/hono/">
<img src="https://www.eclipse.org/hono/img/HONO-Logo_Bild-Wort_quer-s-310x120px.svg" alt="Release Notes logo" class="logo">
<span class="sr-only">Release Notes - go to homepage</span>
</a>
<div class="navbar-buttons">
<button type="button" class="navbar-toggle btn-template-main" data-toggle="collapse" data-target="#navigation">
<span class="sr-only">Toggle Navigation</span>
<i class="fa fa-align-justify"></i>
</button>
</div>
</div>
<div class="navbar-collapse collapse" id="navigation">
<ul class="nav navbar-nav navbar-right">
<li class="dropdown">
<a href="/hono/getting-started/">Getting started</a>
</li>
<li class="dropdown">
<a href="/hono/docs">Documentation</a>
</li>
<li class="dropdown">
<a href="/hono/downloads/">Download</a>
</li>
<li class="dropdown">
<a href="/hono/sandbox/">Sandbox</a>
</li>
<li class="dropdown">
<a href="/hono/faq/">FAQ</a>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">Community <span class="caret"></span></a>
<ul class="dropdown-menu">
<li><a href="/hono/community/contributing/">Contributing</a></li>
<li><a href="/hono/community/presentations/">Resources</a></li>
<li><a href="/hono/community/get-in-touch/">Get in Touch</a></li>
<li><a href="/hono/community/road-map/">Road Map</a></li>
</ul>
</li>
</ul>
</div>
<div class="collapse clearfix" id="search">
<form class="navbar-form" role="search">
<div class="input-group">
<input type="text" class="form-control" placeholder="Search">
<span class="input-group-btn">
<button type="submit" class="btn btn-template-main"><i class="fa fa-search"></i></button>
</span>
</div>
</form>
</div>
</div>
</div>
</div>
</header>
<div id="heading-breadcrumbs">
<div class="container">
<div class="row">
<div class="col-md-12">
<h1>Release Notes</h1>
</div>
</div>
</div>
</div>
<div id="content">
<div class="container">
<div class="row">
<div class="col-md-12">
<div>
<h2 id="1-0-0-not-yet-released">1.0.0 (not yet released)</h2>
<h3 id="new-features">New Features</h3>
<ul>
<li>A tenant can now be configured with a <em>max-ttl</em> which is used as a upper boundary for default
TTL values configured for devices/tenants. Please refer to the <a href="https://www.eclipse.org/hono/docs/api/tenant#resource-limits-configuration-format
">Tenant API</a> for details.
The AMQP, HTTP, MQTT and Kura protocol adapters consider this property when setting a TTL on
downstream event messages.</li>
<li>A protocol adapter can now be configured with a timeout for idle tenants. When there has been no
communication between a protocol adapter instance and the devices of a tenant, the former one releases
allocated resources of the tenant. Currently this means that it closes AMQP links and stops reporting
metrics for this tenant. The timeout is configured with the property <code>tenantIdleTimeout</code> for a protocol
adapter. Please refer to the protocol adapter <a href="https://www.eclipse.org/hono/docs/admin-guide/
">configuration guides</a>
for details.</li>
<li>The accounting period for the <em>message limit</em> checks can now be configured as <code>monthly</code>.
In this case the data usage for a tenant is calculated from the beginning till the end of the
(Gregorian) calendar month. Refer <a href="https://www.eclipse.org/hono/docs/concepts/resource-limits/
">resource limits</a>
for more information.</li>
</ul>
<h3 id="api-changes">API Changes</h3>
<ul>
<li>The already deprecated <em>legacy metrics</em> support has been removed.</li>
</ul>
<h2 id="1-0-m7">1.0-M7</h2>
<h3 id="new-features-1">New Features</h3>
<ul>
<li>The Hono Helm chart now supports to choose if the example Device Registry, example AMQP Messaging Network
and/or the example Jaeger back end should be deployed and used with the Hono components or not.
In the latter case, the chart now also supports setting configuration properties for using an already
existing AMQP Messaging Network, Device Registry and/or Jaeger back end.</li>
<li>A data grid based implementation of the Device Connection API has been added to Hono. This implementation
can be used in production environments using a highly scalable data grid for storing device connection
information. The service can be used instead of the simple implementation provided by the example Device
Registry by means of setting a configuration property when <a href="https://www.eclipse.org/hono/docs/deployment/helm-based-deployment/#using-the-device-connection-service
">deploying using the Helm chart</a>.</li>
<li>A tenant can now be configured so that <em>all</em> OpenTracing spans created when processing messages for that
specific tenant will be recorded in the tracing backend (overriding the default sampling strategy that
might only record a certain percentage of traces). See
<a href="https://www.eclipse.org/hono/docs/admin-guide/monitoring-tracing-config/#enforcing-the-recording-of-traces-for-a-tenant
">Monitoring &amp; Tracing</a>
for more details.</li>
</ul>
<h3 id="api-changes-1">API Changes</h3>
<ul>
<li>The obsolete method variants of <code>reportTelemetry</code> in <code>org.eclipse.hono.service.metric.Metrics</code>
have been removed. The new variants of this method accept an additional parameter of type <code>TenantObject</code>.</li>
<li>The already deprecated <code>org.eclipse.hono.service.AbstractProtocolAdapterBase.getRegistrationAssertion</code>
method has been removed. The alternate variant of the <code>getRegistrationAssertion</code> method which accepts an
additional OpenTracing span parameter should be used.</li>
<li>The already deprecated <code>getRegistrationAssertion</code>, <code>getTenantConfiguration</code>, <code>sendConnectedTtdEvent</code>,
<code>sendDisconnectedTtdEvent</code> and <code>sendTtdEvent</code> methods in <code>org.eclipse.hono.service.AbstractProtocolAdapterBase</code>
have been removed. The alternate variant of these methods which accepts an additional OpenTracing span parameter
should be used.<br /></li>
</ul>
<h3 id="deprecations">Deprecations</h3>
<ul>
<li>The deprecated Kura adapter is no longer deployed by default by the Helm chart.
However, it can still be deployed by means of <a href="https://www.eclipse.org/hono/docs/deployment/helm-based-deployment/#deploying-optional-adapters
">setting a configuration property</a>.</li>
</ul>
<h2 id="1-0-m6">1.0-M6</h2>
<h3 id="new-features-2">New Features</h3>
<ul>
<li>Implementation of the new HTTP management API for tenants, devices and
credentials.</li>
<li>The health check endpoints of services can now be called securely via TLS.
Please refer to the protocol adapter <a href="https://www.eclipse.org/hono/docs/admin-guide/
">configuration guides</a>
for the new parameters available.</li>
<li>The <a href="https://www.eclipse.org/hono/docs/api/tenant/#resource-limits-configuration-format
">Tenant API</a> now optionally allows
specifying <em>minimum message size</em>. If it is specified, then the payload size of the incoming telemetry, event
and command messages are calculated in accordance with the <em>minimum message size</em> by the AMQP, HTTP and MQTT
protocol adapters and then recorded in the metrics system.
See <a href="https://www.eclipse.org/hono/docs/api/metrics/#minimum-message-size
">Metrics</a> for more details.</li>
</ul>
<h3 id="fixes-enhancements">Fixes &amp; Enhancements</h3>
<ul>
<li>The automatic reconnect handling of the <code>HonoConnection</code> implementation has been
improved and now applies an exponential back-off algorithm. The behavior can be
configured using the <code>${PREFIX}_RECONNECT_*</code> configuration variables. Please
refer to the <a href="https://www.eclipse.org/hono/docs/admin-guide/hono-client-configuration/
">Hono Client Configuration guide</a>
for details regarding these new variables.</li>
<li>The <em>message limit</em> checks is now extended to include command and control messages.
Please refer to the <a href="https://www.eclipse.org/hono/docs/concepts/resource-limits/
">resource limits</a> for details.</li>
<li>The health check server endpoint will now bind to a default port value of 8088 if no values
are set explicitly in the configuration. It is also possible to start both a secure and an insecure
server (using different ports)
Refer to the <a href="https://www.eclipse.org/hono/docs/admin-guide/monitoring-tracing-config
">Monitoring configuration guide</a>
for details.</li>
</ul>
<h3 id="api-changes-2">API Changes</h3>
<ul>
<li>With the implementation of the new HTTP management API for the device registry,
the class hierarchy for implementing device registry was significantly
refactored. This also includes the deprecation of a list of classes and tests.
Also see <a href="#device-registry-changes">Device registry changes</a> for more information.</li>
<li>The <em>complete</em> interfaces, and the <em>base</em> and <em>complete</em> implementation
classes for services got deprecated, and are planned to be removed in a future
release. Also see <a href="#device-registry-changes">Device registry changes</a> for
more information.</li>
<li>The example Device Registry that comes with Hono now implements the new
HTTP management API. Consequently, the URI endpoints for managing the content
of the registry have changed accordingly.</li>
<li>The configuration parameters for the health check endpoint were moved from
<code>hono.app</code> to <code>hono.healthCheck</code> and renamed. <code>hono.app.healthCheckPort</code> is now
<code>hono.healthCheck.insecurePort</code> and <code>hono.app.healthCheckBindAddress</code> is now
<code>hono.healthCheck.insecurePortBindAdress</code>. Please refer to the protocol adapter
<a href="https://www.eclipse.org/hono/docs/admin-guide/
">configuration guides</a> for additional
information on the new naming.</li>
</ul>
<h3 id="device-registry-changes">Device registry changes</h3>
<p>The section summarizes changes made for 1.0-M5 in the device registry.</p>
<p>During the development of Hono 1.0, we defined a new HTTP API for managing
information stored in the device registry. This API replaces the current,
provisional API, which was originally intended for tests to manipulate the file
based device registry during system tests. The new HTTP based API is intended
to replace the existing HTTP API, as well as the management part of the AMQP
based API.</p>
<p>The first major change is, that all the <em>complete</em> classes got deprecated. As
they are based on the services for the protocol adapters. And those services
are no longer considered to be used for managing information. The replacement
for those classes are the new management APIs.</p>
<p>Each of the three APIs got a companion API for <em>management</em>, which are located
in the <code>org.eclipse.hono.service.management</code> base package.</p>
<p>The class hierarchy was decoupled in order to make it easier to implement those
services. The new design only requires to implement a service, which is not
based on any other interface. And while your concrete implement still can
implement the <code>Verticle</code> interface, this is no longer a requirement.</p>
<p>Also the <em>base</em> classes got deprecated. Instead of inheriting the common
functionality, to bind to the <em>event bus</em>, that functionality got moved into new
<em>event bus adapter</em> classes, which take the reference of a service, and bind
this service to the <em>event bus</em> instead of using inheritance. Those change
make it possible to re-use much of the functionality, but do not impose the
requirement to inherit from either the <em>complete</em> or <em>base</em> classes. And
this finally allows your service implementation to be extend your specific
base class, and re-use common Hono functionality at the same time. This allows
service implementations to implement both the standard API, as well as the
management API in the same class. As Java does not allow inheritance
from multiple classes, this was not possible before.</p>
<p>The new default file based device registry, was modified to use the new class
hierarchy and support the new management model.</p>
<p>The device registry, which was provided in 1.0-M4 and before, is still part of
the source tree, but was moved to <code>services/device-registry-legacy</code>. It is
there to show the compatibility with the older class hierarchy, using the,
now deprecated, <em>base</em> and <em>complete</em> classes. Newer implementations should not
be build on this model.</p>
<p>Clients of the <em>base</em> variants of the services, like the protocol adapters,
do not need to make any changes.</p>
<p>Implementations of the device registry services, using the existing <em>base</em> and
<em>complete</em> can re-use that model, but are encouraged to migrate to the new model
as soon as possible, as the legacy model is planned to be removed. The only
impacting change is that the service interfaces no longer extend from
<code>Verticle</code> directly, but that has been moved to the <em>base</em> implementation.</p>
<p>Implementations of the services for protocol adapters (the non-management API),
can switch to the new class hierarchy by dropping inheritance to the <em>base</em>
class, and starting up a new instance of the corresponding <em>event bus adapter</em>,
providing a reference to the service. For the <code>RegistrationService</code> it is also
possible to inherit common functionality from <code>AbstractRegistrationService</code>.</p>
<p>Implementations of the services for management need to simply inherit from the
new management interfaces, and set up the <em>event bus adapters</em> the same way.</p>
<p>The module <code>device-registry-legacy</code> as well as all classes and interfaces,
which got deprecated, are planned to be dropped in 1.1.</p>
<h2 id="1-0-m5">1.0-M5</h2>
<h3 id="new-features-3">New Features</h3>
<ul>
<li>Hono&rsquo;s protocol adapters and the other components now support using ECC based server certificates.
The protocol adapters also support authenticating devices which present an ECC based client certificate.
The example configuration now uses ECC based certificates by default.</li>
<li>Hono now specifies a <a href="https://www.eclipse.org/hono/docs/api/device-connection/
">Device Connection API</a> and
contains an exemplary implementation of this API included in the device registry component. The purpose of the API is
to be able to set and retrieve information about the connections from devices or gateways to the protocol adapters.</li>
<li>This version implements the new HTTP management API for tenants, devices, and credentials.</li>
</ul>
<h3 id="fixes-enhancements-1">Fixes &amp; Enhancements</h3>
<ul>
<li>The Hono Sandbox&rsquo;s protocol adapters support using the gateway mode again.</li>
<li>The <a href="/hono/getting-started/">Getting Started</a> guide has been rewritten
to use the <a href="/hono/sandbox/">Hono Sandbox</a> or a local Minikube cluster
instead of Docker Swarm.</li>
<li>The MQTT adapter now closes the network connection to device on publish failures.</li>
</ul>
<h3 id="api-changes-3">API Changes</h3>
<ul>
<li>The optional methods of the <a href="https://www.eclipse.org/hono/docs/api/tenant/
">Tenant API</a> have been
removed. Implementations of the Tenant API are encouraged to expose the <em>tenants</em> endpoint defined by
<a href="https://www.eclipse.org/hono/docs/api/management
">Hono&rsquo;s HTTP based management API</a> instead.
Several of the formerly mandatory to include properties of the request and response messages have
been made optional or removed altogether. Existing clients should not be affected by these changes, though.</li>
<li>The optional methods of the
<a href="https://www.eclipse.org/hono/docs/api/device-registration/
">Device Registration API</a> have been
removed. Implementations of the Device Registration API are encouraged to expose the <em>devices</em> endpoint defined by
<a href="https://www.eclipse.org/hono/docs/api/management
">Hono&rsquo;s HTTP based management API</a> instead.
Several of the formerly mandatory to include properties of the request and response messages have
been made optional or removed altogether. Existing clients should not be affected by these changes, though.</li>
<li>The response message format of the <em>assert Device Registration</em> operation of the Device Registration API
has been changed, replacing the optional <code>gw-supported</code> boolean field with an optional <code>via</code> field.
The value of this field contains the list of gateway that may act on behalf of the device on which
the operation is invoked.</li>
<li>The methods for invoking the optional operations of the Device Registration API have been removed
from <code>org.eclipse.hono.client.RegistrationClient</code> and <code>org.eclipse.hono.client.impl.RegistrationClientImpl</code>.</li>
<li>The optional methods of the <a href="https://www.eclipse.org/hono/docs/api/credentials/
">Credentials API</a>
have been removed. Implementations of the Credentials API are encouraged to expose the <em>credentials</em> endpoint defined
by <a href="https://www.eclipse.org/hono/docs/api/management
">Hono&rsquo;s HTTP based management API</a> instead.
Several of the formerly mandatory to include properties of the request and response messages have
been made optional or removed altogether. Existing clients should not be affected by these changes, though.</li>
<li>The <code>control</code> prefix in the northbound and southbound Command &amp; Control endpoints has been renamed to <code>command</code>.
The endpoint names with the <code>control</code> prefix are still supported but deprecated. The northbound endpoint for
<em>business applications</em> to receive command responses has the <code>command_response</code> prefix now. The old <code>control</code> prefix
for the receiver address is also still supported but deprecated.</li>
<li>The <code>deviceId</code> parameter of the <code>getOrCreateCommandClient</code> and <code>getOrCreateAsyncCommandClient</code> methods of the
<code>org.eclipse.hono.client.ApplicationClientFactory</code> interface has been removed.
This means that a <code>CommandClient</code> or <code>AsyncCommandClient</code> instance can be used to send commands to arbitrary
devices of a tenant now. Accordingly, the <code>CommandClient.sendCommand</code> and <code>AsyncCommandClient.sendAsyncCommand</code>
methods now require an additional <code>deviceId</code> parameter.</li>
<li>The deprecated methods of <code>org.eclipse.hono.client.HonoConnection</code> have been removed.</li>
</ul>
<h2 id="1-0-m4">1.0-M4</h2>
<h3 id="new-features-4">New Features</h3>
<ul>
<li>Default properties can now also be set at the tenant level, affecting all devices
belonging to the tenant. Please refer to the
<a href="https://www.eclipse.org/hono/docs/user-guide/
">protocol adapter user guides</a> for details.</li>
<li><code>CredentialsClientImpl</code> now supports caching of response data received from a Credentials service based on
<em>cache directives</em>. The protocol adapters are now equipped to cache the response from the Credentials Service.
The protocol adapters support configuration variables to set the default cache timeout, the minimum
and maximum cache sizes for this service.</li>
<li>The example device registry&rsquo;s Credentials service implementation now includes a <em>cache directive</em>
in its response to the <em>get Credentials</em> operation which allows clients to cache credentials of
type <em>hashed-password</em> and <em>x509-cert</em> for a configurable amount of time. Please refer to the
<a href="https://www.eclipse.org/hono/docs/admin-guide/device-registry-config/
">Device Registry Admin Guide</a>
for details regarding the configuration properties to use.</li>
<li>There is now an official specification of an HTTP API for managing the content of a device registry.
The <a href="https://www.eclipse.org/hono/docs/api/management
">HTTP Management API</a> is defined using by
means of OpenAPI v3. Note, that the API is not yet implemented by the example device registry that comes with Hono.</li>
<li>The Command &amp; Control feature now supports gateway agnostic addressing of devices. This means that applications are
able to send commands to devices without knowing the particular gateway they may be connected to.</li>
<li>The concept and implementation of <em>message limit</em> have been added. The protocol adapters can be now
enabled to verify this <em>message limit</em> for each tenant before accepting any telemetry/event messages.
Please refer to the <a href="https://www.eclipse.org/hono/docs/concepts/resource-limits/
">resource limits</a> for details.</li>
<li>A basic Sigfox protocol adapter, for use with the Sigfox backend. Please read
the <a href="https://www.eclipse.org/hono/docs/user-guide/sigfox-adapter/
">Sigfox protocol adapter</a>
documentation to learn more about pre-requisites and limitations.</li>
</ul>
<h3 id="fixes-enhancements-2">Fixes &amp; Enhancements</h3>
<ul>
<li>vert.x has been updated to version 3.7.0.</li>
</ul>
<h3 id="api-changes-4">API Changes</h3>
<ul>
<li>The <code>org.eclipse.hono.util.RegistrationConstants.FIELD_DEFAULTS</code> constant
has been renamed to <code>org.eclipse.hono.util.RegistrationConstants.FIELD_PAYLOAD_DEFAULTS</code>.</li>
<li>The <code>org.eclipse.hono.service.AbstractProtocolAdapterBase.newMessage</code> and
<code>org.eclipse.hono.service.AbstractProtocolAdapterBase.addProperties</code> methods have
been changed to accept an additional parameter of type <code>TenantObject</code> which may contain default
properties defined for the tenant to be included in downstream messages.</li>
<li>The <em>get Registration Information</em> operation of the Device Registration API is not optional anymore,
it is now mandatory to implement. For device registry implementations based on the
<code>CompleteRegistrationService</code> interface, there is no change needed as the operation is already
defined there.</li>
<li>The response message of the <em>assert Device Registration</em> operation does not contain an assertion
token anymore. The <code>org.eclipse.hono.service.registration.BaseRegistrationService</code> class
has been adapted accordingly.</li>
<li>The already deprecated <code>org.eclipse.hono.client.CommandConsumerFactory.closeCommandConsumer</code>
method has been removed.</li>
<li>The response message format of the <em>assert Device Registration</em> operation of the Device Registration API
has been changed to include an optional <code>gw-supported</code> boolean field. The value of this field refers to
whether the device on which the operation is invoked allows one or more gateways to act on its behalf.</li>
<li>The AMQP sender link address to be used by <em>business applications</em> to send commands to devices has been
changed from <code>control/${tenant_id}/${device_id}</code> to <code>control/${tenant_id}</code> with command messages requiring
the <code>to</code> property to be set to <code>control/${tenant_id}/${device_id}</code>. Using <code>control/${tenant_id}/${device_id}</code>
as sender link address is still possible but gateway agnostic addressing of devices is not supported for
such command messages.</li>
</ul>
<h3 id="deprecations-1">Deprecations</h3>
<ul>
<li>Instructions for script based deployment to Kubernetes have been removed from the deployment guide.
Using Helm is now the only supported way of deploying Hono to Kubernetes.</li>
</ul>
<h2 id="1-0-m3">1.0-M3</h2>
<h3 id="fixes-enhancements-3">Fixes &amp; Enhancements</h3>
<ul>
<li>The protocol adapters add tracing information about invocations of the Device Registry
services again.</li>
<li>The example deployment now uses Qpid Dispatch Router 1.6.0.</li>
</ul>
<h2 id="1-0-m2">1.0-M2</h2>
<h3 id="new-features-5">New Features</h3>
<ul>
<li>A new <em>experimental</em> LoRa protocol adapter has been added which (so far) supports the reception
of telemetry data and events from devices connected to LoRa network providers and/or
LoRa gateways. Note that this adapter is <em>not</em> considered production ready yet.
Any help in improving and enhancing the adapter is more than welcome.</li>
<li>The concept and implementation of <em>resource limits</em> have been added. Now a connection limit to define
the maximum number of device connections to be allowed per tenant can be configured. The MQTT and AMQP
adapters can be enabled to verify this connection limit before accepting any new connections. Please
refer to the <a href="https://www.eclipse.org/hono/docs/concepts/resource-limits/
">resource limits</a> for details.</li>
</ul>
<h3 id="fixes-enhancements-4">Fixes &amp; Enhancements</h3>
<ul>
<li>The base classes for implementing the AMQP and HTTP endpoints for the Credentials, Tenant
and Device Registration APIs now create an OpenTracing Span for tracking the
processing of requests at a high level.</li>
<li>The <code>hono-client</code> and <code>hono-core</code> artifacts use Java 8 level again so that they
can be used in applications using Java 8.</li>
<li>The protocol adapters now always specify values for the <em>ttd</em> and <em>qos</em> tags when
reporting telemetry messages using meter name <em>hono.messages.received</em>. This fixes
an issue when using the Prometheus back end where the HTTP adapter failed to report
messages that contained a TTD value and others that didn&rsquo;t.</li>
<li>The Helm based deployment of the device registry has been fixed by adding the secret
and deployment entries for the <code>device-identities.json</code>.</li>
<li>Before uploading command responses, the MQTT and AMQP adapters now check whether the device is
registered and also the adapter is enabled for the tenant.</li>
</ul>
<h3 id="api-changes-5">API Changes</h3>
<ul>
<li>The <code>hono-client</code> module has undergone several major and incompatible changes. The most
important change affects the <code>HonoClient</code> interface which no longer serves as a factory
for the arbitrary clients to the Hono service endpoints.
It has been renamed to <code>HonoConnection</code> and now only represents the underlying
AMQP connection to a peer and provides methods for managing the connection state
and registering listeners for arbitrary life-cycle events of the connection.
In addition to this, several factory interfaces have been added which can be used
to create specific clients to Hono&rsquo;s arbitrary services. All of the former <code>HonoClient</code>
interface&rsquo;s factory methods have been distributed accordingly to:
<ul>
<li><code>org.eclipse.hono.client.ApplicationClientFactory</code> for creating clients to
Hono&rsquo;s north bound Telemetry, Event and Command &amp; Control API.</li>
<li><code>org.eclipse.hono.client.DownstreamSenderFactory</code> for creating clients to
Hono&rsquo;s south bound Telemetry and Event APIs.</li>
<li><code>org.eclipse.hono.client.CommandConsumerFactory</code> for creating clients to
Hono&rsquo;s south bound Command &amp; Control API.</li>
<li><code>org.eclipse.hono.client.TenantClientFactory</code> for creating clients to
Hono&rsquo;s Tenant API.</li>
<li><code>org.eclipse.hono.client.RegistrationClientFactory</code> for creating clients to
Hono&rsquo;s Device Registration API.</li>
<li><code>org.eclipse.hono.client.CredentialsClientFactory</code> for creating clients to
Hono&rsquo;s Credentials API.</li>
</ul></li>
<li>In this context the <code>org.eclipse.hono.client.MessageSender</code> interface has been changed as follows:
<ul>
<li>The <em>send</em> methods have been changed to no longer accept a <em>registration assertion token</em>
which became obsolete with the removal of the <em>Hono Messaging</em> component.</li>
<li>The <em>isRegistrationAssertionRequired</em> method has been removed from the interface.</li>
<li>All <em>send</em> method variants which accept specific message parameters have been moved into
the new <code>org.eclipse.hono.client.DownstreamSender</code> interface which extends the existing
<code>MessageSender</code>.</li>
</ul></li>
<li>Several changes have been made to the <code>org.eclipse.hono.service.AbstractProtocolAdapterBase</code>
class:
<ul>
<li>The <em>newMessage</em> and <em>addProperties</em> methods no longer require a boolean parameter indicating
whether to include the assertion token in the message being created/amended.
Custom protocol adapters should simply omit the corresponding parameter.</li>
<li>The base class now uses <code>org.eclipse.hono.client.CommandConsumerFactory</code> instead of
<code>org.eclipse.hono.client.CommandConnection</code> for creating
<code>org.eclipse.hono.client.CommandConsumer</code> instances.
The <em>setCommandConnection</em> and <em>getCommandConnection</em> methods have been
renamed to <em>setCommandConsumerFactory</em> and <em>getCommandConsumerFactory</em>
correspondingly.</li>
<li>The base class now uses <code>org.eclipse.hono.client.TenantClientFactory</code> instead of
<code>org.eclipse.hono.client.HonoClient</code> for creating <code>org.eclipse.hono.client.TenantClient</code>
instances.
The <em>setTenantServiceClient</em> and <em>getTenantServiceClient</em> methods have been
renamed to <em>setTenantClientFactory</em> and <em>getTenantClientFactory</em> correspondingly.</li>
<li>The base class now uses <code>org.eclipse.hono.client.RegistrationClientFactory</code> instead of
<code>org.eclipse.hono.client.HonoClient</code> for creating
<code>org.eclipse.hono.client.RegistrationClient</code> instances.
The <em>setRegistrationServiceClient</em> and <em>getRegistrationServiceClient</em> methods have been
renamed to <em>setRegistrationClientFactory</em> and <em>getRegistrationClientFactory</em> correspondingly.</li>
<li>The base class now uses <code>org.eclipse.hono.client.CredentialsClientFactory</code> instead of
<code>org.eclipse.hono.client.HonoClient</code> for creating
<code>org.eclipse.hono.client.CredentialsClient</code> instances.
The <em>setCredentialsServiceClient</em> and <em>getCredentialsServiceClient</em> methods have been
renamed to <em>setCredentialsClientFactory</em> and <em>getCredentialsClientFactory</em> correspondingly.</li>
<li>The base class now uses <code>org.eclipse.hono.client.DownstreamSendertFactory</code> instead of
<code>org.eclipse.hono.client.HonoClient</code> for creating
<code>org.eclipse.hono.client.DownstreamSender</code> instances.
The <em>setHonoMessagingClient</em> and <em>getHonoMessagingClient</em> methods have been
renamed to <em>setDownstreamSenderFactory</em> and <em>getDownstreamSenderFactory</em> correspondingly.</li>
</ul></li>
<li>The <code>org.eclipse.hono.service.auth.device.UsernamePasswordAuthProvider</code> and the
<code>org.eclipse.hono.service.auth.device.X509AuthProvider</code> now accept a
<code>org.eclipse.hono.client.CredentialsClientFactory</code> instead of a
<code>org.eclipse.hono.client.HonoClient</code> in their constructors.</li>
<li>The <code>org.eclipse.hono.adapter.http.HonoBasicAuthHandler</code> and
<code>org.eclipse.hono.adapter.http.X509AuthHandler</code> classes have been moved to
package <code>org.eclipse.hono.service.http</code> in the <em>service-base</em> module for
consistency reasons as all other reusable classes for implementing HTTP services/
adapters are located in that package already.</li>
<li>The <code>org.eclipse.hono.client.HonoClient</code> class has been renamed to
<code>org.eclipse.hono.client.HonoConnection</code> to better reflect its sole responsibility
for establishing (and maintaining) the connection to a Hono service endpoint.</li>
</ul>
<h3 id="deprecations-2">Deprecations</h3>
<ul>
<li>The optional operations defined by the Tenant, Device Registration and Credentials API
have been deprecated. They will be removed from Hono 1.0 altogether.
A new HTTP based API will be defined instead which can then be used to <em>manage</em> the content
of a device registry.</li>
<li><code>org.eclipse.hono.client.HonoConnection</code>&rsquo;s <em>connect</em> method variants accepting
a disconnect handler have been deprecated and will be removed in Hono 1.0.
Client code should use one of the other <em>connect</em> methods instead and register a
<code>org.eclipse.hono.client.DisconnectListener</code> and/or a
<code>org.eclipse.hono.client.ReconnectListener</code> to get notified about life-cycle
events of the underlying AMQP connection.</li>
</ul>
<h2 id="1-0-m1">1.0-M1</h2>
<h3 id="new-features-6">New Features</h3>
<ul>
<li>The AMQP adapter now supports limiting the number of concurrent connections in order
to prevent Out of Memory errors. Please refer to
<a href="https://www.eclipse.org/hono/docs/admin-guide/amqp-adapter-config/
">AMQP Adapter Configuration</a> for details.</li>
<li>The <code>org.eclipse.hono.client.AsyncCommandClient</code> has been added to support the sending of
commands to devices and the receiving of responses in an asynchronous way. This can be used
to decouple the sender and receiver from each other.</li>
<li>The <code>org.eclipse.hono.service.tenant.CompleteBaseTenantService</code> class now rejects malformed
encodings of public keys/certificates included in a request to add a trust anchor to a tenant.</li>
</ul>
<h3 id="deprecations-3">Deprecations</h3>
<ul>
<li>The <code>HonoClient.closeCommandConsumer()</code> method will be removed in Hono 1.0.
The <code>CommandConsumer.close()</code> method should be used instead.</li>
</ul>
<h2 id="0-9">0.9</h2>
<h3 id="new-features-7">New Features</h3>
<ul>
<li>The MQTT adapter now supports commands to be published using QoS 1. Please refer to
<a href="https://www.eclipse.org/hono/docs/user-guide/mqtt-adapter/
">MQTT adapter User Guide</a> for details.</li>
<li>The MQTT adapter now supports limiting the number of concurrent connections in order
to prevent running out of resources. Please refer to
<a href="https://www.eclipse.org/hono/docs/admin-guide/mqtt-adapter-config/
">MQTT Adapter Configuration</a> for details.</li>
<li>The new <em>Helm deployment</em> for Kubernetes has been added. Please refer to
<a href="https://www.eclipse.org/hono/docs/deployment/helm-based-deployment/
">Helm based deployment guide</a> for details.</li>
</ul>
<h3 id="fixes-enhancements-5">Fixes &amp; Enhancements</h3>
<ul>
<li><code>org.eclipse.hono.util.RequestResponseResult</code> now provides access to AMQP application-properties conveyed in the
response message.</li>
<li>The <code>org.eclipse.hono.service.registration.BaseRegistrationService</code> class now supports authorization of gateways
(acting on behalf of a device) against a list of gateway identifiers instead of a single identifier only. For that purpose
the <code>via</code> property of the device&rsquo;s registration information may contain either a single string or a JSON array containing
multiple strings. Based on this, a device can now be configured to connect via arbitrary gateways instead of just a single
one.</li>
</ul>
<h3 id="api-changes-6">API Changes</h3>
<ul>
<li>The layout and structure of the metrics reported by Hono have been changed substantially. Many of the existing meters and tags
have been changed or replaced in order to provide a more consistent set of metrics and increase the value of the information
being reported. The legacy metrics still remain unchanged, though.
Please refer to the <a href="https://www.eclipse.org/hono/docs/api/metrics/
">Metrics definition</a> for details.</li>
<li>In case of a failed connection attempt, <code>HonoClientImpl</code> will now determine based on the error whether it will re-try
to connect to the peer. Before, reconnect attempts were done unconditionally, by default infinitely or up to the
number of times defined in the <em>reconnectAttempts</em> property in the <code>ClientConfigProperties</code>. Now, when the outcome
of the SASL handshake received from the peer during connection establishment indicates that invalid credentials were
provided or that the server encountered a permanent error when handling the request, no further reconnect attempts
will be done.</li>
<li>The deprecated methods have been removed from <code>org.eclipse.hono.client.MessageSender</code> and
its implementations.</li>
<li>The Command &amp; Control API&rsquo;s <em>send a request/response command</em> operation has been changed. The response
message to a command now must include the device and tenant identifiers of the device. Including
these two properties should make it much easier to implement competing command response consumers
in business applications.
As a consequence, the <code>org.eclipse.hono.client.CommandResponse</code>&rsquo;s factory methods have been changed to
accept the tenant and device IDs as parameters.</li>
<li>The <em>connectTimeout</em> configuration variable for the <code>HonoClient</code> now defines the time to wait not only for the TCP/TLS
connection establishment but also for the SASL handshake and the exchange of the AMQP <em>open</em> frame.</li>
<li>The (already deprecated) Hono Messaging component has been removed from Hono.</li>
</ul>
<h3 id="deprecations-4">Deprecations</h3>
<ul>
<li>The script based deployment to Kubernetes has been deprecated and will be removed in the next version.
The Helm based deployment should be used instead.</li>
<li>The <em>sendCommandResponse(String, String, Buffer, Map, int, SpanContext)</em> of the
<code>org.eclipse.hono.client.CommandResponseSender</code> interface has been deprecated and
will be removed in the next version. Custom protocol adapters should use
<em>sendCommandResponse(CommandResponse, SpanContext)</em> instead.</li>
</ul>
<h2 id="0-9-m2">0.9-M2</h2>
<h3 id="new-features-8">New Features</h3>
<ul>
<li>The MQTT protocol adapter now supports authentication of devices using X.509 client certificates. Please refer to
the <a href="https://www.eclipse.org/hono/docs/user-guide/mqtt-adapter/
">MQTT adapter user guide</a> for details regarding configuration.</li>
</ul>
<h3 id="fixes-enhancements-6">Fixes &amp; Enhancements</h3>
<ul>
<li>The OpenShift <em>source-to-image</em> (S2I) deployment is now the default
OpenShift / OKD deployment. The plain OpenShift deployment, which had been deprecated
in Hono 0.8, has been removed.</li>
<li>The protocol adapters can now be configured with a custom <em>DNS timeout</em> value, limiting the time that the adapter
will wait for the response to a DNS query. By default, a DNS query will time out after 5 seconds.
Please refer to the protocol adapter admin guides for details regarding the new configuration variable.</li>
<li><p>The following configuration variables have been added to <code>HonoClient</code>:</p>
<ul>
<li><em>connectTimeout</em>: Sets a limit on the time that the client will wait for a TCP/TLS connection with the peer
to be established. By default, a connection attempt will time out after 5 seconds.</li>
<li><em>idleTimeout</em>: The idle timeout defines the amount of time after which a connection will be closed when no frames
have been received from the remote peer. The default value is 16 seconds.</li>
<li><em>sendMessageTimeout</em>: Limits the time to wait for a downstream consumer&rsquo;s acknowledgement of
an event or command response message received from a device. The default value is 1 second.</li>
</ul>
<p>Please refer to the <a href="https://www.eclipse.org/hono/docs/admin-guide/hono-client-configuration/
">Hono Client Configuration guide</a>
for details regarding the new configuration variables.</p></li>
</ul>
<h3 id="api-changes-7">API Changes</h3>
<ul>
<li>Some of the <em>tags</em> used by Hono&rsquo;s components when reporting metrics have been changed. The common tag <em>component</em>
has been renamed to <em>component-type</em>. The <em>protocol</em> tag formerly used by adapters to indicate the transport protocol
that a message has been received over, has been replaced by the generic <em>component-name</em> tag which indicates the name
of the component that a metric has been reported by. Please refer to the <a href="https://www.eclipse.org/hono/docs/api/metrics/
">Metrics API</a>
for details. Note that these changes do not affect the legacy Graphite based metrics back end.</li>
</ul>
<h3 id="deprecations-5">Deprecations</h3>
<ul>
<li>The Hono Messaging component is now deprecated and will be removed from Hono in version 0.9 altogether.
The example deployment has not been using Hono Messaging since 0.6 and there is no practical reason for
using it anymore.</li>
</ul>
<h2 id="0-9-m1">0.9-M1</h2>
<h3 id="new-features-9">New Features</h3>
<ul>
<li>The default Micrometer back end is now Prometheus, the Grafana dash boards have been updated
to retrieve data from Prometheus instead of the old InfluxDB.
The Graphite based legacy metrics format can still be used but requires building Hono from source and activating
the <code>metrics-graphite</code> Maven build profile.
Please refer to the <a href="https://www.eclipse.org/hono/docs/admin-guide/monitoring-tracing-config/
">Monitoring admin guide</a> for details.</li>
<li>The <code>org.eclipse.hono.service.credentials.CompleteBaseCredentialsService</code> class now supports the transparent
<em>on-the-fly</em> hashing of clear text passwords contained in <em>hashed-password</em> credentials. Please refer to the
<a href="https://www.eclipse.org/hono/docs/user-guide/device-registry/#managing-credentials
">Device Registry user guide</a> for details.</li>
</ul>
<h3 id="fixes-enhancements-7">Fixes &amp; Enhancements</h3>
<ul>
<li>The base classes for implementing the Device Registration and Tenant APIs have been instrumented
with OpenTracing. New variants of the <code>RegistrationService.assertRegistration</code>, <code>TenantService.get</code> and <code>CredentialsService.get</code>
methods have been added which also accept an OpenTracing span as a parameter.
The default implementations of these methods still default to the previously existing methods.
In <code>RegistrationService</code> implementations based on <code>BaseRegistrationService</code> an OpenTracing span will be created,
passed on to the <code>assertRegistration</code> method and finished eventually. The same applies to <code>TenantService</code> implementations
based on <code>BaseTenantService</code> concerning the <code>get</code> method and to <code>CredentialsService</code> implementations based on
<code>BaseCredentialsService</code> concerning the <code>get</code> method.</li>
</ul>
<h3 id="api-changes-8">API Changes</h3>
<ul>
<li>The <code>org.eclipse.hono.service.credentials.CompleteBaseCredentialsService</code> class now requires an
<code>org.eclipse.hono.auth.HonoPasswordEncoder</code> to be passed into its constructor.
The <code>org.eclipse.hono.auth.SpringBasedHonoPasswordEncoder</code> has been added as a default implementation for
this purpose.</li>
<li>The <a href="https://www.eclipse.org/hono/docs/api/tenant/#trusted-ca-format
">Tenant API</a> now optionally allows specifying an
X.509 certificate instead of a public key when defining a trusted CA.</li>
</ul>
<h2 id="0-8">0.8</h2>
<h3 id="new-features-10">New Features</h3>
<ul>
<li>The already specified new message exchange pattern - called <em>one-way commands</em> - is now available to <em>business applications</em>.
Therefore the <code>CommandClient</code> class was extended by a method <code>sendOneWayCommand</code> that does not expect a response from the device.
See the <code>HonoExampleApplicationBase</code> class for how to use this new command pattern.
On the adapter side, this pattern is supported by the HTTP, MQTT and AMQP adapter so far.</li>
</ul>
<h3 id="fixes-enhancements-8">Fixes &amp; Enhancements</h3>
<ul>
<li>The AMQP adapter has been instrumented using OpenTracing. It now collects traces when a device connects to the adapter,
opens a link for uploading messages and for each message sent by the device. It also adds information to traces created
for command messages to be sent to a device.</li>
<li>The AMQP adapter command line client now uses property names that match those of the HonoClient.</li>
<li>The Command client now has the provision to check the available credits before sending any commands using <code>getCredit()</code>.
Also a handler can be set using <code>sendQueueDrainHandler(Handler&lt;Void&gt; handler)</code>, so that the client is notified when credits are replenished.</li>
<li>The example application <code>HonoExampleApplication</code> can now be configured to only send <code>one-way commands</code> in response to
downstream messages by setting the new system property <code>sendOneWayCommands</code>.</li>
</ul>
<h3 id="api-changes-9">API Changes</h3>
<ul>
<li>The <code>hono-client</code> module now contains all classes necessary to implement Command &amp; Control in protocol adapters.
Previously this has only been the case for the sending of a command, as it is typically done by an application, while
the classes to receive commands, typically used by protocol adapters, were located in the <code>hono-service-base</code> module.
Additionally, the package structure was reworked to allow for implementing protocol adapters that run in an OSGi
environment, so several classes are not in the same package anymore.
Custom protocol adapters thus may need to be slightly refactored to import the Command classes
from their new packages - the functionality has not changed.
The only exception to this is the <code>Device</code> class that was moved to <code>hono-core</code> with a specific
subclass <code>DeviceUser</code>. This subclass is needed in code lines that implement the authentication as defined by the <code>vertx-auth-common</code>
module, so for this class there might be some very few changes to the custom code necessary (the adapted standard protocol
adapters may serve as a blue-print for this). You may want to refer to the method <code>getAuthenticatedDevice</code> in the
<code>AbstractVertxBasedHttpProtocolAdapter</code> class as an example.</li>
<li>The interface <code>ConnectionEventProducer</code> has been modified to support
passing along a context object of type <code>ConnectionEventProducer.Context</code>
which allows the producer implementation to re-use the pre-initialized
Hono clients from the current protocol adapter instance, in the same threading
context. The default implementation of the <em>connection events</em> still defaults
to the logging producer.</li>
<li>The <code>CommandConnection.getOrCreateCommandConsumer</code> method has been renamed to <code>createCommandConsumer</code>. The new name
also reflects a change in the method&rsquo;s semantics. The method will no longer return an already existing instance of a command
consumer for a given device but will instead fail the returned future with a <code>org.eclipse.hono.client.ResourceConflictException</code>
to indicate that a consumer for the given device is already in use. The original behavior allowed an implementation to return
a consumer that was scoped to another message handler than the one passed into the method as an argument. However, client code
had no chance to determine whether it got back a newly created instance or an existing one. This has been resolved with the
new method semantics.</li>
<li>The <code>CommandContext.flow()</code> method has been made private. Client code should instead use the newly introduced variants of the <code>accept(int)</code>,
<code>release(int)</code> and <code>reject(ErrorCondition, int)</code> methods which all accept an integer indicating the number of credits to flow to the sender.
These methods will also finish the OpenTracing span contained in the <code>CommandContext</code> implicitly.</li>
</ul>
<h3 id="deprecations-6">Deprecations</h3>
<ul>
<li>The Kura protocol adapter is being deprecated with 0.8. It will still be part
of Hono 0.8, but may be removed in a future version. Starting with Kura 4.0
and Hono 0.8, both projects can now be used together, without the need for
a special version of the Hono MQTT protocol adapter.</li>
<li>The <code>openshift</code> deployment is being deprecated with 0.8 and is planned to be
removed in 0.9, in favor of the <code>openshift_s2i</code> deployment. While the
<code>openshift</code> deployment still works, it hasn&rsquo;t been updated for more recent
OpenShift and EnMasse versions. The main focus now is on the <em>S2I</em> variant,
which will become the default <em>OpenShift</em>&rdquo; deployment in Hono 0.9.</li>
<li>New variants of the <code>AbstractProtocolAdapterBase.sendConnectedTtdEvent</code>, <code>AbstractProtocolAdapterBase.sendDisconnectedTtdEvent</code>
and <code>AbstractProtocolAdapterBase.sendTtdEvent</code>have been added which also accept an OpenTracing span as a parameter.
The original variants have been deprecated.</li>
</ul>
<h2 id="0-8-m2">0.8-M2</h2>
<h3 id="fixes-enhancements-9">Fixes &amp; Enhancements</h3>
<ul>
<li>HonoClientImpl now waits a limited amount of time for the peer&rsquo;s <em>attach</em> frame during link establishment before considering the attempt to have failed. The time-out value (default is 1000ms) can be configured using the <em>linkEstablishmentTimeout</em> property of <code>org.eclipse.hono.config.ClientConfigProperties</code>. See <a href="https://www.eclipse.org/hono/docs/admin-guide/hono-client-configuration/
">Hono Client Configuration</a> for details.</li>
<li>The example Device Registry service now supports limiting the number of iterations that are supported in BCrypt based hashed-password credentials. This way the processing time required for verifying credentials can be effectively limited. The <code>org.eclipse.hono.service.credentials.CompleteBaseCredentialsService</code> class defines a new method <code>getMaxBcryptIterations</code> which subclasses may override to provide a reasonable default value or determine the value based on a configuration property (as <code>FileBasedCredentialsService</code> of the demo Device Registry does).</li>
<li>Hono now uses OpenJDK 11 as the JVM in the service Docker images. Because OpenJDK 11 has better support for detecting resource limits when running in a container, this also has an impact on the command line parameters passed to the JVM. See <a href="https://www.eclipse.org/hono/docs/deployment/resource-limitation/
">Limiting Resource Usage</a> for details.</li>
<li>Instead of Dropwizard Hono now uses Micrometer. Hono still allows to produce
the same graphite wire format as Hono 0.7 supported. This can be enabled
by the use of the configuration option <code>hono.metrics.legacy</code>. For the
moment this value defaults to <code>true</code>. The plan is to disable the legacy
format for the final 0.8 release, but still support the legacy format at least
until one version after Hono 0.8.</li>
</ul>
<h3 id="api-changes-10">API Changes</h3>
<ul>
<li><code>org.eclipse.hono.util.CredentialsObject.fromHashedPassword</code> now requires a password hash instead of the clear text password to be passed in. Hash values for clear text password can be computed using <code>ClearTextPassword</code>&rsquo;s <code>encode</code> and <code>encodeBCrypt</code> methods.</li>
<li><code>org.eclipse.hono.util.CredentialsObject.isValid</code> has been renamed to <code>checkValidity</code>. The method also no longer returns a boolean but instead throws an <code>IllegalStateException</code> to indicate a failure.</li>
</ul>
<h2 id="0-8-m1-1">0.8-M1_1</h2>
<p>Since 0.8-M1 missed an important artifact, the first 0.8 milestone is available as 0.8-M1_1.</p>
<h3 id="new-features-11">New Features</h3>
<ul>
<li>A new message exchange pattern - called <em>one-way commands</em> - is fully specified for the <a href="https://www.eclipse.org/hono/docs/api/command-and-control/
">Command &amp; Control API</a>.
Note that currently there is no implementation included, this is planned for the following milestone.</li>
</ul>
<h3 id="fixes-enhancements-10">Fixes &amp; Enhancements</h3>
<ul>
<li>Hono-cli now supports Command &amp; Control. Using command line, users can send commands to devices and receive command responses. See <a href="/hono/getting-started/#using-cli-command-line-interface-to-send-commands-and-receive-command-responses">Using CLI for Command &amp; Control</a> for more information.</li>
<li>The command client now enables the setting of application properties for command messages. This can be helpful if custom protocol adapters want to react to specifically annotated commands sent by an application. The standard protocol adapters of Hono do not further exploit these properties.</li>
<li>The command consumer (typically used in protocol adapters) allows access to the application properties of command messages.</li>
</ul>
<h3 id="api-changes-11">API Changes</h3>
<ul>
<li>The <code>org.eclipse.hono.util.TenantObject</code>&rsquo;s <em>getTrustAnchor</em> method now throws a <code>GeneralSecurityException</code> to indicate a problem with decoding/parsing the certificate or public key that is configured as the trusted CA for the tenant. This allows client code to get some insight into the reason for the failure to authenticate a device based on a client certificate.</li>
<li>The <code>org.eclipse.hono.service.registration.RegistrationService</code> interface now describes only the mandatory operations of the API. The complete API is offered in <code>org.eclipse.hono.service.registration.CompleteRegistrationService</code>. These interfaces are implemented in <code>org.eclipse.hono.service.registration.BaseRegistrationService</code> and <code>org.eclipse.hono.service.registration.CompleteBaseRegistrationService</code> respectfully. Device Registries implementations can offer the mandatory only or the full API by extending the according base class.</li>
<li>The <code>org.eclipse.hono.service.tenant.TenantService</code> interface now describes only the mandatory operations of the API. The complete API is offered in <code>org.eclipse.hono.service.tenant.CompleteTenantService</code>. These interfaces are implemented in <code>org.eclipse.hono.service.tenant.BaseTenantService</code> and <code>org.eclipse.hono.service.tenant.CompleteBaseTenantService</code> respectfully. Tenant services implementations can offer the mandatory only or the full API by extending the according base class.</li>
<li>The <code>org.eclipse.hono.service.credentials.CredentialsService</code> interface now describes only the mandatory operations of the API. The complete API is offered in <code>org.eclipse.hono.service.credentials.CompleteCredentialsService</code>. These interfaces are implemented in <code>org.eclipse.hono.service.credentials.BaseCredentialsService</code> and <code>org.eclipse.hono.service.credentials.CompleteBaseCredentialsService</code> respectfully. Credentials services implementations can offer the mandatory only or the full API by extending the according base class.</li>
<li>All messages containing JSON objects as payload are now encoded using <em>Data</em>
sections and are required to have the content type <code>application/json</code>.
This affects the Tenant, Credentials and Registry API. When evaluating Hono
still accepts <em>AMQP Values</em> of type String or byte[]. But this behavior is
deprecated and my be dropped in releases after 0.8.</li>
</ul>
<h2 id="0-7">0.7</h2>
<h3 id="new-features-12">New Features</h3>
<ul>
<li>The MQTT protocol adapter now supports Command and Control. Please refer to <a href="https://www.eclipse.org/hono/docs/user-guide/mqtt-adapter/
">MQTT adapter User Guide</a> for details.</li>
<li>The Credentials API now explicitly defines <a href="https://de.wikipedia.org/wiki/Bcrypt">Bcrypt</a> as a supported hash function for <a href="https://www.eclipse.org/hono/docs/api/credentials/#hashed-password
"><em>hashed-password</em> credentials</a>. The protocol adapters also support verification of username/password credentials against Bcrypt hashes.</li>
<li>Hono&rsquo;s HTTP and MQTT protocol adapters and HonoClient have been instrumented using <a href="http://opentracing.io">OpenTracing</a> in order to support tracing of the interactions between Hono components that are involved in the processing of messages as they flow through the system. The new <a href="https://www.eclipse.org/hono/docs/admin-guide/monitoring-tracing-config/
">Monitoring &amp; Tracing</a> admin guide has the details.</li>
<li>Hono now contains an initial version of an AMQP protocol adapter which can be used to connect devices to Hono using the AMQP 1.0 protocol. The adapter currently exposes Telemetry and Event endpoints only. Support for Command &amp; Control will be added in a future release. Please refer to the AMQP adapter&rsquo;s <a href="https://www.eclipse.org/hono/docs/admin-guide/amqp-adapter-config/
">Admin Guide</a> and <a href="https://www.eclipse.org/hono/docs/user-guide/amqp-adapter/
">User Guide</a> for details regarding how to set up and use the new adapter.</li>
</ul>
<h3 id="fixes-enhancements-11">Fixes &amp; Enhancements</h3>
<ul>
<li>Hono is now licensed under the <a href="https://www.eclipse.org/legal/epl-2.0/">Eclipse Public License 2.0</a>. Please refer to the Eclipse Foundation&rsquo;s <a href="https://www.eclipse.org/legal/epl-2.0/faq.php">FAQ</a> for details regarding any implications this might have.</li>
<li>Hono deployment scripts are now available under <code>deploy</code> folder. Deployment scripts which were previously available under <code>example</code> folder were moved to <code>deploy</code>.</li>
<li>Hono-cli (Command Line Interface) is now available under folder <code>cli</code>. A command line argument <code>message.type</code> with value <code>telemetry</code>, <code>event</code> or <code>all</code> (default) tells the client what kind of messages to be received. See <a href="/hono/getting-started/#starting-a-consumer">Starting a Consumer</a> for more information.</li>
<li>Added metrics to Command and Control for HTTP and MQTT protocol adapters. Now Hono-Dashboard also shows the metrics from Command and Control.</li>
<li>Add a <em>dummy</em> implementation of the device registry services. This allows to
do better scale testing as the file based device registry cannot be scaled up
and thus is a bottleneck in the example setup. The device registry however has
no real storage. So it still can be part of the test, but is no limiting
factor anymore.</li>
<li>The Hono Travis build now also builds for JDK 10 in addition to JDK 8.
Hono is still intended to run on Java 8, but the JDK 10 build was enabled to
be better prepared for Java 11.</li>
<li>The example application in the <code>example</code> folder now supports Command and Control for all <code>ttd</code> values, including a
value of <code>-1</code> that signals that a device stays connected for an unlimited time frame. In this case it sends a command
every 15 seconds, which is helpful for testing this feature with MQTT devices. A <code>ttd</code> value of <code>0</code> stops this
behaviour again (both automatically sent by the MQTT adapter for <code>subscribe</code> and <code>unsubscribe</code>, see
<a href="https://www.eclipse.org/hono/docs/dev-guide/java_client_consumer/
">Consuming Messages from Java</a> for details).</li>
<li>The maximum value for the value of <code>ttd</code> that is allowed for requests to the HTTP adapter is now configurable per tenant.
The default value is <code>60</code> seconds.
Please refer to <a href="https://www.eclipse.org/hono/docs/user-guide/http-adapter/#tenant-specific-configuration
">HTTP Adapter Tenant Configuration</a>.</li>
</ul>
<h3 id="api-changes-12">API Changes</h3>
<ul>
<li>Fix the <code>EventBusService</code> methods handling type safety to handle a
mismatching type according to their documentation, returning <code>null</code>. This
introduced a method signature change for <code>getTypesafeValueForField</code> and
<code>removeTypesafeValueForField</code>. Also see PR <a href="https://github.com/eclipse/hono/pull/757">#757</a>.</li>
</ul>
<h2 id="0-7-m2">0.7-M2</h2>
<h3 id="new-features-13">New Features</h3>
<ul>
<li>The Auth Server can now be used to authenticate clients connecting to the Apache Qpid Dispatch Router which is used in the example deployment. For this purpose the Auth Server is configured as a <em>remote auth server</em> implementing <a href="https://qpid.apache.org/releases/qpid-dispatch-1.1.0/man/qdrouterd.conf.html#_authserviceplugin">Dispatch Router&rsquo;s <em>Auth Service Plugin</em> mechanism</a>. Using this mechanism it is now possible to manage all identities and authorities using the Auth Server&rsquo;s configuration file.</li>
<li>The HTTP protocol adapter now supports devices uploading a response to a command that has been sent to the device before. Please refer to the <a href="https://www.eclipse.org/hono/docs/user-guide/http-adapter/#sending-a-response-to-a-command-authenticated-device
">HTTP adapter User Guide</a> for details.</li>
<li>Hono&rsquo;s service components can now be configured to use OpenSSL instead of the JVM&rsquo;s default SSL engine. The <a href="https://www.eclipse.org/hono/docs/admin-guide/secure_communication/#using-openssl
">admin guide</a> describes how to do this.</li>
<li>In addition to number of successful MQTT and HTTP messages now also the
payload size of the message body is being recorded in the metrics system.</li>
</ul>
<h3 id="fixes-enhancements-12">Fixes &amp; Enhancements</h3>
<ul>
<li>The Device Registry&rsquo;s AMQP endpoints can now be configured with the number of credits they should flow to clients connecting to the endpoints. The default value is 100. See <a href="https://www.eclipse.org/hono/docs/admin-guide/device-registry-config/#service-configuration
">Device Registry admin guide</a> for details.</li>
</ul>
<h3 id="api-changes-13">API Changes</h3>
<ul>
<li>The Command &amp; Control API has been changed to be less restrictive on the format of <em>reply-to</em> addresses. Response messages are no longer required to be scoped to a single device but may instead be scoped to a tenant. This allows for applications to implement a <em>generic</em> command response handler, thus allowing for easier fail-over between nodes.</li>
</ul>
<h2 id="0-7-m1">0.7-M1</h2>
<h3 id="fixes-enhancements-13">Fixes &amp; Enhancements</h3>
<ul>
<li><code>HonoClientImpl</code>&rsquo;s strategy for attempting to establish a connection with a peer has been enhanced. The client&rsquo;s <em>connect</em> methods by default will only try three times to establish a TCP connection with the peer before giving up. Based on the value of the new <em>reconnectAttempts</em> property of <code>ClientConfigProperties</code>, the client will then either re-try to connect to the peer (including a fresh DNS lookup of the peer&rsquo;s host name) or fail the overall connection attempt. This way, the client will not get stuck in an endless loop if the peer&rsquo;s IP address has changed or the peer has crashed while the client tries to connect to it.</li>
<li>The Java Virtual Machines run by Docker images provided by Hono now consider resource limitations defined for a container on startup. See <a href="https://www.eclipse.org/hono/docs/deployment/resource-limitation/
">Limiting Resource Usage</a> for details how this can e.g. be used to limit memory consumption. The example deployment already makes use of this mechanism.</li>
</ul>
<h2 id="0-6">0.6</h2>
<h3 id="new-features-14">New Features</h3>
<ul>
<li>Protocol adapters, services and HonoClient now support TLS 1.2 only by default when using TLS to secure communication. However, additional protocols can be enabled by means of setting environment variables as described in the admin guides.</li>
<li>The deployment examples for OpenShift got overhauled. The two provided
examples are not both based on EnMasse and follow a similar architecture. The
newly added <em>source-to-image</em>&rdquo; based approach doesn&rsquo;t require a local
development setup but created new images directly in the OpenShift
instance. It also makes more use of ConfigMaps and service key/cert management.</li>
<li><strong>Tech preview</strong>: Protocol adapters do have the ability to send out connection events. Those
events are best-effort events, indicating when a connection has been
established and when it has been lost. There is a pluggable way of
handling/creating those events, including two default implementations. A
logger implementation, which simply logs to the logging system. And one
implementation which sends out events to the <em>Hono Event API</em>.<br />
<strong>Note</strong>: This feature is part of the Eclipse IoT integration effort and not
yet considered a public API.</li>
<li>The HTTP protocol adapter now supports authentication of devices based on X.509 client certificates. Each tenant can be configured with an individual trust anchor which the HTTP adapter will retrieve using the Tenant API when a device tries to authenticate with a certificate as part of a TLS handshake. The Credentials API now supports a <a href="https://www.eclipse.org/hono/docs/api/credentials/#x-509-certificate
">new credentials type</a> for registering a mapping of the certificate&rsquo;s <em>subject DN</em> to the device identifier. Please consult the <a href="https://www.eclipse.org/hono/docs/user-guide/http-adapter/#device-authentication
">HTTP adapter User Guide</a> for details regarding usage.</li>
<li>The HTTP adapter now supports uploading telemetry messages using QoS 1 (<code>AT_LEAST_ONCE</code>). Clients must set the <code>QoS-Level</code> request header if they want the HTTP adapter to upload telemetry messages using QoS 1.</li>
<li>The concept and implementation of <em>Device notifications</em> were added. It enables devices to signal that they are ready to receive an upstream message by specifying a <code>time til disconnect</code> parameter with any downstream message. Please see <a href="https://www.eclipse.org/hono/docs/concepts/device-notifications/
">Device notifications</a> for details.</li>
<li><strong>Tech preview</strong>: <em>Command and Control</em> is now available for the HTTP protocol adapter (NB: currently without responses from the device to the application).
It enables HTTP devices to signal how long they stay <em>connected</em> to the HTTP protocol adapter, resulting in a delayed response.
The response then may contain a command sent by the application. Please refer to the <a href="https://www.eclipse.org/hono/getting-started/">Getting Started</a>
guide and the Command &amp; Control <a href="https://www.eclipse.org/hono/docs/concepts/command-and-control/
">concept page</a> for details.<br />
<strong>Note</strong>: This feature is available now as a first fully working version but is considered to possibly have some unknown issues that may not make it
fully production ready yet.</li>
</ul>
<h3 id="fixes-enhancements-14">Fixes &amp; Enhancements</h3>
<ul>
<li>Hono&rsquo;s standard protocol adapters can now be connected directly to the AMQP Network, i.e. without going through Hono Messaging. For Hono&rsquo;s standard adapters Hono Messaging does not provide any additional value because the devices&rsquo; registration status is already being validated by the protocol adapters. Omitting Hono Messaging should therefore reduce message processing latency for standard adapters. However, custom protocol adapters still need to be connected to Hono Messaging. The Getting started guide, the Sandbox and the deployment scripts have been changed accordingly. Note that it is still possible to connect all adapters to Hono Messaging, though.</li>
</ul>
<h3 id="api-changes-14">API Changes</h3>
<ul>
<li>The Tenant API&rsquo;s <em>get Tenant Information</em> operation has been changed to expect search criteria in the request message&rsquo;s payload instead of the application-properties. This change has been made in order to support other search criteria than just the tenant identifier. In particular, the <em>get Tenant Information</em> operation can now be used to find a tenant based on the subject DN of a trusted certificate authority that has been configured for the tenant. See <a href="https://www.eclipse.org/hono/docs/api/tenant/#get-tenant-information
">get Tenant Information</a> for details.</li>
<li><p>The result type of <code>org.eclipse.hono.util.MessageHelper.getPayload(Message msg)</code> has been changed from <code>String</code> to the more generic <code>io.vertx.core.buffer.Buffer</code> to be able to handle e.g. binary data.</p></li>
<li><p>The default way how <code>HonoClient</code> instances are being created has changed.
As the default implementation <code>HonoClientImpl</code> was located in an internal
<code>impl</code> package, it wasn&rsquo;t accessible when using OSGi as this was package wasn&rsquo;t
exported. The old constructor is still available. In combination with that the
<code>ConnectionFactoryImpl</code> builder concept was removed as it didn&rsquo;t add anything
on top of the <code>ClientConfigProperties</code>. The <code>ConnectionBuilderImpl</code> class
was also moved to an <code>impl</code> package to follow the pattern of
<code>HonoClientImpl</code>. The two new methods to created instances are are:
<code>org.eclipse.hono.connection.ConnectionFactory.newConnectionFactory(Vertx, ClientConfigProperties)</code>
and
<code>org.eclipse.hono.client.HonoClient.newClient(Vertx, ClientConfigProperties)</code>.</p></li>
</ul>
<h2 id="0-6-m2">0.6-M2</h2>
<h3 id="api-changes-15">API Changes</h3>
<ul>
<li>The <code>HonoClient.isConnected()</code> method has been changed to return a <code>Future&lt;Void&gt;</code> instead of <code>Future&lt;Boolean&gt;</code>. The future will succeed if the client is connected and will fail otherwise. This change makes it easier to compose the check with other futures.</li>
<li>The signatures of the (base) methods for processing requests of <code>org.eclipse.hono.service.credentials.BaseCredentialsService</code>, <code>org.eclipse.hono.service.registration.BaseRegistrationService</code> and <code>org.eclipse.hono.service.tenant.BaseTenantService</code> have changed to both accept and return an <code>org.eclipse.hono.util.EventBusMessage</code>. Subclasses overriding the corresponding methods will need to be adapted accordingly.</li>
</ul>
<h3 id="fixes-enhancements-15">Fixes &amp; Enhancements</h3>
<ul>
<li>The <em>hono-client</em> and <em>hono-core</em> artifacts no longer depend on classes from the <em>Spring</em> framework which can help reducing the footprint of applications that want to use the Hono client but otherwise do not employ any Spring libraries.</li>
<li>The Qpid Dispatch Router used in the example configuration has been updated to version 1.0.1.</li>
<li>vert.x has been updated to version 3.5.1.</li>
<li>The MQTT adapter now also supports shortened versions of the telemetry and event topic names. Devices may use just <code>t</code> instead of <code>telemetry</code> and <code>e</code> instead of <code>event</code>.</li>
</ul>
<h2 id="0-6-m1">0.6-M1</h2>
<h3 id="new-features-15">New Features</h3>
<ul>
<li>The MQTT protocol adapter now supports publishing telemetry data using either QoS 0 or QoS 1. In case of QoS 1 the adapter will send an MQTT <em>PUBACK</em> to the device once the downstream peer has settled the message with the AMQP <em>accepted</em> outcome.</li>
<li>Hono now specifies a <a href="https://www.eclipse.org/hono/docs/api/tenant/
">Tenant API</a> and contains an exemplary implementation of this API.
The purpose of the API is to make Hono aware of the tenants that are available in an installation. This comprises of:
<ul>
<li>a file-based version of the Tenant API service that implements all mandatory and optional operations</li>
<li>the implementation of the AMQP 1.0 endpoint as part of the device registry component</li>
<li>the AMQP 1.0 based implementation of the mandatory <strong>get</strong> operation of the API</li>
<li>an HTTP endpoint to support CRUD operations for tenants (GET, POST, PUT, DELETE) for convenience</li>
</ul></li>
<li><code>org.eclipse.hono.client.impl.AbstractRequestResponseClient</code> now supports generic caching of responses to service invocations based on <em>cache directives</em>. See <a href="https://www.eclipse.org/hono/docs/admin-guide/hono-client-configuration/
">Hono Client Configuration</a> for details.</li>
<li>The protocol adapters now can be enabled/disabled <em>per tenant</em> using the <a href="https://www.eclipse.org/hono/docs/api/tenant/
">Tenant API</a>. A protocol adapter that has been disabled for a tenant will reject telemetry messages and events published by any device that belongs to the particular tenant.</li>
</ul>
<h3 id="fixes-enhancements-16">Fixes &amp; Enhancements</h3>
<ul>
<li>HonoClient now fails all futures it returns with instances of <code>org.eclipse.hono.client.ServiceInvocationException</code> if something goes wrong. Client code can inspect the exception&rsquo;s <em>errorCode</em> property to get a better understanding of the reason for the failure.</li>
</ul>
<h2 id="0-5">0.5</h2>
<h3 id="new-features-16">New Features</h3>
<ul>
<li>We have added a protocol adapter for allowing <a href="https://www.eclipse.org/kura">Eclipse Kura</a> gateways to publish <em>control</em> and <em>data</em> messages to Hono&rsquo;s Telemetry and Event API. See <a href="https://www.eclipse.org/hono/docs/admin-guide/kura-adapter-config/
">Kura Adapter</a> for details.</li>
<li><code>RegistrationClientImpl</code> now supports caching of registration assertions received from a Device Registration service. The protocol adapters already make use of this feature so that they do not need to do a remote service invocation unless a cached assertion has expired. The protocol adapters support two new configuration variables to set the minimum and maximum cache size.</li>
<li>Devices can now be configured to act as <em>gateways</em> and publish data <em>on behalf of</em> other devices that are not connected to a protocol adapter directly but to the gateway. This is useful for receiving data from devices using narrow band radio communication like <a href="https://www.sigfox.com">SigFox</a> or <a href="https://www.lora-alliance.org/">LoRa</a>. See <a href="https://www.eclipse.org/hono/docs/admin-guide/device-registry-config/#configuring-gateway-devices
">Configuring Gateway Devices</a> for details.</li>
</ul>
<h3 id="fixes-enhancements-17">Fixes &amp; Enhancements</h3>
<ul>
<li>See <a href="https://github.com/eclipse/hono/issues?utf8=%E2%9C%93&amp;q=is%3Aissue%20milestone%3A0.5">Git Hub</a> for the list of issues addressed.</li>
<li>The documentation of Hono&rsquo;s individual components has been split up into information relevant for <em>using</em> the components (<em>User Guide</em>) and information relevant for <em>configuring</em> the components (<em>Admin Guide</em>).</li>
</ul>
<h3 id="configuration-changes">Configuration Changes</h3>
<ul>
<li>All Hono Docker images after 0.5-M10 now use <code>eclipse/</code> instead of <code>eclipsehono/</code> as the prefix in the image repository name.</li>
<li>The default names of the files used by the Device Registry component for persisting data have changed:
<ul>
<li><code>/home/hono/registration/device-identities.json</code> has been changed to <code>/var/lib/hono/device-registry/device-identities.json</code></li>
<li><code>/home/hono/registration/credentials.json</code> has been changed to <code>/var/lib/hono/device-registry/credentials.json</code></li>
</ul></li>
<li>The Device Registry used in the <em>Getting started</em> guide now by default persists data to a file system volume.</li>
<li>The <em>REST Adapter</em> has been renamed to <em>HTTP Adapter</em> because it does not really comply with the common requirements for RESTful services. As part of this effort, the names of the HTTP adapter&rsquo;s configuration variables have also been changed accordingly. See <a href="https://www.eclipse.org/hono/docs/admin-guide/http-adapter-config/#service-configuration
">HTTP Adapter Configuration</a> for details.</li>
<li>The Device Registry component&rsquo;s <code>HONO_CREDENTIALS_SRV_CREDENTIALS_FILENAME</code> configuration variable has been shortened to just <code>HONO_CREDENTIALS_SVC_FILENAME</code> to match its counterpart for configuring the filename of the device registration service implementation.</li>
</ul>
<h3 id="api-changes-16">API Changes</h3>
<ul>
<li>The <a href="https://www.eclipse.org/hono/docs/api/telemetry/
">Telemetry API</a> has been updated to recommend clients to use <em>AT LEAST ONCE</em> delivery semantics instead of <em>AT MOST ONCE</em>. This change has been made to better support end-to-end flow control between protocol adapters (devices) and downstream consumers. Note that this change has no impact on the <em>quality of service</em> that devices and consumers experience, i.e. telemetry data published by a device to a protocol adapter is still <em>not guaranteed</em> to be delivered to a downstream consumer even if the device has received an acknowledgement from the protocol adapter indicating that it has accepted the data (e.g. a 202 HTTP status code).</li>
<li>The <code>org.eclipse.hono.client.HonoClient</code> interface has been changed:
<ul>
<li>All methods that had previously returned <code>HonoClient</code> have been changed to return <code>Future&lt;HonoClient&gt;</code> instead. Returning the client instance had originally been intended to be useful for chaining commands. However, there was nothing much to chain because the effect of invoking the (asynchronous) operations is usually not immediately visible in the client, e.g. when invoking the <em>connect</em> method, the returned client will most likely not (yet) be connected.</li>
<li>All methods that had previously accepted a <code>Handler&lt;AsyncResult&gt;</code> have been changed to return a <code>Future</code> instead. This makes orchestration of these methods and their results using <code>Future.compose</code>, <code>Future.map</code> etc. much easier.</li>
</ul></li>
<li>The <code>org.eclipse.hono.client.MessageSender</code> interface has been changed:
<ul>
<li>All methods now return a <code>Future&lt;ProtonDelivery&gt;</code> to indicate the outcome of the operation according to the sender specific delivery semantics.
For a Telemetry client this means that the future will be succeeded immediately after the message has been sent, i.e. the client does not wait
for a downstream container to accept the message.
For an Event client this means that the future will be succeeded once the downstream container has settled and accepted the message.</li>
<li>All operations accepting a disposition handler have been removed in order to relieve clients from the burden of (correctly) implementing the delivery semantics.</li>
</ul></li>
<li>The <code>org.eclipse.hono.client.RegistrationClient</code> interface has been changed:
<ul>
<li>All methods that had previously accepted a <code>Handler&lt;AsyncResult&gt;</code> have been changed to return a <code>Future</code> instead. This makes orchestration of these methods and their results using <code>Future.compose</code>, <code>Future.map</code> etc. much easier.</li>
</ul></li>
<li>The <code>org.eclipse.hono.client.CredentialsClient</code> interface has been changed:
<ul>
<li>All methods that had previously accepted a <code>Handler&lt;AsyncResult&gt;</code> have been changed to return a <code>Future</code> instead. This makes orchestration of these methods and their results using <code>Future.compose</code>, <code>Future.map</code> etc. much easier.</li>
</ul></li>
<li>The <a href="https://www.eclipse.org/hono/docs/api/device-registration/#assert-device-registration
">assert Device Registration</a> operation of the Device Registration API has been extended with an optional <em>gateway_id</em> parameter which can be used to get a registration status assertion on behalf of another device. This is mainly intended to support use cases where devices do not connect to a protocol adapter directly but are connected to a <em>gateway</em> component which <em>acts on behalf of</em> its connected devices when publishing data to a protocol adapter.
A corresponding <em>assertRegistration</em> operation has been added to the <code>org.eclipse.hono.client.RegistrationClient</code> and <code>org.eclipse.hono.service.registration.RegistrationService</code> interfaces which require both a device ID and a gateway ID being passed in as parameters.</li>
</ul>
<h2 id="0-5-m10">0.5-M10</h2>
<h3 id="new-features-17">New Features</h3>
<ul>
<li>We have set up a <a href="https://www.eclipse.org/hono/sandbox/">Sandbox server</a> at <code>hono.eclipse.org</code> which can be used to connect devices and consumers for testing purposes without the need to run a Hono instance locally.</li>
</ul>
<h3 id="fixes-enhancements-18">Fixes &amp; Enhancements</h3>
<p>See <a href="https://github.com/eclipse/hono/issues?utf8=%E2%9C%93&amp;q=is%3Aissue%20milestone%3A0.5-M10">Git Hub</a> for the list of issues addressed.</p>
<h3 id="configuration-changes-1">Configuration Changes</h3>
<ul>
<li>The example <em>Dispatch Router</em> is configured to use balanced distribution of messages to consumers (vs. multicast before). For full AMQP flow control, this is the preferred option.</li>
</ul>
</div>
</div>
</div>
</div>
</div>
<footer id="footer">
<div class="container">
<div class="col-md-4 col-sm-6">
<h4>More</h4>
<ul>
<li><a href="https://github.com/eclipse/hono" title="View Source Code on GitHub"><i class='fab fa-github'></i> GitHub Repository</a></li>
<li><a href="https://twitter.com/EclipseHono" title="Follow us on Twitter"><i class='fab fa-twitter'></i> Twitter</a></li>
<li><a href="/hono/thankyou">Thank you</a></li>
</ul>
<hr class="hidden-md hidden-lg hidden-sm">
</div>
<div class="col-md-4 col-sm-6">
<h4>Eclipse Legal</h4>
<ul>
<li><a href="http://www.eclipse.org/legal/privacy.php" target="_blank">Privacy Policy</a></li>
<li><a href="http://www.eclipse.org/legal/termsofuse.php" target="_blank">Terms of Use</a></li>
<li><a href="http://www.eclipse.org/legal/copyright.php" target="_blank">Copyright Agent</a></li>
<li><a href="http://www.eclipse.org/legal" target="_blank">Legal</a></li>
<li><a href="https://www.eclipse.org/legal/epl-2.0/" target="_blank">License</a></li>
<li><a href="https://eclipse.org/security" target="_blank">Report a Vulnerability</a></li>
</ul>
<hr class="hidden-md hidden-lg">
</div>
<div class="col-md-4 col-sm-6">
<div>
<div class="incubation">
<a href="https://www.eclipse.org/projects/what-is-incubation.php" target="_blank">
<img src="https://www.eclipse.org/hono/img/eclipse_incubation_vertical_png-02.png" width="100%" />
</a>
</div>
<div class="eclipse-logo">
<a href="https://www.eclipse.org" target="_blank">
<img src="https://www.eclipse.org/hono/img/eclipse_foundation_logo_wo.svg"/>
</a>
</div>
</div>
</div>
</div>
</footer>
<div id="copyright">
<div class="container">
<div class="col-md-12">
<p class="pull-left">&copy; 2019 The Eclipse Hono Project</p>
<p class="pull-right">
Template by <a href="http://bootstrapious.com/free-templates">Bootstrapious</a>.
Ported to Hugo by <a href="https://github.com/devcows/hugo-universal-theme">DevCows</a>
</p>
</div>
</div>
</div>
</div>
<script src="//code.jquery.com/jquery-3.1.1.min.js" integrity="sha256-hVVnYaiADRTO2PzUGmuLJr8BLUSjGIZsDYGmIJLv2b8=" crossorigin="anonymous"></script>
<script src="//maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/jquery-cookie/1.4.1/jquery.cookie.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/waypoints/4.0.1/jquery.waypoints.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/Counter-Up/1.0/jquery.counterup.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/jquery-parallax/1.1.3/jquery-parallax.js"></script>
<script src="https://www.eclipse.org/hono/js/front.js"></script>
<script src="https://www.eclipse.org/hono/js/owl.carousel.min.js"></script>
<script>
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-5WLCZXC');
</script>
<script src="https://www.eclipse.org/eclipse.org-common/themes/solstice/public/javascript/vendor/cookieconsent/default.min.js"></script>
</body>
</html>