| 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 :
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 ;-) Thanks, Paolo. Paolo Patierno Senior Software Engineer Windows Embedded & IoT Microsoft Azure Advisor Blog : Embedded101 > 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 > https://dev.eclipse.org/mailman/listinfo/hono-dev |