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

（出处：DelphiFans.com）