qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Using the messenger API to connect to a server without sending or subscribing
Date Tue, 22 Apr 2014 18:52:21 GMT
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 
users@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








Mime
View raw message