随着各家厂商的强力背书与推销，
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
，你能想象这种情况吗
??
| ||||||||||||||
|
| ||||||||||||||
| ||||||||||||||
