Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Apche Camel Hono Component

Hi Caroline,


please do not confuse Kapua with Kura. The link you provided describes how Camel can be used to implement an application deployed to Kura (the gateway). As such, Marc's Camel component could potentially be used to connect a Kura instance to Hono directly. Integration of Hono and Kapua (on the back end side where Kapua is running) should be done on a "lower level" FMPOV.


On 04.09.2017 13:22, Buck Caroline (INST/PRM) wrote:

 

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

Caroline Buck

Product Management (INST/PRM)
Bosch Software Innovations GmbH | Ziegelei 7 | 88090 Immenstaad | GERMANY
| www.bosch-si.com
Tel. +49 7545 202-229 | Fax +49 7545 202-301 |
caroline.buck@xxxxxxxxxxxx

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn



Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im Auftrag von Pellmann Marc (INST/ECS4)
Gesendet: Montag, 4.
September 2017 12:06
An: hono developer discussions <hono-dev@xxxxxxxxxxx>
Betreff: Re: [hono-dev] Apche Camel Hono Component

 

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

Marc Pellmann
INST/ECS4

Tel.
+49 30 726112-132

From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] On Behalf Of Maas Ingo (INST/ECS4)
Sent: Montag, 4. September 2017 11:51
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Apche Camel Hono Component

 

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

www.bosch-si.de

 

Tel. +49 30 726112-156

Fax +49 30 726112-100

ingo.maas@xxxxxxxxxxxx

 

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>
Gesendet: Sonntag, 3.
September 2017 15:34
An:
hono-dev@xxxxxxxxxxx
Betreff: [hono-dev] Apche Camel Hono Component

 

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

 

marc.pellmann@xxxxxxxxxxxx

 

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B

Executives: Dr. Ing. Rainer Kallenbach, Michael Hahn

 



_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev

-- 
Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr.-Ing. Rainer Kallenbach, Michael Hahn


Back to the top