[Hawkular-dev] cmdgw forwarding messages from bus to UI

[Lucas Ponce]

----- Original Message -----
> From: "Jiri Kremser" <jkremser at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, October 20, 2015 1:22:06 PM
> Subject: [Hawkular-dev] cmdgw forwarding messages from bus to UI
> 
> Hello,
>   when creating the topology graph, the nice feature would be to see the
>   newly added resources in inventory in a real-time. Currently, the approach
>   on many places in UI is polling with long intervals. Each 20 seconds the
>   url list, app server list or topology is updated with the fresh data.
> 
> We have the server-side bus in place into which inventory events when anyone
> is 'CRUDing' the entities, I believe alerts are being sent there, etc. Also
> we have the cmdgw module for dealing with the bus-agent-ui communication, it
> uses the WebSockets for full-duplex comm. From what I've seen it works like
> this:
> 
> 1) ui initializes the WS connection
> 2) server stores the session, correlation id is the session id
> 3) later on ui invokes a command with some id
> 4) once the command is done the ui is notified by the server side (no
> polling, real server push)
> + some magic with bus (bus works here as a glue with the other components)
> 
> What would be imho really useful would be not only using the web socket layer
> for sending the responses on previously requested operations but also having
> the ability to send the notification to whoever cares on the ui (without any
> former explicit action in the ui). I mean events like "something bad
> happened". After talking with Peter, the better correlation id here is the
> tenant id, because we don't want to leak the information among the tenants.
> So if the server keeps the info which session id was created for which
> tenant we are almost there.
> 
> pros:
> * alerts can be displayed immediately (no need to wait 20 seconds for the
> refresh)

(Small disclaimer, about alerts, being displayed inmediately on the UI are not a strong requeriment on that side, on the contrary alerts are sent inmediately via the actions architecture via configured transport)

> * no polling = no wasting with resources
> * cool demos
> 
> cons:
> * switching the persona needs to be handled, but it's doable
> 
> What do you think?

In a first thought, having a real full duplex communication is attractive.

But, dealing with session on server also mean an extra complexity where the tradeoff is not trivial IMO.

I know that the "clustering-scalability" chapter is not formally open yet, but my first thought is that we deal with a custom session mechanism on the server the complexity might be increased (we need to use ISPN to share this state, to deal with distributed scenarios, etc).

Also, there was a related topic some weeks ago about a server side component to do high level integrations between components, Jay started to think about it, perhaps these two topics can be related and on that scenario, having a full duplex communication could be interesting.

Just my 2 cents.

> 
> jk
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>