刚看到DFW的达人王兄的《对Borland 和 N-TIER的牢骚》，发现今天的BLOG有内容可写了:P
非常同意现在的系分、高手都很热衷于赶时髦，或曰“浮躁”。我也见过非常非常之多人是在为了三层而三层，把简单的问题复杂化，把没必要做成三层的应用特地改成三层，结果得不偿失，事倍功半。
但对王兄后面的一些技术性分析，我觉得还是有值得商榷之处。
首先，李维所说的：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总算是所有多层技术中，最简单的之一了。
归根到底一句话：技术不是根本，使用技术的人--这才是根本。
BTW：今天夏至，今年最长的一天。
2004年6月21日 12:07
href="http://borland.mblogger.cn/raptor/Services/Pingback.aspx" rel="pingback" />
# 回复: 我观MIDAS
呵呵。 我在BLOG里发的牢骚并不是想否定SOCKET CONNECTION
的大方向。 我想否定的是众多人等为了三层而三层，不去分析一种技术的实质而盲目跟风。 确实，从DCOM的机理上来说， 我认为DCOM 已死， 除非是MS 再重新修改DCOM的实现，不过从MS的态度上来看， MS修改DCOM的积极性不大.
至于SOCKET CONNECTION， 大方向不错， 但是BORLAND 的实现手段错了，把好好的一个SOCKET CONNECTION 写的没有应用前景， 如果SOCKET CONNECTION 能够应用完成端口技术重新写过， 所需要修改的仅仅是它传输的数据包 IDATABLOCK的
格式， 在每个DATABLOCK的头部加上 REMOTEDATAMODULE的地址或特殊HANDLE标识即可， IOCP 是非常高效的， 如果这样写出来的中间层，中间层服务的CLIENTS 数目，将从0-200提高到0-1500， 这样的性能我认为是有本钱和TUEXDO 拼一拼的
# 回复: 我观MIDAS
老鸟，你做过TUXEDO服务吗？
# 回复: 我观MIDAS
M$的三层策略基本上分为两个部分同步进行.
一是web service enhancement, 刚发布WSE 2.0, 以soap为载体, 增加很多高级应用, 比如ws-trust, ws-security, ws-route, 涵盖了事务, 安全性, 访问, 可靠消息等很多方面. M$用这个来先占领市场, 推销他的SOA加构.
另一是indigo, 这主要是用来解决传输瓶颈问题的, 用一种低层次的基于二进制的协议, 是M$和IBM联合设计的, 在设计的时候, 他考虑了由WEB SERVICE系统转化的问题, 所以编程风格很象现有的asp.net web service, 都是用attribute的, 当升级的时候, 只要把attribute改一下, 底层传输协议就由soap变成indigo了. 而且WSE的高级功能还保留. INDIGO计划2004中旬完成, 将会集成到vs.net 2005里去, 而且他会成为longhorn的首要消息机制.
4459
到【灌水乐园】发言
评论
说不了任何评论，因为三层我只用SocketConnection，其他的连接的性能没有做过，没有发言权。
非常赞同一点，不能为了三层而三层。也不是什么东西都是“万金油”。看具体。
其实还是上次说：下棋低手和高手的区别，一个是要下成什么模样，一个是根据具体的分析使用什么样的模样。
不知怎么，我一直在重新审度C/S结构体系，确实能用C/S何必三层。C/S比三层有很多优势。尽管三层，甚至分布式应用范围广。
嗬嗬，没有发言权的我不再多说了。：〉