非常同意现在的系分、高手都很热衷于赶时髦，或曰“浮躁”。我也见过非常非常之多人是在为了三层而三层，把简单的问题复杂化，把没必要做成三层的应用特地改成三层，结果得不偿失，事倍功半。
但对王兄后面的一些技术性分析，我觉得还是有值得商榷之处。
首先，李维所说的：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总算是所有多层技术中，最简单的之一了。
归根到底一句话：技术不是根本，使用技术的人--这才是根本。
