| 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
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Marinov Avgustin (INST/ECS8) 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,
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Frank Karsten (INST/ECS4) 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
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Marinov Avgustin (INST/ECS8) 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,
|