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.
Cheers,
Dom
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,
Frase
