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
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