非常同意现在的系分、高手都很热衷于赶时髦，或曰“浮躁”。我也见过非常非常之多人是在为了三层而三层，把简单的问题复杂化，把没必要做成三层的应用特地改成三层，结果得不偿失，事倍功半。
但对王兄后面的一些技术性分析，我觉得还是有值得商榷之处。
首先，李维所说的：DCOM 的连接速度较SOCKET CONNECTION 慢， 但是连接完成后， 传输数据较SOCKET CONNECTION 要快。我觉得基本正确。要注意一点：这里的Socket并非指Socket通讯，而是指Borland的SocketConnection。
问题在于王兄把DCOMConnection和DCOM混为一谭了。DCOM应用是一种相当于是远程的Automation应用，它是通过ORPC协议来传输IDispatch接口实现的。所谓的DCOMConnection便是基于DCOM的ORPC协议来传输MIDAS的IAppServer接口（它也是派生自IDispatch接口），而MIDAS（不止是MIDAS，DNA也一样）并没有限制DCOM连接（即ORPC）的服务端必须是DCOM应用，后来的MTS、COM+无一不是基于此，即便是现在.net的remoting也是基于此，它是在成熟的标准RPC基础上，结合了Windows的安全机制发展的起来，最关键一点，它的底层协议也是TCP/IP（ORPC用了UDP和TCP两个协议）。王兄所谓的淘汰之说，应该是指DCOM应用，而不是指DCOM连接吧。
不可否认，MS设计ORPC协议是完全基于Windows的域用户安全机制，这决定了它有很多的限制，特别是因为用了动态端口，所以基本上是无法穿过Firewall（不表示不能，只要打开Firewall的全部端口即可，但这样的话Firewall就形同虚设了），但也还有其它办法可以解决，典型的就是MS提供的基于IIS的CIS（COM Internet Services）技术，此外便是Borland的SocketConnection和WebConnection。
从本质上说这些穿过Firewall的技术都是所谓的Tunnel技术。即通过一对代理把ORPC的请求和响应转为通过别的协议传输。其中CIS和WebConnection的本质都是用HTTP协议作为中间协议，而SocketConnection则是用TCP协议。如下：
DCOM Client ==[远程接口调用/ORPC]==> Server（DCOM/MTS/COM+）
DCOM Client ==[本地接口调用]=> Client Agent(SocketConnection/WebConnection etc.) ==[中间协议：TCP/HTTP]=>Server Agent(ScktSrvr/HttpSrvr etc.)==[本地接口调用]=>Server（DCOM/MTS/COM+）
上面一个是标准的DCOM连接，下面则是Tunnel连接，因为Tunnel多了很多中间步骤，所以数据传输性能一定比较差。但为什么连接速度反而比DCOM快呢？因为ORPC有安全性约束，在连接时需要身份验证，而用了Tunnel后，两边都是本地接口调用，不用安全身份验证，所以连接速度比较快。但这样的话就需要自己处理安全问题，如SocketConnection提供了Interceptor技术，而WebConnection则需要借助于SSL。不过据我所知，绝大多数做这两种应用的人都没有考虑过这个问题（据说有人用代理猎手在网上搜211的端口号，居然找出一堆的地址，汗啊）。
正好前不久给一朋友帮忙，他为了安全考虑，需要改造WebConnection，所以对它的实现机制刚好还是比较熟的（不然MIDAS有几年没有用了，快忘记着差不多了）。王兄说WebConnection会导致效率大幅下降，这我同意，因为在WebConnection中需要对COM请求的数据进行Marshall并编码为HTTP协议所需要的文本格式，到了httpsrvr中又要把HTTP的文本转成本地COM调用。相对来说，SocketConnection的二进制数据效率肯定比HTTP的文本要高，更何况相比WebConnection用的HTTP这样的应用层协议来说，SocketConnection用的底层的TCP协议，性能上也要好。但如果用了SocketConnection就必须要在防火墙上专门开一个端口供其使用，对于一些只能访问Web的防火墙，就无能为力了。
至于基于XML和HTTP的SOAP/WebService，我也同意王兄的看法。基本上它的大多数优点，WebConnection都有（只是通用性和标准性不如SOAP），而且WebConnection用的BASE64编码无论在时间效率和空间效率上都远高于XML编码。个人认为，如果不是必须要与异构系统互联，SOAP/WebService还是应该避免的。
但王兄认为HTTP效率低下就完全不可取我不敢苟同。在一些情况下，用牺牲效率来换取高度的灵活性还是值得的，至于王兄所说的查询出数M的数据，对于现在的网络来说，问题并不是很大，就算数据量再大也可以通过减少每次传输的记录数来解决，毕竟使用客户端的用户一次能看的数据也是有限的。
抛开WEB防火墙的苛刻要求，SocketConnection不论是在性能上还是在灵活性上应该说都是比较好的选择。但遗憾的是，Borland提供的SocketServer并不具有工业应用的能力，具体的王兄已经分析得很细了，我就不再赘述。但王兄因此否定SocketConnection我觉得不太妥当。
毕竟对于Borland来说ScktSrvr是一个随DELPHI/BCB免费提供的小程序，不可能对它要求太高，拿Tuxedo来比是不公平的，Tuxedo可是BEA的主要赚钱产品之一，单一个Tuxedo就比DELPHI要贵了，没有理由要求DELPHI免费配一个跟Tuxedo相当的产品。而Borland提供了ScktSrvr的源码意义也正是在于：如果你需要很高的性能要求，完全可以自己参照着源码用完成端口之类的更好的方法去修改它。
当然，就目前的情况来说，MIDAS并不能算是一个非常好的多层解决方案，不可能指望用一种多层技术去处理所有的多层应用情况（即所谓手里有一把锤子，看什么都是钉子），但MIDAS总算是所有多层技术中，最简单的之一了。
归根到底一句话：技术不是根本，使用技术的人--这才是根本。
