2015年5月8日 星期五

Delphi COM 的再認識

在發展delphi 上WEB的過程,由於整個專案是利用DOT NET 呼叫Delphi 的COM Server。因此,很自然就研究起Delphi 的COM架構。不過,也遭遇了幾個困難:
1. COM+ 跟 COM的註冊是截然不同。
2. COM的 TYPE LIBRARY 如何繼承。
3. COM的 Instance 的選擇。

   由於透過IIS呼叫,一定要是COM+的註冊方式,但Delphi 內建的 COM註冊程式只支援COM,不支援COM+,因此,專案的一開始,單單這問題就搞了快一個月。

   由於希望每個專案能有自己的COM SERVER,最終是一台電腦可獨立運行多個專案,但問題是,每個專案都是由模板專案產生,但TYPE LIBRARY要不同。如此一來必須是繼承,才能達到目標,但第一次摸索delphi 的TYPE LIBRARY繼承要花了一點時間,不過,也因此感受到delphi在這方面支援不錯。

   基於過往的使用經驗,很自然選擇ciMultiInstance(Delphi Create COM 中的一個選項)。 但問題來了,delphi 的MultiInstance 是要自己實作,這問題找了資料之後很快就突破了,真正問題在上線之後。

   再經過一年左右奮戰終將專案完成,懷著戰戰兢兢的心情既期待又怕受傷害的心情,測式上線。剛開始無異狀,因上線人數不多,但人數一多COM SERVER會死當。這下心情跌到谷底。因為,這種Run time 的錯誤特別難抓。想想這問題不僅底層須解決,讓問題更複雜是:客戶買了這產品回去,還會自行加工。那如何避免Server如何死當,不僅底層程式碼必須注意,客戶也要有足夠的知識避免,那這教育訓練成本未免太高了,於是思索如何讓每個Server 都是獨立不會互相干擾,當成是研發的方向,而且就算Coding 不到位也無妨,果然一試之後,COM Server 再也不當,甚至比NET 研發更穩當。

PS: 不過,獨立的COM SERVER研發也帶來別的挑戰。不過,這不是本次文章的主題,故不在此深述。