Why split it out over two network protocols?

If you are going write a SOAP layer you don't need to go over HTTP too to get the possibility of back-end-on-big-iron.

The GUI front-end needn't be .NET or Java. If you're happiest in perl, you could do a perl/Gtk2 (or perl/WxWindows or even perl/Tk) front-end. The first two options at least look pretty 'native' on Windows.

But if you're happiest doing GUI work as web pages, then you could do what you say. But then you could leave out the SOAP entirely. Just write a web app as you described.

Put a nice, clean abstraction layer in your code at that boundary and it will be fairly straightforward to SOAP-ify it later. And you'll even get to re-use your interface unit tests so that you know it's all working ;-)

So...my first choice might be zero network protocols (native client, with code on board). Do a decent model/view/controller split and then you'll have the option of putting in another controller/view for a web interface, talking to the same local model. Or the option of splitting off the backend over SOAP. But I'm not sure you need both.