>I see your point, but few apps can just inform the user of an error and be shut down every time a service flakes out. It's not like the stand-alone app that relies only on itself and maybe a file server. It's more like apps that use a file server and a remote COM object or two. You've now got several machines involved, a network, maybe the internet, maybe an ISP. The application now needs to maintain as much functionality as possible given that certain services aren't available. What is or isn't possbile now? That question can cascade through the application...
>
>In some cases, queueing will be required to hold processes until the services become available again and messaging is needed to alert administrators that a problem exists. Some functions will simply be unavailable for an indeterminant time. How often do you check to see if they are back?
>
>I'm certainly not against distributed computing. In fact, I'm looking forward to a LOT of it's benefits, especially application deployment. I know however that those apps will be a lot more vulnerable and in some cases, slower than stand-alone .EXEs. I relish having the choice, but I don't see a distributed as all good stuff with no bad stuff.

I think that the typical things you do with a stand-alone EXE would be better to be there. My view of the possibilities of distributed applications are for a lot of services that can compliment this apps, as remote information updating, validation services to certain operations that are made off-line right now.

I ddon't think we would be able to build an OLTP system with VERY distributed transactions any time soon, but someone could come up with some kind of solution later, or finally we could reach a decent level of reliability on the Internet (or whatever you call it in ten or twenty years).