自从人类开始建造活动以来，就存在着建筑的美观性与实用性之间的矛盾。在经济萧条或者快速变革的时期，这种冲突更趋于增强。对于软件工程师来说，我们正同时经历着这两种时期。但是在.NET
Framework的基础上构建新系统的愿望或需求（从某些情况上来说）从来没有像现在这样如此强烈，决策需要依据预算底线，这是经营管理的需求。对于软件工程师来说，要牢记需要交付更具商业价值的软件，而不是交付仅仅符合成本的程序。
让我来分清价值和成本在商业和系统架构方面定义。对商业来说，价值不能仅仅计算交付程序本身所花费的成本，还要考虑因程序而带来的增收以及相关的运行成本。这些成本的降低可能来自减轻的劳力或更高的生产力，或者因运行程序而精减的组织部门。但是构造价值却全然不同。构造价值通过两个关键因素来衡量：寿命和实现成本。
构造寿命是指在不改变底层结构的前提下组织开发附加的程序或整个系统的能力。然而，对于一个软件工程师来说，设计一个可重用和可扩展的系统并不困难甚至相当容易，但要实现它却不大实际，因为所需的成本太高了。让我们来看一个重要的有关实现成本的例子，对于.NET工程师它经常被讨论——使用SOAP还是.NET Remoting。
任何将SOAP作为一个协议来看待的论题都不可避免地会导致对其基础——XML的使用成本的讨论。XML能适应多种不同的环境的理想特性使得SOAP实现起来及其昂贵。
例如，两台机器如果运行着相同的操作系统并具有同样类型的处理器，它们可以通过将数据存为紧凑的二进制格式来交换大记录集。但是如果两台机器的操作系统和处理器并不相同，那就需要一种通用的格式（如XML）来描述数据，以使两者都能处理。将二进制格式的数据序列化成为定义了结构的XML标记，并将文件发送到第二台机器，然后反过来将其转换为第二台机器本地的二进制格式，这比起直接用二进制格式交换数据要花费太多的操作了。使用二进制格式交换数据使两台机器的处理器都发挥了更大的效能，而通讯成本是根据有效负荷大小的差异而增加的（有效符合越小，成本越大），典型的使用二进制格式比发送XML数据的有效负荷要大三至十倍。
大多数的工程师愿意付出处理和通讯成本以允许两台或更多的机器能够通过一个通用可理解的格式来传输数据。此外，扩展SOAP如今被主流软件厂商如IBM、Microsoft、BEA和SUN等所实现。基于WS-Irecommendation的扩展使得不同系统的SOAP消息能够自动发送并包含任何平台都可用得二进制附件。这些扩展还允许SOAP消息在不同平台之间进行调整，这样使用调整处理，既能够进行同步处理控制也能够进行异步处理控制。
当你只考虑同一种环境时，成本明显的要少许多。一些公司（包括我曾经供职过的）正在一个纯Microsoft环境下实现.NET。在这个环境下显而易见的话题是：“我为什么要为SOAP付出成本？”虽然他们当然同意在一个标准IP端口上通过HTTP协议来使用SOAP是有意义的（与DCOM相比，后者需要更多复杂的配置以使其工作正常），但是他们会怀疑使用SOAP与使用二进制格式和.NET Remoting的有效负荷价值之比。后者要快一些，需要更少的处理周期，而且拥有一个更为有效的编成模型，可以允许程序产生事件并响应它们。
然而，使用.NET Remoting意味着必须开发自己内部的架构标准来确保将来的系统可以与其正确的互操作。实际上，选择使用.NET Remoting作为内部标准几乎就可以肯定必须实现自己的WS-I途径和处理标准，这些当让只能在你自己的组织之内使用。如果你的系统需要与非Microsoft的系统互操作，那么最少你要使用SOAP标准来暴露你的部分底层系统，因此需要你支持SOAP和二进制格式两种标准。这样一来，成本还会节约到哪去？
底线是这样的：接收额外的成本来实现基于SOAP标准的系统会使你从目前和将来扩展的实现中获得好处——你可以不必自己开发。另一方面，如果你预计你的系统不会同非Microsoft的系统“对话”，那么一个纯.NET Remoting结构会给你带来性能上的优势，而你失去只不过是一个基于SOAP的底层结构。
