友情提示:如果本网页打开太慢或显示不完整,请尝试鼠标右键“刷新”本网页!阅读过程发现任何错误请告诉我们,谢谢!! 报告错误
热门书库 返回本书目录 我的书架 我的书签 TXT全本下载 进入书吧 加入书签

borland传奇-第52章

按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 Enter 键可回到本书目录页,按键盘上方向键 ↑ 可回到本页顶部!
————未阅读完?加入书签已便下次继续阅读!



地吸引新的应用和力量进入、使用这个架构。这种软件群聚的效应正是企业级信息技 
术应该形成的现象,因为唯有如此,才能够让影响力不断扩大。当初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 引擎的转换之后, 
就可以调用远程的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这个解决方案之后,终于有了进入可提供企业级 
应用程序�
返回目录 上一页 下一页 回到顶部 赞(1) 踩(1)
未阅读完?加入书签已便下次继续阅读!
温馨提示: 温看小说的同时发表评论,说出自己的看法和其它小伙伴们分享也不错哦!发表书评还可以获得积分和经验奖励,认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦!