OK,
It's certainly an interesting problem you have there! I'll try to split up my response into areas I think you want addressed (let me know if I missed the mark), I'll apologise in advance if I'm babbling on about stuff you already know, in fact I suspect you'll be far more of an expert than I am in most of this.
GUI:
-----
What are the current GUIs written in? I'm going to assume they are written in Swing. Other GUI technologies would probably be just as competent in dealing with the display of data etc as long as it's decoupled from the processing layer.
Disclaimer #1 - I'm not a Swing GUI expert by any means but an open source project I'm on uses a very complex multi-threaded/concurrent GUI and it works just fine in terms of speed. Now that's not too say there wasn't pain in getting the GUI to that point
. I'm especially unaware if Swing is very good at say using multiple threads to update multiple rows in a table, that sort of thing.
So I think your choice of building the GUI in Swing on Netbeans is fine. Further down the line you can ask Swing Q's directly in our Swing forum where there are lots of gurus to assist (not me ;p). One thing I'll add straight away is that:
* Yes using Swing App Framework is a good idea.
* Using the very latest version of the JDK/JRE is a good idea. That is if you can build on and have your clients run on JDK/JRE 1.6.0_10+ you're going to get a much nicer experience (radical changes were made in 1.6.0_10 to make desktop Java a bit nicer and faster again).
* Decouple the MessageHandler(s) from the GUI if you haven't done so already.
The whole concurrent messaging model thing:
-----------------------------------------------------
Aside #1 - I'd normally prescribe a healthy dose of JMS (which would deal with some of your queuing and concurrency issues), but typically that involves introducing an application server and I don't think you want to go down that path
.
Right now onto the heart of the matter! I think what you've described sounds just fine up to:
The client reader thread takes msgs off the reader queue and calls the appropriate message handler. In the simple GUI, the message handler simply updates a JTextArea from the message payload.
As you say with the new complex GUI you can no longer have the simple MessageHandler model. I can only suggest something like (same as before really):
* Have the M1 MessageHandler simply store the M1 block (storage type should be swappable) but no longer call the GUI to update.
* Have the B1 MessageHandler retrieve the M1 block hand off to another class to do the merge with M1 processing and then eventually take the result of that and update the GUI (again I'm not sure how efficiently you can update various Swing components).
Naturally the above is simplistic and you'll have all sorts of Manager classes, an interface or two and maybe a storage solution
. Oh and you'll need to deal with two M1 blocks arriving before a B1 block, that sort of thing!
The important bit?:
---------------------
I _think_ an important concept you might have to introduce is a Admin or Thread Manager interface on some of this stuff as you want to be able to cancel threads at the drop of the hat (the GUIs have to be very responsive), obviously the stop threads would have to be given the higher priority.
I'm not sure if you 'stop' a
unit of work whether you lose it all or whether you've got everything wrapped in transactions....
The graph:
-------------
I think there are some 3rd party APIs for that sort of thing, JFreeChart is one to look into..
Well I hope that helped in some small way, it certainly sounds like you'll be busy!