Skip to content
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

Closed
wants to merge 21 commits into from

Conversation

b-abel
Copy link
Contributor

@b-abel b-abel commented May 15, 2020

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:

  1. a template in the form of an abstract base class that provides a protocol gateway that offers MQTT on the device side and connects northbound to the AMQP adapter while being as generic as possible.
  2. a ready-to-use example implementation that shows how this base class can be used in practice. The use case of this example is a protocol gateway that offers the MQTT API of the Azure IoT Hub and passes these messages to Hono.

Challenges for a generic usage of Hono with MQTT are:

  • Topics are freely selectable in MQTT and may or may not contain all kinds of information
  • MQTT doesn't have metadata
  • for a command response several values must be sent back from the command with the response (requestId and CorrelationId)

For the last point, there are 3 strategies on how to get the two IDs from the command into the response:

  1. encode them into the topic and have the device send them back
  2. encode them into the payload and have the device send them back
  3. keep them in the protocol gateway and add it to 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.

@b-abel b-abel requested a review from sophokles73 as a code owner May 15, 2020 18:57
@b-abel b-abel changed the title Adds a base class for a Protocol Gateway that receives messages from … Protocol Gateway Template and Example May 18, 2020
@ctron
Copy link
Contributor

ctron commented May 18, 2020

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

@b-abel
Copy link
Contributor Author

b-abel commented May 18, 2020

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.

@sophokles73
Copy link
Contributor

@b-abel can you fix the JavaDoc that prevents the Travis build to succeed?

@b-abel
Copy link
Contributor Author

b-abel commented May 19, 2020

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

@sophokles73
Copy link
Contributor

ah, you have renamed the PR ... I was under the impression that there are two separate PRs. My bad ...

@b-abel
Copy link
Contributor Author

b-abel commented May 29, 2020

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.

@b-abel
Copy link
Contributor Author

b-abel commented May 29, 2020

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?

b-abel added 9 commits June 4, 2020 15:41
…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]>
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]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
@b-abel b-abel force-pushed the mqtt_protocol_gateway branch from 06629cb to 6e74d0a Compare June 4, 2020 13:57
@b-abel
Copy link
Contributor Author

b-abel commented Jun 4, 2020

Force pushed to get rid of the checkstyle problems.

@b-abel
Copy link
Contributor Author

b-abel commented Jun 5, 2020

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

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

b-abel added 2 commits June 8, 2020 11:27
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]>
@sophokles73
Copy link
Contributor

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

@b-abel
Copy link
Contributor Author

b-abel commented Jun 9, 2020

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

b-abel added 5 commits June 9, 2020 11:32
…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]>
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]>
b-abel added 4 commits June 15, 2020 09:30
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
Signed-off-by: Abel Buechner-Mihaljevic <[email protected]>
@sophokles73
Copy link
Contributor

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

@b-abel
Copy link
Contributor Author

b-abel commented Jun 16, 2020

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

@sophokles73
Copy link
Contributor

Should I create the new PR in Hono-Extras now, or are we waiting for a statement from @ctron?

IMHO you should create the new PR. No need to wait, as @ctron already has proposed to move it to hono-extras.

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?

I think we should move everything.

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?

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?

@b-abel
Copy link
Contributor Author

b-abel commented Jun 16, 2020

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.

@b-abel
Copy link
Contributor Author

b-abel commented Jun 22, 2020

Replaced by a new PR on the hono-extras repository: eclipse-hono/hono-extras#3.

@b-abel b-abel closed this Jun 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants