问：是否存在某些经验法则，让人们在网络互操作性和进程互操作性二者之间做出选择？换句话说，如果我遇到吞吐量问题，是不是就不该选择Web服务了？

　　答：由于开发者的选择以及对于单个应用开发的关注，互操作性至今还是一个问题。如果目的明确，为了互操作性而设计程序，可能问题就没那么困难了。但是开发者喜欢利用各种编程语言的高级功能，例如：C#、Java、Ruby、SQL、XML、Perl、JavaScript等等，这意味着要充分使用嵌入式数据类型。有关互操作性的研究表明，程序中的数据类型的复杂性同它与其它程序的互操作性（尤其是用其它语言编写的程序）成反比。

　　例如，在网上搜索SOAPBuilder，你会发现数据类型越少，互操作性的级别就越高，这一点表现在和复杂以及结构化数据类型的搭配中。高级数据类型可能为开发者提供更大的灵活性，并由此产生紧凑代码，但是会阻碍互操作性，因为不同语言支持的数据类型组合不同，尤其是复杂数据类型不同。Web服务通过将单个语言数据类型映射到XML数据类型，解决这一问题，但是不能保证100%的映射，也无法保证映射的过程完全自动化。

　　性能也是一个问题，如果你可以保证相同的环境，例如Java EE或者.NET，还是使用国产的通信协议，如Java EE环境下使用RMI，.NET环境下使用Microsoft RPC。如果你需要在Java EE和.NET程序间进行互操作，Web服务可能是唯一选择了。在这种情况下，最好放弃性能而选择程序之间的交流功能。
　
　　另一个可以实现互操作性的地方就是异步通信协议，例如：JMS、AMQP、REST/HTTP都属于这个领域，至少理论上是这样的（但是实施起来不是这样——远远超过了这个领域）。从这个角度来说，实现互操作性的主要概念是你可以避免使用带有数据类型的接口。相反，你可以把所有的数据都放入一个大型的半结构化信息中，然后像传递文件一样将这个信息传递出去。收到信息的程序负责解压数据，然后对数据进行处理，例如：访问数据库。这一做法为处理数据类型这类问题提供了更大的灵活性，不过代价是复杂性也随之增强了。

　　REST/HTTP是其中的特例，因为REST/HTTP定义了一个特定的接口并且准许内容类型的流通。这一设计是建立在产生并且使用更多的资源基础之上的，而不是建立在定义和打包/解压信息本身之上的（尽管现实所发生的一切和概念上很接近）。