| Re: [hono-dev] Correlation of messages |
Hi Paolo,I agree that copying message-id into the correlation-id is the straight forward case in homogenous systems. But in this case, I think that setting correlation-id on the requester side will give us a bit of flexibility to support different clients and environments. And I can’t see any obvious drawbacks so far.On Fri, Jun 24, 2016 at 2:24 PM, Paolo Patierno <ppatierno@xxxxxxxx> wrote:In my experience I have seen the AMQP request/reply implemented always with the messageid (set at requestor) copied into the reply correlationid (set at responder); it's also the default way in the "great" EIP book :-)
We know that JMS doesn't provide the way to set the messageid (but only the correlationid). Do you think that is so important for an application specifying the messageid and don't use the automatically generated by the library (as JMS client works) ?
Tha main point is that JMS should allow to retrieve the messageid for a message sent so that the application can handle the correlation on reply.
Of course the AMQP specification doesn't impose anything on the way to use.
Paolo.
Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
From: dejanb@xxxxxxxxxxxx
Date: Fri, 24 Jun 2016 13:43:47 +0200
To: hono-dev@xxxxxxxxxxx
Subject: Re: [hono-dev] Correlation of messagesHi Kai,I’m +1 for using correlation id pattern here. It doesn’t impact anything fundamentally (it’s not jms related), and leaves option for implementations that want to use message ids, to set them as correlation ids if they want to.On Thu, Jun 23, 2016 at 5:08 PM, Hudalla Kai (INST/ESY1) <Kai.Hudalla@xxxxxxxxxxxx> wrote: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
> dominik.guggemos@xxxxxxxxxxxx
>
> Registered office: Berlin, Register court: Amtsgericht
> Charlottenburg, HRB 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> >
> > -----Original Message-----
> > From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@eclipse
> > .org] On
> > Behalf Of Hudalla Kai (INST/ESY1)
> > Sent: Thursday, June 23, 2016 4:16 PM
> > To: hono-dev@xxxxxxxxxxx
> > 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
> > 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
> _______________________________________________
> 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
_______________________________________________
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
--
_______________________________________________ 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
_______________________________________________
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
--