RemObject+SDK学习资料 2013-04-18.docVIP

RemObject SDK学习资料 前言 DELPHI 的3rd-Party 元件數量之多，遠超過其它的開發工具，其用途之廣可說創下前所未有的記錄。這也為DELPHI 程式設計師省下許多重新製造輪子的時間，令系統開發速度倍增，同時減少了因實作碼增加而使錯誤率升高。可惜的是VCL元件似乎都有著一個通病，就是缺少完整的說明檔!許多VCL 元件甚至連範例都少的可憐，幸運的是VCL 元件有個不成文的慣例，那就是多數都會附上完整的原始碼，這一點可以稍減其說明檔不足的現象。即便如此，說明檔不足依舊對使用者造成相當大的困擾，時間就是金錢，在設計者探索原始碼時，時間也一點點的流失了。本文所介紹的RemObjects SDK(以下簡稱RO) 也不能例外，由於這套元件的開發者只有兩位，因此說明檔一直都是相當短缺，有些地方甚至還有描述錯誤的情形，但這些缺點卻無法掩蓋其嶄新的創意與高延展性的設計概念，這也是本文為何會出現在讀者眼前的主要原因，RO是筆者看過VCL 元件中唯一令筆者感到驚豔的，當然! 這只是筆者個人的感覺，對讀者不見得是如此，不過多了解一樣東西，於汝何損?? 因此，細細品嘗吧!! ?PS:本文省略了討論Web Services的基本知識部份，如果讀者對於Web Services不熟悉，可參閱筆者的另幾篇文章。 What’s RemObjects SDK 隨著各家廠商的強力背書與推銷，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，你能想像這種情況嗎?? PS: TCP 與 Windows Message同時只能支援一種訊息格式，如SOAP 或是 Binary，原因是這兩種協定並沒有類似URL的概念，HTTP則無此限制，另外RO Enterprise SDK將會支援.NET Binary(.NET Remoting) 與RO Binary 兩種格式。 初試RemObjects SDK 談了這麼多空話，現在是時候試試RO的