The "problem" is that all this application development stuff is so very complicated. Microsoft concedes in a white paper ("The .NET Framework and COM," from which I'm paraphrasing) that COM development is pretty tough. These poor developers need to (gasp!) write code, implement interfaces (eek!), manually manage memory cleanup (oy!), and (insult upon injury) count how many times a component is used. Now might be a good time to send your local COM developer a flower basket or some muffins.

The threat here is that since all this "development" work is so time consuming and complex, application users are subject to "DLL Hell," system crashes, and generic errors. However, Microsoft has removed much of this development nonsense by automating the plumbing details of software writing. It created a common language runtime (CLR) that will manage many of the things the developer used to, such as managing memory allocation, thread lifespan, and security policy enforcement (this is the first MS mention of security), as well as satisfying any component dependencies. Because of the way that development projects run, and the important "time to market" pressures, these CLRs will see a lot of use. Unfortunately, when you decide to leave memory and security functions to a black box mechanism, you lose all understanding of what it does and how it does it. Does anyone else see a problem here when we start talking about online transactions and information privacy?

Additionally, Microsoft has introduced loosely coupled message-oriented Web services based on XML. Web services will allow an application to expose its features programmatically over the Internet (or intranet). This type of distributed logic exists today in the Distributed Component Object Model (DCOM), Common Object Request Broker Architecture (CORBA), and Remote Method Invocation (RMI), but they are typically local objects, unavailable over the Internet.

That is, up until now. Since DCOM is exploitable and considered insecure, corporate firewall administrators have been able to block DCOM from entering or leaving their networks. To use it, you would have to open your firewall up on the TCP and UDP port 135. UDP is bad enough, but 135 also is used for NetBIOS communications and it's inherently exploitable. Now through the magic of Microsoft, we have the Simple Object Access Protocol, or SOAP, which communicates over HTTP—the logic of this being "since SOAP relies on HTTP as the transport mechanism, and most firewalls allow HTTP to pass through, you'll have no problem invoking SOAP endpoints from either side of a firewall."

I can see the TV ad now: "Are you a developer frustrated by network security professionals? Are you tired of managing threads and cleaning up memory? Then try Microsoft.NET! With the power of SOAP you can wash away all security concerns by passing through the most commonly open firewall port, HTTP!" ("SOAP: The Simple Object Access Protocol" by Aaron Skonnard, Microsoft Internet Developer Magazine.)

Where Am I Going with All This?
Microsoft has a battle ahead of it for the .NET service in terms of security and privacy. To wit, Microsoft has created a framework, called .NET that makes services out of products, automates application development, and provides a mechanism for circumventing corporate security frameworks. They have created an architecture that will use the Internet to talk to distributed parts of itself but there has been no mention of how these connections will be secured, how they will be authorized, or if redirected, how they are authenticated in such a way that there can never be a dispute over authenticity (digital certificates or thumbprints anyone?).