qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject We've got an App for that .... Qpid Web Based GUI - and more - just released.
Date Sun, 20 Jan 2013 16:26:18 GMT
For those of you who follow my postings on the Qpid Mailing List you'll 
probably be aware that I've been doing quite a lot with QMF2.


I've just made a fairly major uplift to the QMF2 code base.

https://issues.apache.org/jira/browse/QPID-3675


There are a few bug fixes to the core Java QMF2 implementation, the most 
significant being that the ManagementAgent can return multiple partial 
responses if there are large numbers of objects, the QMF2 getObjects() 
call now caters for that.

However the most significant uplift is the addition of:
1) A QMF2 REST API Implementation.
2) A JavaScript QMF2 Implementation that uses the REST API as a back end.
3) A fully featured Qpid Management Web GUI that does pretty much 
anything you'd need to do to
monitor and manage one or more brokers (it supports connecting to 
different brokers).

The REST and JavaScript QMF2 implementations are fairly complete, the 
main thing missing is support for QMF2 Query Subscriptions, which are 
supported in the Java API but I've not got round to adding them to REST 
& JavaScript versions.

The JavaScript implementation uses AJAX to talk to the REST API, this is 
mainly because that approach is supported on pretty much every browser. 
I might look to adding WebSocket support IDC when I've got a bit more 
familiarity with WebSockets.


The Web GUI works on multiple browsers and is even functional on IE6 
:-), it morphs quite well onto mobile devices and uses GPU accelerated 
animations to give a fairly "native app" feel on iPad/iPhone.

The REST API Server was deliberately designed to have almost no 
dependencies. It uses the com.sun.net.httpserver.HttpServer embedded Web 
Server that is part of JDK 6 (at least on Sun and OpenJDK) so just 
requires the Qpid jars on the classpath. It has been designed to make it 
fairly easy to add a Servlet implementation, but that's not been done 
yet as the initial goal was to make it fairly dependency free and embedded.

The REST API is very RESTful and uses PUT to add Qpid Connections but 
there is automatic creation of a "default" resource if one tries to do a 
GET so for example doing:

http://<host>:8080/qpid/connection/default/console/objects/queue

will retrieve the latest update of the QMF queues as a JSON string, 
which will parse into a list of QmfConsoleData objects. The QpidServer 
class JavaDoc documents the complete REST API but hopefully the example 
above should give the gist (that's the REST equivalent of 
getObjects("queue") in case it wasn't obvious).


To get up and running all that should be required is the Qpid jars on 
the classpath and running ant in the root qmf2 directory.


Once compiled cd to bin and do ./QpidRestAPI.sh by default it tries to 
bind to the
wildcard address on the host it's running on and port 8080 though this 
stuff is configurable.

Point a browser at <host>:8080 and you should be in business. By default 
it will create a default QMF connection to a broker running on the same 
host as the QpidRestAPI on port 5672 but the default broker connection 
is configurable too.

Once running you can add QMF2 Console Connections to other brokers and 
connect to them via the Web GUI.

The main limitation at the moment is the authentication. It uses basic 
authentication so username/password are sent clear. I'll look to do 
something better IDC but I wanted to get it released as it represents 
around a years worth of work over weekends.

the authentication file is in 
qmf2/bin/qpid-web/authentication/authentication.properties and has the 
traditional
admin=admin
guest=guest

Obviously you might want to change that :-) it supports dynamic changes 
to the file.

FWIW although the Web GUI doesn't yet have better authentication it 
should be possible to configure the QpidRestAPI to use a default 
connection to a secure broker. The broker credentials for the default 
broker aren't returned to the browser - to use the defaults it just 
supplies a broker URL of "". Obviously the broker management statistics 
will still be being sent over an unsecure channel but that may not be an 
issue in many cases.



It's all released under the Apache Licence and the GUI uses a JavaScript 
UI library that I ended up writing as part of this project (called 
itablet) which should be reusable in other projects.


I hope that this is useful to people, as I say it's taken an awful lot 
of effort to put together, so I'd *really* appreciate feedback.


I should point out that this is QMF2 based and so it can only talk to 
the C++ broker at the moment, however if people are interested and the 
feedback is positive I'll look to uplifting the back end to also proxy 
to the JMX mechanism used by the Java broker. I must admit that I've not 
got any real familiarity with the Java broker, but it ought to be 
do-able assuming that the Java broker JMX Management Objects have 
similar capabilities to the C++ QMF Management Objects.

Finally if you point it at a broker less than 0.10 the add/delete 
queue/exchange/binding features won't work as they require broker object 
create/delete methods that were added in 0.10.

I've attached a couple of screen shots of a few different pages on a few 
different browsers to pique your interest :-)


I really hope that the QMF stuff can make it into the main Qpid release 
at some point, I did the first Java QMF2 API release over a year ago but 
I've not had much feedback, hopefully with the addition of a management 
GUI it'll get a bit of traction?

Best Regards,
Frase





Mime
View raw message