When I create Swing apps for remote users, I just create jar files and create a WebStart file to let users download the app and then run it. I haven't heard of application servers serving up JFrames, etc, like JSPs. Was that the original intent?
Persistence.
If you want to have nothing other than the UI you could persist it to disk and then restore it the next time the program is run.
It'd come back up with everything exactly as you left it.
No fancy stuff required.
I've actually used it in the past. Build a compiler that takes in XML data, configures and builds your display objects up, serialize them and then pass them on to a thin client that doesn't know anything beyond UI and simple callbacks.
Of course it turned out to be terribly inefficient. We wound up seperating the data into a different class and using an instance of that as a parameter for our display object constructors.
There's no good reason I can think of to have the swing objects themselves serializable, except for ease of use. In fact it turned out to be a little dangerous, since we thought "if they made it serializable in the first place, then it can't be that bad an idea."