Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Hono JMS adapter

Thanks Dejan for pointing out the main JMS limitations which Hono development is facing (with the Dominik work).

Kai, I know that "Hono's API IS based on AMQP 1.0. Nobody question's this AFAIK." but considering the difference between JMS and AMQP, an API vs a protocol, building an AMQP based API with limitations of another API (JMS) means limiting the underlying protocol features and related potential.

I'm just saying to think only in the AMQP way for building the API. If starting using a client, for example JMS client, something can't be implemented in the right AMQP way, an adapter (like Dejan suggested) could be good (like for HTTP, MQTT, ...) or in some other cases, as you said, it could be a bug to fix in the client itself.

I completely agree on Vert.x Proton as the Java reference client but at same time, as I already said during the meeting, the developers experience is one of the points for the success of a new platform. As Dejan mentioned, I think that an Hono client library (like a wrapper around the Vert.x Proton) could be a great idea. It's valid for all other programming languages (i.e. using AMQP .Net Lite for .Net oriented clients, RHEA for _javascript_ oriented clients and so on).

This is the story for example from Microsoft and Amazon for their IoT platforms (but it's the way a lot of companies think) which offers client SDK as wrapper around the underlying protocol and API (AMQP for MS, MQTT for Amazon). Of course you have the freedom to choose to interact at low level directly with the protocol so against the API definition.

Paolo

Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor 

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience



From: dejanb@xxxxxxxxxxxx
Date: Thu, 23 Jun 2016 16:33:23 +0200
To: hono-dev@xxxxxxxxxxx
Subject: Re: [hono-dev] Hono JMS adapter

Hi Kai,

I was referring to the things we were already discussed, like not being able to use different link and message addresses for producers and hyphens for ids and now correlations. It’s getting into the design decision more and more.

I see your point on the importance of the JMS on the data services side, but I’m not quite convinced that long term JMS should be something we should aim for (I’m not a big fan of Spring JMS to be honest for example). Vert.x Proton is a decent client and we can work to make it stable and feature complete (SASL support, etc.).

In my opinion (and I think I raised this before) the ideal case for Java world would be to provide a client library with Hono specific API that would give developers better experience.


On Thu, Jun 23, 2016 at 4:10 PM, Hudalla Kai (INST/ESY1) <Kai.Hudalla@xxxxxxxxxxxx> wrote:
On Do, 2016-06-23 at 13:02 +0000, Paolo Patierno wrote:
> Hi,
>
> as already said in the chat with Dejan and Dominik, we already
> decided (during the meeting) that Hono will be fully AMQP based so
> the related API as well.
> As specification, JMS isn't related to AMQP (they are on different
> abstraction layers) even if we have a JMS client which uses AMQP as
> underlying protocol but in order to adhere the specification
> introduces some limitations.
> I don't think that it could be a good idea to introduce such
> limitations in Hono.
>
Can somebody enlighten me regarding the "limitations" you guys seem to
anticipate?

> So I agree on handling JMS compatibility with an adapter but leaving
> Hono API more AMQP oriented.
>
Hono's API IS based on AMQP 1.0. Nobody question's this AFAIK.

> Regards,
> Paolo
>
> Paolo Patierno
> Senior Software Engineer (IoT) @ Red Hat
> Microsoft MVP on Windows Embedded & IoT
> Microsoft Azure Advisor 
>
> Twitter : @ppatierno
> Linkedin : paolopatierno
> Blog : DevExperience
>
>
> From: dejanb@xxxxxxxxxxxx
> Date: Thu, 23 Jun 2016 14:44:43 +0200
> To: hono-dev@xxxxxxxxxxx
> Subject: [hono-dev] Hono JMS adapter
>
> 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.or
> g/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



--
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

Back to the top