Translate

2015/02/11

決定 DataSnap 輸出的通訊協定

DataSnap 提供豐富的傳輸方式。其中包含:

基於 (D)COM / COM+ (MTS) 的有:
  • Socket
  • Web HTTP

基於通用協議的有:
  • CORBA
  • SOAP
  • RESTful

在 XE 之後的版本,基於 COM 的 DataSnap 已經停止開發新的功能。

主要的原因是基於 COM 的 DataSnap 無法在行動裝置上被使用。

但如果仍然是以 Windows 桌面平台為主力,使用 COM 版的 DataSnap 仍然能享有最大效能的網路傳輸服務。

DataSnap 區分為 Server 端和 Client 端設計。

基於 COM 的場合:
Server 端設計上又分為邏輯程式及橋接程式設計:
1. 邏輯程式設計:以 COM / MTS 等註冊元件服務的方式存在。
2. 橋接程式設計:決定 Client 可以使用 Socket / HTTP 的通訊協定連入。

Client 端:
依照 Server 能夠提供的通訊協議,設定指定的連線元件進行連接。

基於通用協議的場合:
代表 CORBA 開發的 VisiBroker 在 Delphi 7 之後的版本已悄悄消失,不再被預載入 Delphi 的產品內,有在開發 CORBA 版 DataSnap 的開發者一定底子很好。但我是直接放棄它的使用,哪怕它有再好的能力,因為 Delphi 早已不支援 CORBA 新的技術版本了。

SOAP 在 Delphi 5 時可紅極了,設計 SOAP 的技術資料不斷的被推出,只是 SOAP 的技術理論要搞懂真的不是件簡單的事,Delphi 真的把 SOAP 變簡單了嗎?

RESTful 是從 Delphi 2009 加入的開發方向,基於 Indy WinHTTP 技術再替 DataSnap 注入新的氣象,在當時行動裝置主要以 JSON 做為與伺服器的資料交換,於是 RESTful 就此晉升為跨平台解決方案的主力。

Server 端:
邏輯和橋接會併入同一個開發專案使用,Delphi 按服務通用規範打造橋接程式內容,使用者只需專注在邏輯程式的開發即可。

Client 端:
依照 Server 能夠提供的通訊協議,設定指定的連線元件進行連接。

以上可以得知,不論 Server 端如何變化, Client 端的設計是很固定的。

而且,它的通訊協議也有個專屬名詞:MIDAS

--- 未完待續 ---

沒有留言:

張貼留言

Delphi 自動化 JSON 格式相容性分析

Delphi 自動化產出的 JSON 格式一直被詬病著,因為它的 JSON 格式在起始處一定會強制寫入「Meta Data」,它看起來像是: "table":[["EmpNo",6,0,0,0,4,0,0,false,false,...