按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
既然新创下的企业组件架构不是短时间内可以完成的，那是不是代表着在这
方面已经无法和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 引擎的转换之后，
就可以调用远程的CORBA服务和CORBA服务器，甚至通过RMI Over IIOP调用到远程的
EJB服务器，如下所示：
上面说明的架构还是比较详细的。由于在下各种程序语言都会被的编译器转
换为的IL，因此CORBA For 工具可以产生一个IL型态的客户端CORBA Stub。
如此一来，不管程序员使用的程序语言是什么，都可以保证能够通过这个CORBA
Stub来调用远程的CORBA服务。这个架构其实比以前Windows下的CORBA开发工具更容
易，因为在Windows下，CORBA厂商还必须为不同的程序语言产生不同程序语言的客户
端CORBA Stubs。现在下CORBA厂商反而因为几的特性而更轻松和一致了。
一旦CORBA厂商能够在下实现CORBA For ，那么不但可以让的程序员开
发真正企业级的应用系统，更由于CORBA和EJB是兼容的，因此下的CORBA服
务器也能够通过RMI Over IIOP调用和整合EJB服务器，提供和J2EE无缝整合的能
力，并且允许使用者的应用系统能够从平台顺利地移转到J2EE平台，如下所示。
更何况，现在许多的EJB服务器还能够像管理EJB对象一样地管理CORBA对象，这意味
着执行在Mainframe或是UNIX/Linux的EJB服务器能够管理和整合执行在中的CORBA
对象或是CORBA服务。有了CORBA这个解决方案之后，终于有了进入可提供企业级
应用程序架构的能力了。
巨人终将对决？
CORBA的复杂度使其一直未能被广大的程序员所接受，现在的CORBA本身已经非常安全
强固，而且经过了十几年企业市场的考验（即使是EJB也不过在企业市场才经历了2个
版本的洗礼），CORBA的开发厂商应该已经清楚，CORBA不被大多数开发人员接受的原
因并不是CORBA不够好，而是CORBA太复杂。因此这些开发厂商应该舍弃CORBA中鲜为
人用的服务，先提供一个完整的CORBA引擎以及企业应用最重要的两个服务事务管
理服务（Transaction Service）和安全服务（Security Service）。更进一步的是，如
果CORBA厂商能够在客户端提供的组件来封装比较复杂的CORBA调用和存取机制，
并且结合数据存取的能力，那么，下的程序员将能够以非常快的速度学习和使用
CORBA组件架构。如此一来，CORBA将有机会在平台中大展身手，有机会成为
平台中最有潜力的组件架构，也将有机会让CORBA一吐闷气，让世人了解CORBA的价值。
〃EJB和CORBA两大巨人终将对决〃？不，更正确的说法应该是J2EE/EJB终于找到了可敬
的对手/CORBA，而CORBA和EJB也将进入〃既竞争又合作〃的时代，当然前提是有
厂商推出CORBA For 的软件产品。
^v^v^v^v^v^v^v^v^v
第十二章 回到C/C＋＋的王国
〃让我们重返荣耀之都吧！〃
当年Windows平台C/C＋＋开发工具四大天王一战，在Microsoft取得了市场的主导力量
之后，C/C＋＋开发工具的市场和竞争反而缓慢了下来，Windows上C/C＋＋开发工具的进
步也开始牛步化。VC＋＋一连两三个版本的进度幅度并不大，除了稍后推出的ATL还有
新意和技术革新，VC＋＋编译器除了在C/C＋＋语言上更趋近于标准之外，MFC本身几乎已
经没有什么大的进步了。在Wat和Symantec退出市场之后，VC＋＋也顺利地接受了
Wat和Symantec的市场。而Borland C/C＋＋虽然也损失了大量的市场，并且失去了
C/C＋＋的王座，但是在数年后，Borland推出C/C＋＋Builder，以C/C＋＋ RAD工具、以及
更符合ANSI C/C＋＋标准和VC＋＋进行市场的区隔，也慢慢地收复了一些失地。虽然
Borland C/C＋＋工具系列已经无法像以前一样是市场第一的C/C＋＋开发工具，但是
Borland在Windows的C/C＋＋开发工具市场仍然占有30％强的市场份额。
C/C＋＋开发工具在C/C＋＋ Framework一战之后，开发的重点却似乎模糊了起来。由于VC
＋＋没有强劲的竞争，因此整个的发展速度缓慢下来。不过C/C＋＋技术在C/C＋＋语言、函
数库（Library）和通用Framework方面却快速地如雨后春笋般兴起。特�