随着各家厂商的强力背书与推销, 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 ,你能想象这种情况吗 ??
RemObjects SDK 的特征 以下列表概述了 RemObjects SDK 的核心特征,这些特征是目前可用版本中都拥有的。请跟踪连接以获取这些特征的更多信息。 总特征
库特征
Service Builder 特性
IDE 集成特性
网络服务
| ||