Web Services 俨然成为未来分布式系统开发的主流架构,但是
Web Services 至今仍然存在一些问题,其中有些是属于规格的问题,有些则是先天上的限制,许多使用
Web Services 开发系统的人都会有一个困扰,那就是效率不高,其原因很简单,
XML 本身属于纯文字型态,加上必须依赖
XML Parser 剖析
XML 文件,在传输与解译上都是造成效率不彰的原因,这是
Web Services 的先天限制,也是为了兼容性所付出的代价。当然
! 如果网络频宽够大,计算机速度够快,这些都不是问题。但事实是目前的频宽与计算机速度还不足以胜任,这使得
Web Services 的应用面缩减不少,因此许多的
Web Servcies 开发工具都会提供将
SOAP 讯息压缩的解决方案,藉此减少网络传输时间。另一个问题则是
Web Services 必须依赖网络通讯协议,以现今的情况来看是以
HTTP 或
TCP 两种网络通讯协议为主流,假如客户想将系统安装于一台计算机上
( 不管是何理由,或许是因为节省金钱
) ,
Web Services 还是需要一个占用
Port ,就实务上来看这并不是什么大问题,但如果可以不占用
Port 岂不更好
?? RO 就是这样一套组件,首先
! RO 支持两种讯息标准,一个是
SOAP( 也就是
Web Services) 、另一个则是
Binary( 二进制讯息
) ,支持
SOAP 可让其它支持
Web Services 的开发工具经由
SOAP 连上
RO Server ,支持
Binary 可以让
RO Client 以更快的速度与
RO Server 沟通,这比起将
SOAP 压缩后传递的效率高上许多,更令人兴奋的是
RO 允许设计者混用这两种讯息协议,也就是说只须撰写一个
Server 并放上这两个讯息组件,这一个
Server 就可以同时服务使用
SOAP 与
Binary 讯息的
Client 端。有趣吗
?? 更有趣的事情还在后面,
RO 支持
HTTP 、
TCP 、
Windows Message 、
DLL 、
UDP(2.0) 、
MSMQ(RO Enterprise) 多种通讯协议,并且允许设计者混用这些协议
(DLL 是例外
) ,简单的说
! 就是写一个
Server 同时允许
Client 端以
HTTP 、
TCP 、
Windows Message 、
UDP 、
MSMQ 方式连结,再加上之前所提的两种讯息标准,这个
Server 是不是更有趣了呢
?? 呵
! 还没讲完呢,
RO 不但具备这些特色,同时也允许设计者撰写自己的讯息协议与通讯协议,其步骤也不复杂,这些都是
RO 出色的主要原因。另外
RO 也支持
Kylix 3 for DELPHI ,这代表着使用
RO 可撰写
Linux Server/Client ,
Windows Server/Client ,日后的
RO Client SDK.NET 支援
.NET Framework 、
Mono 、
Ractor ,及
Compact Framework ,你能想象这种情况吗
??
| ||||||||||||||
|
| ||||||||||||||
|
||||||||||||||
再分享一下我老师大神的人工智能教程吧。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow
发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/226020.html原文链接:https://javaforall.net

