Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Correlation of messages

From an outsider perspective, this conversation represents two bad ideas.

If HONO is serious about the trends and future of IoT and not just serving the legacy vendors,  This would be MQTT based and everything else would be binding to it.


Aaron Allsbrook | CTO
Mobile : +1(919)614-0231  
Email : aallsbrook@xxxxxxxxxxxxxx
103 E. 5th Street | Austin, TX 78701
Skype :  aaron.allsbrook | Gtalk : aaron.allsbrook

CLEARBLADE
Engineering the Connected World


From: <hono-dev-bounces@xxxxxxxxxxx> on behalf of "Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>
Reply-To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Date: Thursday, June 23, 2016 at 10:08 AM
To: "hono-dev@xxxxxxxxxxx" <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Correlation of messages

On Do, 2016-06-23 at 14:31 +0000, Guggemos Dominik (INST/ECS1) wrote:
Initially we designed the API to support the Message ID Pattern as
this seems to be the preferred way to do this with AMQP 1.0. Maybe
someone can confirm or disconfirm this? And this is how I implemented
the request/response messages for the Device Registration API. Now I
came across the fact that I cannot set an arbitrary message id using
the Qpid JMS Client and read in the JMS specification, that the
Message ID is generated by the client and not meant to be set by the
user. The recommended way to do request/response with JMS is the
Correlation ID Pattern.
You do not necessarily need to set the message ID explicitly as long as
you are able to get to know about the message ID the JMS provider has
used to send the message, right? In fact, the JMS provider in this case
makes sure (is required by the spec) to create a globally unique ID for
you ... if Qpid JMS client does not provide a way for the client to get
to know about the message ID then I consider this a bug (as already
stated) which needs to be fixed.

Actually I do not prefer the one over the other, but I'm currently
facing the question if we change the API and implementation to switch
to the Correlation ID pattern to be compatible with JMS? So we are
somehow back to the discussion "to JMS or not to JMS".
Neither do I :-) I found a post on stack overflow [1] regarding this as
well and there is one answer arguing in favor of Correlation ID pattern
due to the fact that - guess what - not all JMS clients provide access
to the used ID :-)

So, can we then conclude that we want to use the Correlation ID
pattern?

Mit freundlichen Grüßen / Best regards
Dominik Guggemos
Bosch Software Innovations GmbH
Engineering Cloud Services (INST/ECS1)
Ziegelei 7
88090 Immenstaad
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Tel. +49 7545 202-396
Fax +49 7545 202-301
Registered office: Berlin, Register court: Amtsgericht
Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> -----Original Message-----
> .org] On
> Behalf Of Hudalla Kai (INST/ESY1)
> Sent: Thursday, June 23, 2016 4:16 PM
> Subject: [hono-dev] Correlation of messages
>
> Hi,
>
> in order to not confuse the discussion around "to JMS or not to
> JMS"
> from the technical question how we want to implement message
> correlation, can
> somebody describe the current state of affairs?
>
> @Dominik: are you planning to use Correlation ID or Message ID
> pattern for
> correlation, i.e. is the client expected to generate an ID and set
> it explicitly as the
> value of the correlation-id field in the request with the receiver
> then copying its
> value to the response (former case) or do you prefer to have the
> receiver copy the
> value of the message-id property from the request to the
> correlation-id in the
> reponse (latter case)?
>
> --
> 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, Register court: Amtsgericht
> Charlottenburg, HRB 148411
> B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> _______________________________________________
> hono-dev mailing list
> To change your delivery options, retrieve your password, or
> unsubscribe from this
_______________________________________________
hono-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
_______________________________________________
hono-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit


Back to the top