-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protocol Gateway Template and Example #1964
Conversation
I am wondering if this should go into the main repository, or maybe go to some "extras" repository. Maybe even a dedicated "demo-gateway" repository, which can be flagged in GitHub as "template repository". |
I am open to moving this to a separate repository. I don't know of any decisions yet regarding whether to create multiple repositories or continue to keep everything in the main repository. I also found this repository: https://github.com/eclipse/hono-extras but don't know what it is intended for. |
@b-abel can you fix the JavaDoc that prevents the Travis build to succeed? |
@sophokles73 I don't see a JavaDoc error in the latest Travis run, but an error with pulling docker images. (After the first commit there was a JavaDoc error, which I have already fixed). Or am I missing something? |
ah, you have renamed the PR ... I was under the impression that there are two separate PRs. My bad ... |
I added tests for the base class. I would add a little bit of documentation (Developer Guide for the template) and a small unit test for the Azure example. |
It looks like the new checkstyle configuration from master is used by Travis causing the build to fail. What are we going to do? Rebase? |
…devices via MQTT and forwards them to the AMQP adapter. And vice versa. This is implemented in the new Maven module "hono-sdk". It also adds an example implementation in the "hono-example" module, the "Azure IoT Hub Protocol Gateway". Demo certificates are now created for the latter. Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
…ADME. Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Adds package-local methods to verify subscriptions and TLS options in AbstractMqttToAmqpProtocolGateway. Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Change the visibility of MQTT endpoint handlers to private. In tests they can be invoked with (mocked) MQTT messages. The tests are improved because they are more decoupled from the implementation and the public interface is tested. Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
…mentation. Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
06629cb
to
6e74d0a
Compare
Force pushed to get rid of the checkstyle problems. |
@ctron I just realized that you probably meant the existing "hono-extras" repository. I agree that having this protocol gateway example in a separate repository is a good idea. How can I add it there? |
custom_http_adapter.md and java_client_consumer.md had conflicting weights. Move custom_http_adapter.md to the (current) bottom of the list. Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
@b-abel @ctron I also believe that this should go into the hono-extras repository. One of the reasons is that I do not want people to think of it as an official component which gets the same level of support as the protocol adapters. I also do not want to foster expectations that we will add more protocol gateways over time. This should simply serve as an example project that people can take or leave. WDYT? |
@sophokles73 I agree that this should be in a separate repository, for the reasons you mentioned. And I don't see why we wouldn't want to use hono-extras for it. I'm happy to turn the PR against this repo. The question is whether there are already ideas about the directory structure there. And who does the review? |
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
…rConfig. Rename `AbstractMqttToAmqpProtocolGateway` to `AbstractMqttProtocolGateway` which expresses more clearly what s important and removes the secondary information that it connects to the AMQP protocol adapter. Rename `MqttGatewayServerConfig` to `MqttProtocolGatewayConfig` because it no longer contains only server configuration. Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Applied the changes in the CommandSubscriptionsManager of the MQTT adapter to the CommandSubscriptionsManager of the protocol gateway to keep them similar. Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
…ACK). Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
...-protocol-gateway-example/src/main/java/org/eclipse/hono/example/protocolgateway/Config.java
Show resolved
Hide resolved
@b-abel FMPOV the directory structure in the hono-extras is simple: one top level folder per extra. I do not think that we should have a single multi-project build but instead each top level folder should contain its own build. We also will need this because not every extra will be Java/Maven based. So I can imagine to use azure-mqtt-protocol-gateway as the top level folder name here. However, I think we should/could keep the additional demo cert in Hono's code base but maybe rename it to allow for it to be (re-)used more easily, i.e. without tying it to azure so tightly. WDYT? |
@sophokles73 Thank you for your feedback! Should I create the new PR in Hono-Extras now, or are we waiting for a statement from @ctron? Do you only want to move the Azure IoT Hub Protocol Gateway, i.e. the sample implementation of the template, to hono-extras, or do you want to move the template itself? As far as the directory structure is concerned: what you wrote makes total sense. We should probably keep the number of items (directories) at the top level of the repository as small as possible for ease of reference. How about a top-level protocol gateway directory to prepare for when another protocol gateway project is added in the future? That would be just to organize similar projects, each protocol gateway project should contain its own build. WDYT? You're right, the certificate should generally be issued much better for a gateway. |
…-gateway). Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
IMHO you should create the new PR. No need to wait, as @ctron already has proposed to move it to hono-extras.
I think we should move everything.
I do not expect nor want to maintain additional protocol gateways. This single one should be sufficient as an example for how to use the template, shouldn't it? |
Of course, is a single example for the usage of the template enough. I had other protocol gateways in mind (which do not use MQTT). So the top-level directory would be protocol-gateway and contain (1) the template, (2) the azure-mqtt-protocol-gateway. In the future, other protocol gateways (potentially written in another language and using other protocols) might or might not be added in this top-level directory as well. I will create new PRs and then close this one. |
Replaced by a new PR on the hono-extras repository: eclipse-hono/hono-extras#3. |
Implementing a production-ready protocol gateway currently involves a considerable effort and requires advanced knowledge of Hono and AMQP 1.0 (in addition to knowledge of the device-side protocol).
To simplify this, a useful example would be helpful.
What I have implemented here is two things:
Challenges for a generic usage of Hono with MQTT are:
For the last point, there are 3 strategies on how to get the two IDs from the command into the response:
Correlation of command responses
There is no simple generic solution for this. When the values are sent to the device (1. and 2.), the device must support this and add the correct data to the response in the required manner. The 3rd strategy has the disadvantage that the protocol gateway cannot simply be scaled horizontally.
The base class is designed to leave this to the concrete implementation.
The Azure IoT Hub sample implementation uses the 1st strategy because the API implemented there contains a corresponding attribute that can be used for this purpose. Since Hono's Command & Control API requires two values for correlation, they are encoded into this one attribute and decoded accordingly on the way back.
The template supports multitenancy. For this to work, the subclass must determine the credentials of the corresponding gateway device for each connection establishment by a device.
The protocol gateway then uses these credentials to authenticate a new client to the AMQP adapter if the connection does not already exist for this client (because of already connected devices).
The template does not support unauthenticated device connections, but the authentication is performed by the derived class and could be skipped there.
Authentication is implemented here only exemplarily for a configurable demo device. This allows the protocol gateway to be tested against Hono's sandbox or any other Hono installation with minimal effort.
I will provide documentation and tests later.