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

[Atul Kshirsagar <atul.kshirsagar@xxxxxxxxx>]

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.