Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Let's get started

Just my 2 cents ...
... related to what Gordon said : "... take the question in this thread of whether or not clients connect directly to the infrastructure, or only through Hono..."
Reading previous emails and Hono project description, my personal idea about it is that Hono could be represented in the following two exchangeable ways :
  • an "out of box" MOM like ActiveMQ, Artemis, RabbitMQ and so on to connect to using AMQP 1.0 protocol;
  • a MOM developed as software component. Today it's based on the EventDispatcher, tomorrow it could be based on Vert.x Proton server (to guarantee connection based on AMQP 1.0);
The common element will be the AMQP 1.0 API we should define in terms of AMQP node/path to connect/send/receive to interact with the infrastructure.
As Gordon says, implementing a software component as a Messaging middleware we need to provide same features as an "out of box" middleware so that all these features are always available in any scenarios (using both above middlewares).
In case we use an "out of box" MOM it could be not so productive to put another layer in front of it. Of course, the protocol adapters (for HTTP, MQTT, ...) are needed for interoperability.
On my understanding, I think that the Hono value is to define a good AMQP API and use MOM capabilities to provide Hono features we want.
Of couse the other value is provided by adapters and predefined services (like device management and monitoring) on both Hono sides.
So referring to what Gordon said ... I can't understand the difference between connecting directly to the infrastructure or only through Hono, if the "infrastructure" (aka a MOM) IS a possible Hono implementation ... so for me they are the same.
Sorry If I have lost your points due to my miss understanding ;-)

Paolo Patierno
Senior Software Engineer

Windows Embedded & IoT
Microsoft Azure Advisor 

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience

> To: hono-dev@xxxxxxxxxxx
> From: gsim@xxxxxxxxxx
> Date: Mon, 29 Feb 2016 14:49:26 +0000
> Subject: Re: [hono-dev] Let's get started
> On 28/02/16 10:09, Kai wrote:
> > I think you are exactly right, the specific message exchange semantics
> > are Hono's "raison d'etre". However, this still allows for these
> > messages being forwarded to consumers via infrastructure that has no
> > knowledge of these semantics as long as they use AMQP 1.0, right?
> Of course.
> My point was that using different infrastructure may result in different
> characteristics of course, but it should not (in my opinion) alter the
> semantics of what Hono provides.
> The interface and interaction between the infrastructure and any Hono
> components is therefore important. (Standard messaging protocols aim to
> define such interfaces of course).
> Simply as an example, take the question in this thread of whether or not
> clients connect directly to the infrastructure, or only through Hono.
> Brokers typically provide features related to accepting incoming
> connections - e.g. flexible authentication options, connection limits,
> access restrictions, management and monitoring of connections etc - but
> not tied to any specific messaging patterns or semantics. If using Hono
> requires that clients connect to some Hono component instead, then these
> features may not be accessible as implemented in the broker. None of
> these are in themselves difficult to develop of course but in my view
> they aren't the core focus of what Hono aims to offer.
> The best way to provide a feature Hono offers may of course necessitate
> re-implementation of functionality commonly available in the
> infrastructure. I'm not arguing it never makes sense, just that it is
> worth being clear as to why it is necessary.
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top