| Re: [hono-dev] Apche Camel Hono Component |
|
Hi Caroline, what is provided with the Camel endpoints are just the possibility to communicate with Hono directly from Camel routes. My initial thoughts
where more in the direction of direct adapters and consumers, but as always - this could open other possible applications. If the idea is to use Hono as the first citizen messaging infrastructure for Kapua, I am not sure that an integration with Camel routes
is the best possible solution. Mit freundlichen Grüßen / Best regards Marc Pellmann Bosch Software Innovations GmbH INST/ECS4 Schöneberger Ufer 89-91 10785 Berlin GERMANY Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B Executives: Dr. Ing. Rainer Kallenbach, Michael Hahn From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx]
On Behalf Of Buck Caroline (INST/PRM) Hi Marc, since there is an existing integration of Eclipse Kapua with Apache Camel (see,
https://eclipse.github.io/kura/camel/kura-camel-app.html), would your suggested component be a way to integrate the Eclipse Hono with Eclipse Kapua, e.g. for event forwarding from Hono to
Kapua (or vice versa)? Mit freundlichen Grüßen / Best regards
Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Pellmann Marc (INST/ECS4) Hi Ingo, thanks for your feedback! I agree that the main purpose is to have fast (in terms of complete it) solutions on the adapter side for protocols, that already exist for Camel. It is not the
idea to e.g. use it as our standard REST adapter, since the Camel engine will always have some overhead. But on the other side a few hundred messages per second is not a problem for the Camel based REST solution – so it might be good for customer specific
REST adapters. On the consumer side there will also be the application logic of the solution itself and it will often be created for specific projects – so this fits well, I think. Mit freundlichen Grüßen / Best regards
From:
hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx]
On Behalf Of Maas Ingo (INST/ECS4) Hi Marc, Apache Camel is great for integration tasks, offering a broad choice of protocols. On the other hand, the focus of Hono is more on (high performance) messaging. That said, I think, Camel may be an option when performance is not an issue and support for a not so common protocol is required. Kind regards,
Ingo Maas Bosch Software Innovations GmbH INST/ECS4 Schöneberger Ufer 89 - 91 10785 Berlin GERMANY Tel. +49 30 726112-156 Fax +49 30 726112-100 Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B Executives: Dr.-Ing.
Rainer Kallenbach, Michael Hahn Von:
hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
im Auftrag von Pellmann Marc (INST/ECS4) <Marc.Pellmann@xxxxxxxxxxxx> Hi, I created a first prototype version of an Apache Camel component for Hono. I think this could help a lot on both sides – adapters and solutions. In theory this could also be done with the JMS based AMQP component – but this is not easy – especially on the adapter side, e.g. with the assertion
mechanism. Also the overhead of JMS is not ideal and with a component based directly on Hono it will be easy to encapsulate future additions. The Camel Component for Hono makes it very easy to integrate protocols on the adapter side, which are already available as Camel components. As an
example I used the PubNub component to forward events to Hono, and also provided the REST endpoints from the REST adapter as a route. On the consumer/solution side it will be very easy to implement e.g. store and forward semantics or filtering with Camel and also it is less complex
to use such a client for many people. The producer part is based on the AbstractProtocolAdapterBase and the consumer on the Hono client. So it reuses as much as possible from our existing
code. And I think our asynchronous model fits very well with Camels asynchronous routing engine. The adapter based on Camel is also very similar to the other adapters in regards to configuration and being a Spring Boot app (and a Docker image).
For the example of the solution app, this is the same, but I think on this side it is important to allow different usages and also different configuration options so it could be used from any Java application. WDYT? Mit freundlichen Grüßen / Best regards Marc Pellmann Bosch Software Innovations GmbH INST/ECS4 Schöneberger Ufer 89-91 10785 Berlin GERMANY Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B Executives: Dr. Ing. Rainer Kallenbach, Michael Hahn |