Re: "I like the decoupling that REST provides as it just takes a library
that speaks HTTP. I don't have to link against a vendor-specific
management library nor do I have to carry through their dependencies. "
What you say about REST is indeed true and is a good selling point, but
it's worth bearing in mind that it's *also* true of the approach
illustrated in the examples from Gordon - that approach is using the QMF
*protocol* and in terms of dependencies it is simply using pure AMQP as
a transport passing Map Messages in a request/response pattern to
specific AMQP Destinations, that's arguably no more coupled nor vendor
specific than say using the REST API, even the Java QMF stuff isn't
really coupled as it's implemented as pure JMS. In actual fact it's the
QMF aspects that are vendor specific - QMF is specific to the Qpid C++
broker.
I certainly don't want to dissuade the approach that you're taking, but
you should probably be armed with all the facts - sure you're not
dependent on a library, but as I say above nor are you really dependent
on a library for some of the other approaches (though Gordon's examples
are C++ using qpid::mess
I like the decoupling that REST provides as it just
takes a library that speaks HTTP. I don't have to link against a
vendor-specific management library nor do I have to carry through their
dependencies.
aging) I've not tried raw QMF via Proton Messenger, it might well be
possible though it currently seems to have quite a few limitations wrt.
topic subscriptions (and other filter types).
As I say ultimately QMF is actually your biggest vendor specific
dependency, so that's something that you should keep in the back of your
mind going forward. I expect QMF to be around for quite some time, but
there is certainly a desire to move towards the AMQP 1.0 Management
Specification over time. As we move forward on that I'm sure that there
will be a concerted effort to avoid breaking existing QMF things (I'm
certainly intending to try my best to avoid that) and as I say it's
likely to be some time before traction builds in that direction, but
it's certainly something that you should be cognoscente of if you are
building a mission critical system - put a comment in your code to track
AMQP 1.0 Management developments on this list at the very least.
Hope that this stuff is useful,
Cheers,
Frase
On 28/01/14 19:18, Shearer, Davin wrote:
On Tue, Jan 28, 2014 at 1:39 PM, Fraser Adams <fraser.ad...@blueyonder.co.uk
wrote:
Glad that I was able to help out.
I'm a little bit curious why you're choosing to go with the REST interface
directly? What language are you programming in.
I am programming this piece in C (messaging and transport layer of a larger
system). I am using proton for the AMQP layer and using the REST API for
the broker management. I like the decoupling that REST provides as it just
takes a library that speaks HTTP. I don't have to link against a
vendor-specific management library nor do I have to carry through their
dependencies. I don't want the consumers of the library (be it additional
middle-ware layers or the application-layer code) to be concerned about the
messaging and transport details, just that we moving data reliably from one
end-point to another over a flexible topology.
Not that I've got anything against the REST API, but I mainly put it in
place to be able to talk QMF from a browser environment.
It should work for my needs as well. It took longer than I'd hoped to
package a "reference" broker, but I've managed it.
I've attached a couple of examples put together by Gordon Sim to
illustrate this in C++ the queue_depth is self explanatory, the one marked
example.cpp does something similar to qpid-route - not exactly what you
want for adding a queue, but it illustrates invoking QMF2 methods via the
raw QMF2 protocol and you can use that in conjunction with what I've shown
below on the REST API
I think your REST API will be sufficient provided I request a dynamic queue
with delete on close via REST. If that isn't possible then it could be the
case that there will be abandoned reply queues lingering in the broker if a
client creates one, then dies without removing it. I will review the code
since more information usually leads to better decisions.
It is quite fun doing this stuff via curl, but it's pretty hardcore :-)
I'd *probably* take easier options in Python/Java/C++/JavaScript unless I
wanted to prove a point (clearly REST is handy if you want to mash up info
from lots of different sources in a web app).
The commandline curl stuff is to understand the API, get my URLs right and
to test the behaviour before writing it up in C using libcurl.
BTW in case you are curious the reason that the URI's are relatively
complex e.g.
GET http://127.0.0.1:8080/qpid/connection/default/console/objects/queuerather
than say
GET http://127.0.0.1:8080/qpid/console/objects/queue
Is because it's perfectly possible to PUT an arbitrary number of QMF
Console connections and access them independently so the GUI can talk to
multiple discrete Consoles and I can have multiple browser instances served
by the same REST API instance.
I think the flexibility that provides is worth the price in complexity. I
only have to get it right once, then it's in my library and I'll build on
top of that. :-)
I hope that helpful and that it made sense...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
