Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Commands & Control in HonoClient

Hi Avgustin,

 

>If the HonoClient is just application oriented then why it provides MessageSender-s (e.g. getOrCreateTelemetrySender, getOrCreateEventSender) as well as registry/credentials/tenants access >(e.g. getOrCreateRegistrationClient, getOrCreateCredentialsClient, getOrCreateTenantClient)? Which are completely in scope of protocol adapter. That made me feel that HonoClient is not just >about the applications but for the protocol adapters too (which are also kind of clients for Hono server/core. Sorry if my terminology is not correct but  by Hono server/core I mean Hono without >adapters).

 

that is a valid question. IMHO we should come to a better separation of responsibilities in the future and I created an issue for this (https://github.com/eclipse/hono/issues/780).

 

Currently the HonoClient is focused on providing access to Hono’s APIs and this includes all the mentioned methods. With the (first) exception that the command consumer client

is offered by a child interface of HonoClient : CommandConnection.

 

I am sure it needs some discussions to come to a IMHO better solution in the future and would like to have this discussion in the created issue – there we can use GitHub’s capabilities to discuss certain code lines and focused comments (instead of using emails).

Please are very welcome to comment what I have written there.

 

>If you intend to have HonoClient just for applications and as simple as possible I suppose you should provide just message consumers and command client. Or I miss something?

No, I basically agree with what you wrote. This is mainly the content of the issue (meaning: we are not there yet..).

 

>I would agree with the concept of different API for applications and protocol adapters but then I think that protocol adapter support shall contain the senders and  as registry/credentials/tenants >clients.

+1

But the registry/credentials/tenants parts might be even a third client – needs some thoughts.

 

> if you clearly separate applications and protocol adapters support you should probably think about moving some protocol adapter support from HonoClient to ‘protocol adapter client/support’. It >seems cleaner API design and will make HonoClient lighter.

+1

 

Regarding the OSGi related questions, let me respond in a separated mail.

 

Thanks for having started this discussion about the HonoClient which I find quite useful!

 

Mit freundlichen Grüßen / Best regards

Karsten Frank

(INST/ECS4)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY
| www.bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn



From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of Marinov Avgustin (INST/ECS8)
Sent: Dienstag, 14.
August 2018 08:53
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Commands & Control in HonoClient

 

Hi Karsten,

 

> from our point of view we consider applications (implementing any IoT-Use-Case) and protocol adapters (that integrate devices by offering a specific protocol and provide Hono’s Messaging patterns like telemetry or Command and Control for this protocol) to be on different levels.

> 

> Both levels should be as easy to be implemented as possible, but they have different requirements.

>

> Applications are typical clients, and thus are supported by the HonoClient. All applications share the same mechanism to send a command e.g., so the HonoClient is for all different applications the same. The HonoClient should be complete, but as simple as possible.

If the HonoClient is just application oriented then why it provides MessageSender-s (e.g. getOrCreateTelemetrySender, getOrCreateEventSender) as well as registry/credentials/tenants access (e.g. getOrCreateRegistrationClient, getOrCreateCredentialsClient, getOrCreateTenantClient)? Which are completely in scope of protocol adapter. That made me feel that HonoClient is not just about the applications but for the protocol adapters too (which are also kind of clients for Hono server/core. Sorry if my terminology is not correct but  by Hono server/core I mean Hono without adapters).

If you intend to have HonoClient just for applications and as simple as possible I suppose you should provide just message consumers and command client. Or I miss something?

I would agree with the concept of different API for applications and protocol adapters but then I think that protocol adapter support shall contain the senders and  as registry/credentials/tenants clients.

>

> Protocol adapters, however, differ a lot in how they map a command e.g. to the protocol, so they are supported by providing several methods via the AbstractProtocolAdapterBase class.

> These are specifically:

> 

-       createCommandConsumer

-       closeCommandConsumer

-       createCommandResponseSender

-       sendCommandResponse

-       failCommand

> 

> This seems to be more suitable than putting it into the HonoClient, which is not meant for that and would suffer a lot regarding simplicity if we attempted it.

> Additionally, the HonoClient is provided for being used outside of Hono – and a protocol adapter is an essential part of Hono’s internal architecture, even if it is a custom protocol adapter.

I would partially agree with that but the custom protocol adapters (nevertheless part of Hono) could be external entities for Hono server/core, even operated by other vendors. So indeed they are such clients to Hono server/core as the applications. And Hono should provide them with the same level of support – i.e. user (integrator) friendly library for accessing Hono server/core.  

 

 

>> Do you plan to make Commands & Control first level citizen of HonoClient and provide CommandResponseSender and CommandConsumer on the HonoClient level? Or you have chosen to leave >all the low-level implementation to the protocol adapters?

> But I would not call it “low level”, maybe you can be more specific on that?

By low level implementation I meant protocol adapters to handle directly AMQP communication in the way current CommandConsumer and CommandResponseSender does. Basically copying the aforementioned classes.

 

Basically I don’t mind to use org.eclipse.hono.service.commands directly from the hono-service-base but:

·         if you clearly separate applications and protocol adapters support you should probably think about moving some protocol adapter support from HonoClient to ‘protocol adapter client/support’. It seems cleaner API design and will make HonoClient lighter.

·         currently there are problems with using org.eclipse.hono.service.commands in OSGi environment. It is not OSGi enabled (e.g. proper import/export statements in manifest). But the main problem is that it uses implementation classes from hon hono-client which are not exposed via export package.

 

I’d be glad to know what is your opinion about proper content/scope of application API (HonoClient) and protocol adapter API (org.eclipse.hono.service ?).

Also regarding the dependencies between hono-service-base and hono-client.

 

Поздрави / Best regards,

Avgustin Marinov

Engineering Cloud Services Device Manager
(INST/ECS8)
Bosch Software Innovations EOOD | 47B Tsarigradsko Shose | Sofia 1124 | BULGARIA
| www.bosch-si.com
Tel. +359 2 9055801 | Mobile +359 889 464664 | Fax +359 2 9532617 | Avgustin.Marinov@xxxxxxxxxxxx



From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of Frank Karsten (INST/ECS4)
Sent: 13 август 2018 г. 18:08
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Commands & Control in HonoClient

 

Hi Avgustin,

 

> as far as I see the HonoClient provides only support for backend apps to send commands (CommandClient) upstream to protocol adapters. However, there are not facilities for a protocol adapter >to consume commands and to send downstream command responses.

> see such utilities in hono-service-base but they seem to be different level of services (not of the level of CommandClient, MessageSender, RegistrationClient, CredentialsClient).

 

from our point of view we consider applications (implementing any IoT-Use-Case) and protocol adapters (that integrate devices by offering a specific protocol and provide Hono’s Messaging patterns like telemetry or Command and Control for this protocol) to be on different levels.

 

Both levels should be as easy to be implemented as possible, but they have different requirements.

 

Applications are typical clients, and thus are supported by the HonoClient. All applications share the same mechanism to send a command e.g., so the HonoClient is for all different applications the same. The HonoClient should be complete, but as simple as possible.

 

Protocol adapters, however, differ a lot in how they map a command e.g. to the protocol, so they are supported by providing several methods via the AbstractProtocolAdapterBase class.

These are specifically:

 

-       createCommandConsumer

-       closeCommandConsumer

-       createCommandResponseSender

-       sendCommandResponse

-       failCommand

 

This seems to be more suitable than putting it into the HonoClient, which is not meant for that and would suffer a lot regarding simplicity if we attempted it.

Additionally, the HonoClient is provided for being used outside of Hono – and a protocol adapter is an essential part of Hono’s internal architecture, even if it is a custom protocol adapter.

 

 

>Do you plan to make Commands & Control first level citizen of HonoClient and provide CommandResponseSender and CommandConsumer on the HonoClient level? Or you have chosen to leave >all the low-level implementation to the protocol adapters?

 

I think I gave the answer already – we will not support protocol adapters via the HonoClient, but will stay with our abstract base class, which is extended by all protocol adapters.

But I would not call it “low level”, maybe you can be more specific on that?

 

If there are any questions, remarks or improvements – please do not hesitate to ask and discuss, or even provide a pull request or write an issue!

 

I hope I could help you with your question…

 

 

 

Mit freundlichen Grüßen / Best regards

Karsten Frank

(INST/ECS4)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY
| www.bosch-si.com


Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn

From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of Marinov Avgustin (INST/ECS8)
Sent: Montag, 6. August 2018 13:28
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: [hono-dev] Commands & Control in HonoClient

 

 

Hi all,

 

as far as I see the HonoClient provides only support for backend apps to send commands (CommandClient) upstream to protocol adapters. However, there are not facilities for a protocol adapter to consume commands and to send downstream command responses.

I see such utilities in hono-service-base but they seem to be different level of services (not of the level of CommandClient, MessageSender, RegistrationClient, CredentialsClient).

 

Do you plan to make Commands & Control first level citizen of HonoClient and provide CommandResponseSender and CommandConsumer on the HonoClient level? Or you have chosen to leave all the low-level implementation to the protocol adapters?

 

Personally I think that these facilities shall be available via HonoClient, but I don’t see open issues for adding such support.

Поздрави / Best regards,

Avgustin Marinov

Engineering Cloud Services Device Manager
(INST/ECS8)
Bosch Software Innovations EOOD | 47B Tsarigradsko Shose | Sofia 1124 | BULGARIA
| www.bosch-si.com
Tel. +359 2 9055801 | Mobile +359 889 464664 | Fax +359 2 9532617 | Avgustin.Marinov@xxxxxxxxxxxx


Back to the top