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

[Atul Kshirsagar <atul.kshirsagar@xxxxxxxxx>]

Hi Henryk,

I was thinking that multi-tenancy could be achieved without a separate hono process as well. Hono client libraries specific to each MOM could achieve that. E.g. Hono cilent implementation for RabbitMQ will target separate Vhost based on tenant or hono client implementation for Kafka could prefix tenant ID to the kafka topic. We could similarly achieve AuthN and AuthZ by letting underlying MOM authenticate and provide access control.

Having said that, I do see value in having a separate hono process, not for multi-tenancy or AuthN/AuthZ but for routing and hiding underlying MOM from protocol adapters and solutions. If we do not have separate hono process then protocol adapter or solutions will need to know what is underlying MOM and include appropriate Hono implementation library (as maven/gradle dependency).

I hope I could make it to Berlin meeting, at present it looks unlikely based on German consulate's visa appointment schedule :(

Regards,

Atul

On Fri, Mar 18, 2016 at 9:00 AM, <hono-dev-request@xxxxxxxxxxx> wrote:

Send hono-dev mailing list submissions to
        hono-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://dev.eclipse.org/mailman/listinfo/hono-dev
or, via email, send a message with subject or body 'help' to
        hono-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
        hono-dev-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hono-dev digest..."


Today's Topics:

   1. Re: hono-dev Digest, Vol 2, Issue 6 (Henryk Konsek)


----------------------------------------------------------------------

Message: 1
Date: Fri, 18 Mar 2016 15:23:34 +0000
From: Henryk Konsek <hekonsek@xxxxxxxxx>
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] hono-dev Digest, Vol 2, Issue 6
Message-ID:
        <CALhQg-bVK4KP5__==-VmmSXhR4nAgFfMhKSLiUjfoU2OubfDHA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/hono-dev/attachments/20160318/094d558f/attachment.html>

------------------------------

_______________________________________________
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


End of hono-dev Digest, Vol 2, Issue 10
***************************************