borland传奇-第33章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
就让我们以EJB服务器市场这个实际的竞争范例来看看信息产业是如何竞争和演化的
吧。三四年前，当EJB市场开始成长时，许多软件厂商相继投入这个潜力十足的市场。
当时，所有EJB厂商竞争的基准大概都是符合EJB规范、使用最新JDK标准以及执行效
率最良好的EJB服务器。当时竞争的EJB服务器可以用满山满谷来形容，为什么呢？因
为在这个阶段纯粹是以技术为决胜点，这个门槛并不高，拥有技术的软件人才多得是。
因此，这个阶段中有眼光和智慧的厂商便了解到，光凭EJB服务器引擎是无法作为胜
出的要件的，必须想办法增加竞争门槛以阻绝竞争对手持续逼近，或是增加〃软件服
务〃以提供竞争对手没有的功能。
到了EJB服务器竞争的第2阶段，逐渐胜出的EJB厂商便开始为EJB服务器加入各种服务，
其中一类是以增加商业应用服务为主，例如Portal Service、ERP Service等。而另
外一类则是以技术服务为主，例如分布式交易服务、安全服务等。由于这些软件服务
的加入，在EJB服务器竞争的第2阶段便逐渐产生了EJB服务器的领先群，许多其他的
EJB服务器厂商在眼看竞争无望之下自然地退出了市场，HP就是一个例子。
现在EJB服务器市场又进入了最后厮杀的阶段，因为在领先群中的厂商大都提供了类
似的服务。那么接下来要如何竞争呢？IBM很快就看到了关键点，那就是为WebSphere
加入整合开发平台的能力。通过并购Rational取得Modeling工具和技术，IBM可结合
原有的Java开发工具为WebSphere形成一个关键开发平台，同时吸引企业使用者以及
开发人员为WebSphere形成的企业平台开发更多的客制化服务，以便为WebSphere形成
势力强大的专属力量。这是WebSphere最大竞争对手WebLogic目前没有的优势。
从EJB服务器竞争的过程来看，致胜的关键便是软件人员是否能够看到别人看不到的
优势、并提供额外的服务。对于软件人员的发展，道理也是同样。大部分的软件人员
都只注重在特定的开发工具或是程序语言中精进，但似乎都是随着别人的脚步而前进，
少数软件精英除了在信息技术领域有高人一等的修为外，真正胜出的却是能够为自己
增加附加价值、提供创造力的能力。就像JBuilder的Chief ScientistBlake Stone，
为什么他能够在年纪轻轻的情形下成为领导者？许多资历、年纪都比Blake Stone
多的研发人员反而只能当工程师呢？很简单，因为Blake Stone更早地看到了JBuilder
的发展趋势和竞争策略，掌握了Java开发工具发展的动脉，能够为JBuilder开发团队
提供更多的价值，再加上坚强的技术实力，终于成为家喻户晓的Java天才。
我一直认为任何软件技术终将被大众所熟知和掌握，就像数年前的主从架构一样，因
此光凭借技术并不能让人领先多久。反而是通过平日不断培养的眼光和趋势、再加上
专业的技术才能够让软件人员保持在领先群中，并且掌握软件趋势的动脉。拥有这种
特质的软件人员能够不时的提供服务，不时地为团队提供持续的创新力，自然也就能
够百战百胜了。
结论
人类对于新事物的害怕，通常都是由于对新事物的无知所引起。同样，软件人员对于
未来的困惑和焦虑则来自不知如何是好，这也是对于未来趋势发展的无知所引起。本
节中，我们通过分析、观察和统计了解了以往、现在和未来软件趋势的发展，当事实
的走向豁然开朗之后，困惑和焦虑不再重要，软件人员反而应该反躬自省地自问：面
对未来，我们准备好了没有？
不管Java和两大平台之间的战争如何，不管哪一个软件组件或是程序语言会获得
最后的胜利，世界对于软件系统快速开发的要求不会因为那一方胜出而改变，软件人
员必须准备好面对这个趋势。想想，JBuilder以每半年一个新版本出现，Java JDK和
也几乎以1年半之间推出两个版本的速度在彼此争战之中，连传统的开发工具现
在也几乎以一年一个版本的速度出现。更夸张的是，Internet/Intranet的技术现在
几乎每3个月就有一番新的面貌，开发人员应该如何自处呢？
机会可能会降临在每一个人的身上，但是只有时时准备好的人才能够把握住机会，不
让它从手缝中溜走。
^v^v^v^v^v^v^v^v^v
第十一章 EJB对抗CORBA？有趣的假设
〃组件模型的两大巨头终将对决？〃
什么是？我们可以从各种技术角度探讨，NET的技术书籍也可以撰写成几十
本、甚至是上百本。但是Microsoft提倡，最重要的目的是提供一个足以和Java
平台对抗的〃企业平台〃（Enterprise Platform）。Microsoft希望企业能够使用作
为企业应用系统的核心平台，根据这个企业核心平台再开发各种应用系统，连接新式
的移动设备（Mobile Device），形成企业应用系统需要的完整信息供应链，提供类似
目前Java拥有的企业业务。Microsoft希望通过打入企业市场的企图是不言而喻
的。
为什么Microsoft急于打入企业市场呢？主要因为企业市场是获利最为丰富的市场，
也是Microsoft长久以来最想进入的市场。另外，Microsoft不希望Java独占企业市场、
进而产生对Microsoft的威胁，这是第二个关键因素。其次更重要的原因是，Microsoft
在客户端几乎已达饱和，继续成长的空间有限，需要另外能够持续成长的市场，而企
业市场、消费端市场、通讯市场以及游戏市场就是Microsoft注重的目标了。
Microsoft要想打入企业市场，需要面对的是表现愈来愈好的J2EE架构。目前J2EE已
经被愈来愈多的大型企业用作企业核心的信息技术。根据Gartner Group的调查，EJB
的架构将逐年增加，到了2003年将会拥有超过40％的使用率。这代表EJB将成为企业
应用系统的核心组件架构，更多的企业系统将使用J2EE来建制。
这些现象在大型的信息业界反映得非常真实和明显，例如台湾的台积电（TSMC）、联电
（UMC）和友达光电等都已经在使用Java和J2EE作为新一代信息系统开发的核心技术。
再看看目前EJB服务器的两大领导厂商产品BEA的WebLogic以及IBM的WebSphere。
WebLogic和WebSphere除了已经成为许多企业的核心J2EE服务器、提供企业开发应用
系统的基石之外，还慢慢形成了企业应用系统的解决方案中心，并从其中衍生出许多
新的软件需求和应用。例如许多的Portal系统、ERP、CRM或Web Service应用都围绕
在这两个J2EE服务器的外部进行增值的应用。这种现象已经开始形成非常巨大的力量，
让EJB服务器的竞争从EJB核心服务器演变到EJB解决方案的地步，宛如一个黑洞在不断
地吸引新的应用和力量进入、使用这个架构。这种软件群聚的效应正是企业级信息技
术应该形成的现象，因为唯有如此，才能够让影响力不断扩大。当初Microsoft的
Windows就是这样，吸引了全世界程序员为Windows开发应用软件，以Microsoft Windows
为应用的核心，这才造就了Windows成为全世界客户端操作系统的霸主。
由此可见，一个核心软件技术对于信息应用的重要性。当初Microsoft在Windows上力
推/＋组件模型，希望它们成为Windows上的核心组件技术，提供企业在Windows
平台上开发企业应用系统的解决方案。其实以效率来说，＋的确是不错的。根据许
多的测试以及TPCC上公布的结果来看，＋的执行效率几乎是最好的。而前段时间The
ServerSide上公布的EJB对＋的评比更是闹得满城风雨。Java业界仍然不肯承认＋
比EJB来得有效率，但是以目前的数据来看，在Windows上EJB的确远远比不上＋。
在Microsoft多年的推展之后，/＋的确也有了不错的使用结果。根据2002年北
美关于＋的信息调查显示，使用＋技术的人占了34。3％，而且还有9％的人回答
将会采用＋。虽然＋在执行效率方面表现很好，但不可否认的是＋只能在Windows
平台使用，而且在Internet应用中使用不便，延展性也不若EJB，这都是＋致命的
缺点。
核心组件技术
既然Microsoft希望成为企业应用的平台，那需要提供什么呢？除了开发工
具之外，最重要的便是提供一个类似J2EE架构的软件解决方案，以吸引软件人员
为开发企业级的应用系统，帮助打入企业市场和Java平台竞争。
那现在的中有什么类似J2EE架构的技术呢？从下图我们可以清楚地看到，Microsoft
在中正逐渐建立起同SUN Java平台竞争的技术核心。Microsoft和SUN的虚拟竞争
平台现在几乎非常类似，不过，目前的Java在组件技术的领域远远超过了Microsoft
提供的解决方案。
Microsoft在中的组件技术是以组件配合＋为主。＋在中转为操作
系统的核心服务，提供事务管理（Transaction Management）的功能，而组件则可
以同时扮演中的可视化组件（Visual ponent）、数据感知组件（Data…Aware
ponent）以及中间件（Middleware ponent）。然而使用组件作为平台中
间件有许多问题。首先是组件必须依靠＋组件提供分布式事务管理能力；另外，
组件目前也没有像EJB一样的Fail…Over和Load…Balancing能力，这在企业级的应用
中是明显不足的。
此外，组件必须和＋一起搭配使用，这意味着程序员必须开发＋组件，而。
NET的原生工具无法开发＋组件，程序员还是必须使用原生的Windows开发工具。此
外，一旦使用了＋，代表此应用系统无法移植到其他的平台。如果Microsoft
把移植到Linux或是FreeBSD上，那使用＋组件的应用系统将无法移植到这
些平台之中。
那么，Microsoft是不是需要一个新的、能在平台使用的组件架构呢？就我的眼
光来看，如果Microsoft希望把平台定位在企业系统同J2EE竞争，那的确是需要
这种技术，但这对于Microsoft是有一点困难的。首先，Microsoft正忙于在一二年内
达到Java平台花了七八年的成果，正忙于开发本身、开发工具、下的数
据库，并且把所有的Microsoft Server应用程序移植到之下，可能一时无法投入
太多的资源来开发一个全新的企业级的组件架构。
另外，再看看Microsoft建立组件架构的历史就可以了解到，在这方面Microsoft的确
不太在行。期望Microsoft在短时间内在平台定义类似EJB的企业组件架构的规格
并且将其实现出来，似乎是不太容易的事情。
组件技术 结果
16位VBX 失败
32位VBX 失败
OLE 失败
尚可
ActiveX 失败
MTS 失败
＋ 不错
组件 不适合使用在企业级应用中
既然新创下的企业组件架构不是短时间内可以完成的，那是不是代表着在这
方面已经无法和J2EE竞争而提早出局呢？其实并不一定，因为如果无法快速开发一个
新的组件架构，那为什么不使用已经存在且已经验证是适合企业应用的组件架构呢？
让我们想想的特性和需求是什么，就可以推知什么组件架构最适合在平台下
成为企业级的组件架构了。
什么组件架构已经使用过很长的一段时间，且经过了市场的验证呢？
→ CORBA、EJB和＋
什么组件架构可以跨平台？
→ CORBA和EJB
什么组件架构允许多种语言开发和使用？
→ CORBA
从上面的问题中，我们已经看到答案是呼之欲出了。更关键的是上面的第3个问题。
由于是一个语言中立的平台，程序员可以使用任何语言来开发应用程序，因
此在平台的组件架构必须能够让各种不同的程序语言来开发和使用，而不像EJB
一样只能使用Java语言。对比一下，CORBA正好符合语言中立的要求。此外CORBA是一
个跨平台的组件架构，可以随着移植到各种平台。因此从各方面来看，CORBA实
在非常适合使用在之中并成为的核心组件架构。
CORBA和EJB
CORBA已经在企业应用系统使用了很长时间，是一个架构成熟、经过了市场严格考验
的组件技术。在CORBA之后的许多组件架构其实也都学习了CORBA。例如J2EE中的EJB
规格可以使用CORBA来实现，在EJB 2。0之后也要求EJB服务器必须和CORBA兼容，由此
可见CORBA组件架构的重要性和成熟性。目前，CORBA仍然是一个在持续发展中的组件
规格，OMG也持续为CORBA定义更为完整的核心和服务规格。
CORBA使用的Stub/Proxy以及组件服务架构深深地影响了＋和EJB的实现架构，以致
＋和EJB组件架构和CORBA都有许多神似的地方。
由于CORBA几乎是其他组件架构的始祖，因此CORBA绝对有能力、有份量和EJB分庭抗
礼。如果能够在其平台上以CORBA作为核心组件架构，那么就可以提供同J2EE
一样好的企业应用架构。虽然许多人会质疑在PC上执行企业应用系统会不会力量不够？
但是，随着64位的CPU（Intel和AMD）即将推出，Microsoft也准备推出64位的操作系统。
在虚拟执行环境的保护下，如果再加上安全强固的CORBA，那么的确可以提供
相当有竞争力的企业执行平台，与J2EE在中/低阶的企业应用中竞争。如此一来，
Java/J2EE就不再拥有企业应用中的绝对优势了。
既然CORBA对于Microsoft 平台的企业运算有这么大的助力，那么CORBA组件架构
在平台上将以什么样的架构来提供服务呢？
CORBA For
CORBA要如何在平台上提供企业级的服务呢？由于CORBA使用IIOP通讯协议作为调
用CORBA服务的接口，因此传统的CORBA引擎（例如Borland的VisiBroker），应该会为
CORBA伺服端和客户端产生可连接的DLL或是函数库，这些DLL和函数库就负责让客户
端通过IIOP调用伺服端的CORBA服务器。因此CORBA即使是执行在平台中，也是使
用IIOP作为调用的通讯协议，如右图所示。
不过，在下Microsoft是使用 Remoting机制作为远程和分布式沟通的通讯协
议。那么，的CORBA开发工具要如何结合的Remoting机制、并且允许下
各种不同的语言通过IIOP调用远程的CORBA服务呢？
其实，这同在Windows下提供原生窗口开发工具开发CORBA应用系统几乎是一样的，只
是在下CORBA引擎必须进行一些额外的工作以让的开发工具和应用程序能够
使用CORBA技术。
首先，下的CORBA开发工具必须能够提供下主流程序语言的支持，这代表CORBA
For 必须为每一种程序语言产生客户端的CORBA Stub和伺服端的CORBA
Proxy。其次，为了和 Remoting机制结合在一起并提供IIOP的能力，CORBA For
必须产生一个Adapter和 RemotJng作为沟通的机制， Remoting通过这
个Adapter再调用最底层的CORBA For 引擎，CORBA For 引擎再把 Remoting
的调用惯例转换为IIOP通讯协议。经由Adapter和CORBA For 引擎的�
