Hi gentlemen,
I'm architecturing a new opensource project around asterisk PBX and Restlet
to offer a RESTFull view of an asterisk server (or cluster of *).
I've got a working server and already use it in production servers for
monitoring, clustering
and call distribution purposes for our customers but I'm now facing
architecture choices
for making user interfaces for various clients technology.
I've choosen first to implement an ajax inerface to it for demonstration
purposes
so I quickly wrote several Quick&Simple samples using jQuery.
But looking at the bandwith used by exchanges between client and Restlet
server I quickly see the limits
for this 'polling' approach (for example a simple queues management
console for monitoring several asterisk
servers's calls queues are around 3 request/s and even if each grab 1-5
ms of time
to serve the approach will push linearly on the server as the client
augment * by the polling frequency)
I can quickly conclude that a generic console that will show you all
your company phones
status multiplied by the number of people watching them is a dead end
solution
(think about 500 users watching each other phones and how this scale)
So I looked around for a comet implementation of this with Restlet but
after following
the full circle beginning with Grizzly cometd/bayeux implementation, I
came to the
"Support asynchronous processing"
http://restlet.tigris.org/issues/show_bug.cgi?id=143 RFE
And the thoughts about how to solve this synchronous -> asynchronous
dilemma using futures
but when I then looked at my concern as outlined by this :
(* server publishing internal events) -> my server events listeners ->
Rest representation <- Restlets <- (polling synchronous ajax requests)
and the ideal view of it from a bayeux enabled client outlined as this :
(browser with for example dojo like bayeux client) -> subscribing to
'events/changes' -> Rest representation coupled with trigers events
coming from my internal events listeners <- my server listeners <- (*
server publishing internal events)
where everything is asynchronous but then I loose my REST interface in
the middle.
Then I came with the following I would like an advice for you wise guys ;-)
What if I use a staggering approach ?
Where I could get this kind of separation :
Glassfish as a front end for comet/bayeux interaction for synchronous
operation with browser
using an internal/local RESTlet connexion for getting synchronous access
to the RESTfull representations
So glassfish will solve the asynchronous -> synchronous access to the
proper RESTFull representation but access
it only when the need to propagate the changes arose and do it
synchronously (its like having your 'future idea' being resolved only
when the representation change is needed).
Is this too heavyweight or do you have get more thoughts about it in
Restlet before the 1.2 Milestone ?
Thanks in advance for your "lumières" ;-)
