Back to Part One
Last, but certainly not least, is Microsoft's over-the-top commitment to the Web Services model. The .NET platform makes implementing loosely coupled, XML-based systems very straightforward. Microsoft has solid support for the most recent XML and Web Services standards and has built that support into the framework and the development tools. Now, whether or not you are a big, giant fan of Web Services is not really important (to me anyway). Even if you are not implementing a "Web Service" the support for simple remoting and standards-based data marshalling is a huge help when developing modern, distributed applications. The .NET tools allow you to stick to your architectural model all the way through development of your application. Specifically, many times architectures start out with all the right intentions of separating machines and processes, only to fall back to single machine or too-tightly-coupled components as deadline pressure mounts. Implementing remote processing or remote data is as simple as adding a tag to a method in the Microsoft environment. To actually go to production with a high-volume implementation takes a bit more work but it's much easier to tune communications after v1.0 of a product than it is to try and rip apart compiled modules to run in a distributed fashion.
This only scratches the surface and does not do justice to an effort that Microsoft is spending billions on. Hope it helps!
Dig Deeper on Topics Archive
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.