[jboss-as7-dev] Add Notification support to the domain management API

[Brian Stansberry]

On 2/27/13 2:12 PM, David M. Lloyd wrote:
> I don't see notifications as a bidirectional thing.  I look at it this way:
>
> sync:
>     C: "Please send me notifications regarding /foo=bar to id=123"
>     S: "OK, will do"
>     C: "Please send me notifications regarding /baz=zap to id=123"
>     S: "There is no such resource, sorry"
>     ...
>
> In the meantime, you have:
> async:
>     C: "Notifications for id=123"
>     S: "/foo=bar changed ..."
>     S: "/foo=bar changed ..."
>     ...
>     (connection broken - cell phone went into a tunnel)
>     C: "Notifications for id=123"
>     S: "/foo=bar changed ..."
>     ...
>
> It seems a very clean mapping, cleaner than web sockets tbh, and a sight
> simpler architecturally.
>
> I do not see async notifications as a good solution for long-running
> operations since those are essentially synchronous.  I'd rather see a
> server-side solution for that (even the outliers like restarting a
> server).  Trying to make these asynchronous is sort of the path of most
> resistance, in that we're borrowing complexity we do not need.
>

We actually built a side-channel event mechanism into the core operation 
execution API:

org.jboss.as.controller.client.OperationMessageHandler

We never really did anything with it though after 7.0.0.Beta1. For 
7.0.0.Alpha1 I had prototype stuff for sending back events as 
domain-wide operations execute. But it got ripped out as a bridge too far.

A browser-based client would of course need a different mechanism for 
registering for messages and having them be propagated back.

> On 02/27/2013 01:43 PM, Heiko Braun wrote:
>> SSE are asynchronous, but unidirectional. Whereas websockets are
>> asynchronous and bidirectional.
>>
>> Enabling push through SSE,  clients could use a combination of
>> request/response for the main communication (i.e. execution of
>> operations, reading the model contents, etc) and SSE for the notifications .
>>
>> Using websockets we could move all client communication to one paradigm.
>> But do we need it?
>>
>> Currently have cases where clients keep polling for system state changes
>> (i.e. server restart, deployments, etc). Typically the things that take
>> some time to complete. So I am wondering if these cases could benefit
>> from an asynchronous bidirectional communication channel. But I guess
>> this depends on how the DC processes management operations and if
>> asynchronous responses would fit into the picture.
>>
>>
>> /Heiko
>>
>>
>> On Feb 26, 2013, at 6:37 PM, David M. Lloyd <david.lloyd at redhat.com
>> <mailto:david.lloyd at redhat.com>> wrote:
>>
>>> I don't know, it seems like overkill.  I think
>>> http://html5doctor.com/server-sent-events/is probably a better option
>>> than web sockets or polling as it is supported in the browser with a
>>> simple API and doesn't require a lot of complex server-side support.
>>
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat