More SOAP

I relearned one of the reasons why we do RPC style architecture. I am working on a solution spike with an expensive (license and hardware requirements) piece of software and wanted someone else to play with it to get a sense of the data that was being manipulated. So I created an installer and used it to put the software on another machine, easy as pie. Of course it didn't work right away because all the 3rd party dependencies weren’t captured correctly.
After futzing for about an hour, running back and forth between machines everything was working fine. Except now another person wanted to play with it as well. I didn't want to kill an hour or more every time I revised the spike so my users could see what had been done.
Luckily Thanksgiving came upon us and I was forced away from my machine for a couple of days and clarity returned. My first thought was to bag it all and redo everything as a web page, but it seemed like wasted time to recreate all my previous GUI work and run into who knows how many snags to save a couple of hours. Then I remembered I could have my cake and eat it too by only deploying my rich GUI (via .NET no-touch deployment) keeping my customers up-to-date and putting all the problem API calls and configuration files on my development box where I could keep an eye on them behind a SOAP interface.
Now granted I haven't yet made this change, and I haven't decided if SOAP or .NET remoting is the best choice. Nevertheless I can see several advantages, not the least of which is that I can abstract my interface to the service I am building and (with SOAP) can trivially create proxy classes to manage the communications. Anything that saves me coding time is tops in my book.

No Comments