>>
>If the remote possibility for the need to scale was present in the original spec, then it was incorrectly architected.
>>
>
>Hypo....
>
>There is a 1% chance that the app has to be 100% web-enabled. This I think you would agree is a remote scenario. Futher, presume that it would cost an additional $50,000 to architect the app so that it could go to the web.
>

In this case, the choice would be more or less clear. But what I'm getting at, and what I think .NET is trying to address, is that if we can put infrastructure in place that makes it easy to create n-tier, scalable applications, this is a business decision we won't have to make. We'll be building everything so that we can flip a switch and put it on the web.

< example >
The application I'm working on now will be a shrinkwrapped app that for the most part will be a single user app per install. But since scalability is designed in from the start, adding users to a single install will be seamless, and when the customer wants to deploy the application enterprise-wide, I will be able to sell them a single, cheap server component that makes the fat client application usable from anywhere in the world that has an internet connection. It's a single user application that has the potential to scale nearly infinitely. And because the scalability is built into the framework, and most of the code is either in superclasses or written by wizards, the app development effort has been not much more than a simple, single user application that uses dbfs. I don't have to make the $50,000 decision, because this app is already cheap.
< /example>

>Huh? How do you implement com through a firewall? I'm not talking about punching holes, I am talking about port 80/443? Without writing a lot of code on both the client and the server side, you can't.
>>
>
>How do people do it now???? Seems to me that folks have been able to things to work now. Why is that? The COM components are behind the firewall. I don't get this argument that COM does not work with firewalls. Make me understand....

DCOM/RPC uses several ports in a predetermined range ((by default, DCOM is free to use any port over 1024) to communicate between machines. To connect to a COM server over the internet, and through a firewall, a network administrator has to open this range of ports in the firewall. The average corporate firewall only has openings in specific ports to allow for specific types of Application Layer traffic : port 80=HTTP, port 443=SSL, port 21=FTP, port 25=SMPT, etc. You can configure DCOM on the server to use a different then default range of ports, but changing these changes the port for all COM servers on that machine, and the registry entry changes require a reboot for the change to take affect. You can find out a lot about this mess by searching MSDN on DCOM and firewall.

>>Yeah, they're writing their own code to do it. Have you ever written one of these apps? It's not trivial. (It's getting easier and easier now that I have my own framework to deal with it, but nonetheless, my framework has a lot of code).
>
>Now that your framework works, would you throw it away on something that is not tested? Or, would you wait and see???

I won't be throwing it away any time soon. But not everyone is using my (or any) framework, and the functionality that my framework gives me is the functionality that .NET (integrated Web Services in particular) is attempting to give us right out of the box. Right now, AFAIK, there is nothing that does this type of thing out of the box.