On 22/04/14 19:27, dnwe wrote:
On 22/04/14 08:26, Fraser Adams wrote:
I'm sure others with more detailed knowledge of the background would be
able to give a better answer, but in short I think the thing that you
need to bear in mind is that proton Messenger is a *Message* oriented
API as opposed to a *Connection* oriented API, so for example compare
the approach taken with Messenger with say the qpid::messaging API and
JMS which are both Connection oriented APIs (where you specify
Connection, Session etc.).

Messenger is supposed to abstract the (client) user from needing to care
about such things, so you specify the address that you want to send a
Message to in the Message and let Messenger take care of the Connection
and Session stuff.
The benefit of having Messenger quietly handle the connection, session
etc. certainly makes sense once the client is up-and-running, as it nicely
allows for automatically re-establishing links and re-authenticating as
appropriate. However, being able to do a simple initialization check at
application startup would be equally beneficial - "are any of my possible
endpoints available?" and "do I have valid authentication credentials that
would allow me to connect?" would be fail-fast scenarios that we would be
keen to support. This need not necessarily be available via an explicit
pn_messenger_connect api call, but could be a use case provided by some
other means.


The folks behind the design of the API would certainly give a more definitive response than me (hopefully Rafael Schloming will be able to respond) but TBH I think that you are starting to get into the realm of *application* versus API. As I said previously if you are really looking to build on a connection oriented API then I think that you probably ought to look more to qpid::messaging as this is probably more along the lines of what you sound like you want/need.

There are probably possibilities of some (slightly hacky) approaches such as establishing a subscription (consumer connection) to a non-existant node e.g. amqp://<host>:<port>/mq-light. I've not tried this, but I *think* that it will create a connection to the server at host:port and wait for messages to be published to the mq-light node, which could be a dummy node that will never receive messages. That would establish the physical connection before any messages have been sent (.... I think :-[ ). As AMQP 1.0 Management evolves another option might be to "ping" the container's Management Node, though that's not widely supported at the moment (the Java Broker and the dispatch router have started to implement AMQP 1.0 Management features, but the C++ broker hasn't yet). As I say these approaches are a bit hacky, but possibly better than pretending Messenger is connection oriented at the API level.

Ultimately proton Messenger and qpid::messaging are essentially "peer" APIs, that is to say they offer largely similar capabilities from the point of view of message delivery, but they have different perspectives, so (again IMHO) I'd say you'd be best backing the horse that suits your particular turf, if you pardon the racing analogy.

Incidentally it might be worth your while posting to us...@qpid.apache.org. That mailing list is the broader Qpid users mailing list and quite possibly has a wider readership than proton@qpid.apache.org although clearly your questions have been Messenger-centric you might get a more diverse set of responses if you pitch there - I think that most of the proton folks subscribe to that list, but not necessarily the other way round.

Best regards,

Reply via email to