Re: [hono-dev] hono-dev Digest, Vol 2, Issue 6

[Henryk Konsek <hekonsek@xxxxxxxxx>]

Hi Atul,

The separated Hono process is needed only if you need a multitenancy on the platform level. For example if you would like to deploy Hono as a cloud and allow various 3rd parties to connect their services into your Hono installation (for example to consume data sent from particular devices). In such case, you need a separated process to enforce tenants separation (like using dedicated AMQP queues per tenant) and security checks.

If you don't need multitenancy on the platform level (i.e. there is only a single party responsible for deploying services on the right side of the diagram) then you can skip IoT Connector process, use default tenant and rely on your MOM only to deliver the message.

Hono is designed to support both type of deployments. BTW We should update our topology diagrams after our Berlin meeting. :)

Cheers!

pon., 7.03.2016 o 19:46 użytkownik Atul Kshirsagar <atul.kshirsagar@xxxxxxxxx> napisał:

On 06/03/16 01:55, Atul Kshirsagar wrote:
> 1) After going through excellent wiki page on topology options, I feel
> that the option of "connection via Message broker" is more closely
> aligned with what we are internally discussing at GE. Some reasons
> behind this are as follows:
> a. Reduces one additional network hop
> b. Avoids one additional protocol conversion if underlying MOM/broker
> being used doesn't natively support AMQP 1.0 (e.g. Kafka)

In my view, the protocol adapters and the solutions should not know or
care about the underlying MOM used. They should use a standard protocol
(whatever that is) to communicate with it.

If that is true, then the difference between 'Direct Connection' and
'Connection via Message Broker' is that in the second case the broker in
question itself supports this standard protocol (whatever it may be),
either natively or through some extensions considered to be outside the
scope of Hono itself.

So to me, the advantage you describe above really applies to the the
'Direct Connection' case. (I apologise if I am mistaken or being overly
pedantic :-)

May be I should have been more explicit. My view of "Connection via Message Broker" doesn't involve a different Hono process. I am expecting the hono libraries embedded in protocol adapters/solution to directly connect to underlying MOM. However, this does expose hono clients (protocol adapters and solutions) to underlying implementation even if through maven/gradle dependency. While hono clients will work off of hono API the concrete implementations of hono API will be specific to MOM being used.

_______________________________________________
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

--

Henryk Konsek

http://about.me/hekonsek