[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Hono JMS adapter
|
I think you're right in general. And I also think that we are pretty
much following that pattern. On the other hand, if nobody can consume
our APIs due to the lack of (working) AMQP 1.0 clients then we have a
problem. At the moment I have the feeling that the Qpid JMS client is
one of the more stable clients to be used (from within Java at least)
and there exists a lot of support for JMS in other frameworks (e.g.
Spring) as well. So, ruling out the use of JMS clients from the very
beginning doesn't seem like a very smart move to me.
So, when we are discussing multiple options of implementing/specifying
stuff and we feel that both ways are ok and makes sense, then I think
going for the one that is also compatible with JMS is justified. On the
other hand, if we feel that in order to make it work with JMS as well
we would need to do something completely stupid and/or technically not
feasible then we should consider dropping JMS support.
In the case of correlating responses with requests I do not see that we
are doing anything JMS specific. To the contrary, this pattern has been
around ages in IBM's MQ before JMS was even born ... If the Qpid JMS
client is not able to support this pattern then I would simply consider
this a bug in Qpid JMS that needs to be fixed and that's it :-)
--
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
On Do, 2016-06-23 at 14:44 +0200, Dejan Bosanac wrote:
> Hi,
>
> I’ve been chatting with Dominik a bit on IRC about request-reply
> patterns in JMS and the issues that will impose on the Hono API. It
> struck me at the moment that we’ve been influencing a lot of the API
> lately with the limits of JMS API and clients we have available. It
> seems to me that it might be a better long term solution to keep Hono
> API focused on the things it needs to do and natural to AMQP
> protocol, and deal with these JMS compatibilities issues in an
> adapter of some kind (in a similar fashion we’ll deal with other
> protocols over time).
>
> What do you guys think about this? It’d be good to have this sorted
> before we go further in changing the API.
>
> --
> Regards
> --
> Dejan Bosanac
> about.me/dejanb
> _______________________________________________
> 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
