日期:2008-04-04  浏览次数:20550 次

转载自【雨声论坛】
原作:software_young

----------------------转载开始---------------------

CORBA,DCOM,Java RMI, Web App,.Net其实都源于DCE(分布计算环境),是其不同分支的后代,而DCE又源于EDI(电子数据交换)。
EDI的目的,是在网络上以电子方式实现不同用户间的数据交换,以数据交换的方式实现某种合作。这是一个很老的东西了。由于其各个供应商互相不妥协,不管是网络的物理特性、数据交换的格式还是应用的体系结构都互不兼容,使得它的成本极高,非大用户难以用得起那玩意。CA从那里赚了一些钱。不过它也产生了一些好的后代(这里姑且不论其大小),XML就是其中一个。我在中国时,认识中国IBM的一些怪物,知道了一些这方面的东西。他们都是在IBM MainFrame上面实现EDI的,由于我在AS/400方面的名气,他们倒是愿意和我讨论其在AS/400上面的实现可能。其实,AS/400上面有对EDI的支持,问题在于成本。我和他们讨论了一下在AS/400上面实现EDI应用程序的成本问题,发现那玩意要比AS/400的购买成本还要高上一倍。大家要知道,一台企业级主机型AS/400的价格,大致要三到四百万美元(报价,打完折是两到三百万美元),EDI应用程序又需要企业级主机型AS/400的处理能力,服务器型的AS/400处理能力远不如主机型的AS/400,虽然价格比较便宜,只要八十万到一百二十万美元。我和公司的业务老总们汇报了这个问题后,他们撇撇嘴,再也不关心了。
DCE源于Unix,其目的是建立一个统一的、标准的、分布式、跨平台的通用计算环境,而不只是数据交换,工作基础是RPC(远程过程调用)。其工作原理正如gxtsh教导我们的 “采用的POXY/STUB机制(代理存根机制),在客户机上使用代理,在服务器上保留存根,这样一个远程调用发出后,代理将有关信息采用自己的特殊数据结构与服务机连接,服务器建立对象作为存根,运行结果通过存根返回客户机的代理并由代理提交调用程序完成一次交互。”。其实,这也是所有分布式计算的共同原理。DCE的支持者有Sun、IBM、HP、Microsoft,Novell等大公司,以及如Borland等一些小公司。开始时声势十分的浩大,但是却没有产生相对应的产品,原因就在于各个大公司各行其事,虽然上面有一个委员会,却是个周天子。那组织的下场就和三国时讨董卓的十八路诸侯的命运一样了。
DCE的一个后代就是CORBA,它的发起者主要是IBM,Microsoft和一些Unix公司。Borland也介入了进来,但是Borland只是作为一个工具供应商来出现,它的技术实力和商业能力实在是不般配,因此,它也只能够作为小脚色来出现了,虽然它在中国的名气很大。就像三国时的姜维,虽然才气过人,名气很大,但是受限制于国力,最后也只能够去屯田了。
CORBA的设计者们都是Unix专家,这些家伙都是玩Unix和工作站长大的,那些玩意都是面向技术精英的,他们所设计出来的东西自然也就深深地和具体技术相关了。CORBA其实可以作分布式的应用,可以跨平台,甚至也可以跨网关。这里的网关的含义是Gateway,指的是不同的通讯结构,如IBM SNA、TCP/IP和微软自己的通讯协议之间的沟通和交流方式。微软的SNA Server和IBM的Communication Server就提供这方面的能力。CORBA的问题在于,它的实现过分依赖于技术细节,即商业应用程序开发人员必须以相当精力关注具体的技术细节而无法超脱于其上来专注于商业逻辑。而商业应用程序的开发其实只应该关注商业逻辑才是。这一方面对开发人员的要求很高,一方面也使得成本很高,同时推广和移植都产生了问题。后来者实际上都是以不同的方式来解决这个问题。目前的CORBA在Java和DCOM的夹击下日趋衰微了。
COM的来源是微软的OLE,其含义是部件目标模型,是微软的第一个以部件目标为设计模型的东西,DCOM则是其具有分布式特征的模型。ActiveX是其在环联网时期的对应物,思想是几乎完全一样的。它的核心部件是Microsoft Transaction Server、SQL Server以及Microsoft SNA Server,前者是交易协调器,后者是为了提供跨网关的能力。开发者在服务器端以Visual C++和Visual Basic来开发部件,发布到Microsoft Transaction Server上面去,客户端则可以使用任意的支持COM的工具来开发。DCOM和MTS以及一些其它的东西合在一起则称为COM+。在应用程序的开发上,COM、DCOM和COM+是一样的,虽然它们在技术细节上有很多不同之处。微软的这套东西的好处就在于,应用程序的开发人员无须关心多少技术细节,只要会使用部件编程就可以了,因此对应用程序的开发人员的要求很低,易于使用;其问题在于,它基本上是基于Windows的,虽然有COM for Unix之类东西的存在,但是在Unix市场上则没有啥地位。
Java的起源这里无需多说,其RMI(远程方法调用)其实就是DCE中的RPC,它对技术细节的要求比CORBA要少得多,因此,在J2EE出来以前成了Java分布式应用程序开发的主力。但是它依然还有许多对具体技术细节的相关性,J2EE的EJB的出现正是为了最后解决这个问题,它使得开发应用程序的人员无须关注多少技术细节而完全将精力放在应用的业务需求上。在这里,商业性应用程序的设计重点在于用UML和Rational的产品作设计,最后由程序员作Coding,这样,程序员实际上是个工人的角色了,有高中生的文化程度加上一定的软件开发培训就够了。Web App其实就是纯商业性J2EE应用程序,由于J2EE的特点,它自然就具备了一个统一的、标准的、分布式、跨平台的通用计算环境所要求的所有东西,当然这只是理想上的,理想和现实总是有区别的,否则就不用做梦了。
至于.NET,它的真正使用要等到VisualStudio.NET和Windows.NET都出现以后才行。目前很难讲它的许多技术细节。至于商业宣传,那是市场的事情,和技术就没有多少关系了。
Web Service并不是微软一家独有,而是各个大公司都在作的东西。其思想在于以Web为来源为客户提供服务。这是那个统一的、标准的、分布式、跨平台的通用计算环境的极致实现。如果真的能够做到的话,当然很好。它的基础是XML+SOAP,但是XML自己就不是一个统一的东西。它的描述分裂成DTD和Schema,对数据库的存取又有许多的变种方法。各家的Dom和Sax实现也不完全一样。看来,它的统一依然是个问题。
毕竟,外交是为利益服务的,利益分配最终是通过对抗来解决的,而对抗是通过实力来说话的。在国际外交中,实力表示为国力和军力,而在商界,则表示为市场的胜利和失败。其实都是一回事。
三国演义有一句话,叫做天下大势,分久必合,合久必分。其根本就在于实力。
目前的微软,很像中国战国末期的秦国,虎视六国,至于它的下场怎样,我看最后也会一样的,始皇死而地分,美国的反托拉斯法案最后会处理它的。我看这也是目前遏制微软的唯一办法了。垄断终归不是好事。
哈哈,扯得太远了。


software_young 编辑于 2002-02-01 13:55
----------------------转载结束---------------------