I am in the preliminary stages of architecting a legacy replacement project. They already have sub half second performance on their green screens and they want the same on their web app.

We have a 390 mainframe that can handle anything we throw at it but they don't have a good jvm for it, so we have two tiers of websphere servers between the mainframe and the browser, The ui server, and the bl server. For the ui, I'm leaning towards GWT. But one thing that I think would seal the deal is to add messaging capabilities to the browser. The idea is say you click on a link that displays a second panel of information, instead of the classic GWT where it triggers a GWT-RPC call to the ui server, the ui server routs it to the bl server, the bl sends it to the mainframe and back out, it drops an MQTT message directly to the bl server or directly to the mainframe. Say writes go to the bl, reads go to the mainframe.

This is an easy enough thing in classic jms because you can issue a message that has an expected response. Then have your callback ready to get the resonse. But from what I'm reading so far. It looks like mqtt doesn't have that. It looks like it's strictly fire and forget, which would make it really tough to come up with a way to get a response back to the workstation that called it.

Am I right here? Has anyone tried this stack before with gwt.