Le 15 févr. 2013 à 10:21, Heiko Braun <hbraun(a)redhat.com> a écrit :
Referring to [2]
You write "The notifications are a feature internal to AS7 and are not meant to be
available remotely."
You mean it's not going to part of the work you are doing, right? Nevertheless any
protocol implementation used for remote notifications should be able to interface with the
management layer. For instance a web socket layer interfacing the management layer which
adopts the notification protocol to HTTP.
An alternative would be build it right into the Java and HTTP protocol we have. But I can
see benefits and drawbacks in both approaches. The later is not strictly necessary. I.e.
we might have a custom subsystem, able to translate internal notifications to web socket
events. Interfacing the notification API. This would decouple the wire protocol from the
management layer and the notification API it exposes.
[wire protocol, i.e. web sockets]
|
[notification API]
|
[management layer]
Just food for thought.
At first, I did not want to add remote notifications support to our management API.
Clients interested by it (web console, JBoss Tools, etc.) could add subsystems to bridge
between the notifications and the transport protocol they can use. That's not a great
idea though, we want to provide an uniform & stable way to manage AS7, not let every
potential clients puts bits in the server-side to interact with it.
So, let's add the notifications to the management API.
I don't see a big issue to do that with our Java API, we could add a
registerNotificationListener(ModelNode, NotificationListener) with the listener being
called back when a notification is emitted.
However, I don't have a good idea yet for the HTTP API.
I see 2 types of clients for our HTTP API:
* web clients that uses HTTP only
* modern web browsers that can leverage Web Sockets
For the Web console (running in a Web browser), using the Web Sockets protocol seems a
natural fit to handle notifications but that support web sockets protocol from AS7
management service (not sure if it's already in the pipeline).
For plain-HTTP, we could also provide a more RESTful API but it'd be up to the clients
to poll to check whether there are new notifications to handle. We could use long-polling
techniques to push the notifications back to the clients but I don't know if
that'd work outside of web browsers…
If you have other ideas, don't hesitate to send me pointers.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/