S
scureader
Unregistered / Unconfirmed
GUEST, unregistred user!
JChang
幼幼班
Canada
9 Posts Posted - 12/16/2001 : 12:51:41
--------------------------------------------------------------------------------
2001/07/02 星期一, 是個重要的日子, 這個營業額近一百億的公司, 共計海內外 5 個資料庫, 11 個營業據點, 12 條 internet 專線, 4700 名員工, 今天要轉換系統, 總公司的 database 要從 Oracle v7.33 換成 v8.17, 更要從 client/server 換成 3-tier, 經過長時間的測試再測試, 延後再延後, 今天將不再順延, 全公司就靠妳了, Delphi!
6/30 v7.33 資料庫停止服務, 與其他資料庫中斷 replication, 在資料 export 之後, 當日深夜開始 import 進 v8.17, 這個動作已經演練了好幾次, 一切順利.
7/1 星期日, 外頭是艷陽高照, 假日的辦公大樓, 機房則是幾十台機器發出如火爐般的高溫, 大家已經在這個小房間裡日以繼夜的熬了好幾個星期, 總算已經到了該攤牌的時候了, 3 台 ap server 就緒, web-server 啟動成功, 第一個帳戶登入, 第二個帳戶登入, 第三, 第四...整個過程順利的難以置信, 在向老闆報告了工作狀況後, 確定明天轉換系統!
7/2 星期一, 早晨 8:30 user 開始湧入辦公室, 新的 HomePage show 出以下公告:
1.舊系統所有功能自即日起由新系統替代.
2.在 30 天之內舊系統仍保留查詢功能.
3.海內外之資料同步預定 7 日內恢復.
4.請各位同仁注意所公佈之學習課程.
...
11:00am
[主機還好嗎?]
[沒什麼 loading, 所以還看不出來.]
[為什麼?]
[大部分都還不會操作, 在等訓練課程.]
11:30am
[教室裡有一台 pc 出現 RPC 伺服器的 error message.]
[然後呢?]
[還在解決中.]
11.35am
[不好, 大部分的 user 都出現同樣的訊息, RPC error.]
[程式重新啟動呢?]
[也不行, David 課也教不下去了.]
[server 狀況怎麼樣?]
[Oracle 正常, ap server 沒有 loading, 但也連不上]
[是哪台出問題?]
[好像全掛了.]
...
[通知 user 下課吃飯, 下午繼續!]
大家看了便當, 卻一點食慾都沒有. 離下午上班還有 90 分鐘可以想對策.
[ap 重開就正常, 會不會是剛才線路出問題?]
[可是除了 ap 其他 server 全正常.]
[ap 的網路卡出問題?]
[可是 3 台都掛了.]
[奇怪, 測了這麼久都沒碰到這個什麼 RPC error, 上線第一天就掛了...]
[會不會是這些正式的 server 與之前測試的環境不一樣?]
[唯一不同的就是從前只有一台 ap, 而現在則是 3 台.]
[會不會是 load balancing 出了問題?]
[... 可是, SimpleObject 只是分配一個 ap server 給 client, ap 當掉跟 SimpleObject 有關係嗎?]
[不管, 下午先將 2 台 ap 離線, 只用一台看會不會好一點.]
1:40pm
[各位同仁很抱歉, 因為上午主機出了些問題, 所以現在繼續 ...]
2:00pm
[又是 RPC error!] Jerry 驚叫.
[ap 又掛了.]
[重開!]
[...]
好不容易熬到下班, 也數不清當了幾次. 同樣是這些人, 同樣是愁眉苦臉對著便當吃不下. 中央空調過了七點就沒了, 而夜卻長的很.
[ok, 看來唯一與測試環境不同的就是 loading, concurrent user 多了, ap 就掛了.]
[今天有多少 user?]
[教室裡 20 個, 外頭也有一些, 但教室這些是跟著老師的課程走, 所以會同時做相同的動作, 所以 ap 受不了.]
[才 20 個就受不了? 那這什麼爛貨, 還有誰敢用.]
這些人已經幾星期沒睡好覺, David, Jerry 更是好久沒回家了, 心中的怒火似乎就像外頭的氣溫.
[ap service 是用 Single 或 Multiple?]
[有沒有可能是 Oracle 817 的問題?]
[有沒有可能是 Socket Server 出問題?]
[有沒有可能是 ap 與 Oracle 中間的傳輸有問題?]
...
疑點愈來愈多, 但要從何下手? 而且做任何的改變都等於是拿真實環境做實驗, 一點退路都沒有, 頭上幾天 user 還能忍受, 只要再過幾天, 肯定就有人告到老闆那兒去, 那就 ...
[吃飯, 等一下把所有的 ap service 都改成 Single, 而且都裝到 817 同一台, 明天再跑跑看.]
這個改變可以知道 Single 與 Multiple 有沒有差別, 而且可以把 Oracle 與 ap 中間傳輸的問題給先排除, 讓問題比較好抓. 唉! 所有的狀況都事先做過測試, 就缺找 20 個人同時 run 一個 program...
7/3 星期二, 大家拖著疲憊的身子, 再度面臨沉重的一天.
[可以上課了嗎?]
[嗯! 開始]
所有人注意的焦點都在 20 個 user 的螢幕.
[RPC, RPC, 不要出來 RPC...]彷彿在唸著咒語.
時間一分一秒的過去.
[有 RPC 嗎?]
[沒有, 可是有 user 的 program run 一半當掉, 死當, 要強迫中斷才能結束.]
[多不多?]
[有幾個!]
[RPC 呢?]
[沒有.]
沒有 RPC error 了, 大家彷彿不信似的. 那到底是因為 Multiple 的問題, 還是 Oracle 與 ap 傳輸的問題造成 RPC?
再改, 下午再把 ap server 回復到 3 台.
中午休息時間似乎對所有的人都是個短暫的解脫, user 可以逃離這個讓人瘋狂的新系統, 而我們也可以關起門來想對策.
[早上 RPC 是沒有了, 可是因為只有一台 ap 而且 Service 都是 Single, 所以排隊的情形很嚴重, 往往一個 user 作個查詢要等前面 10 個人 run 出結果, 他才會有回應.]
[這可以先不管, 要確定 RPC 的問題已經解決, 否則這個系統根本 run 不下去.]
下午同樣沒有出現 RPC error, 看來很明顯是因為 Multiple 所造成, 雖然因為加到 3 台 ap server 排隊的現象緩和了些, 但 user 偶而會當掉 program 還是很令人心煩, 不過總比 RPC 要好多了.
[RPC error 是沒了, 可是 user 在抱怨做一個動作要等好久, 也不知道是當了還是在等待.]
[等了多久?]
[有 user 等了一二個小時.]
[天啊! 這麼笨, 當然是當了.]
[可是 user 分不出來要他等多久才算當掉, 而且往往打一張訂單, 在儲存時就沒回應, 你要他放棄將程式中斷, 他會殺了你.]
[...]
又是悶熱的夜晚, 還是這些人, 新系統上線第二天, user 加班變得更晚.
[耶! 存成功了!] 一個 user 冒出了一聲歡呼, 但我們這些人相對不語, 這一點都不好笑, 一筆資料能順利存成功, 變成了上天的恩賜.
這麼龐大的公司, 每天這麼多的交易, 現在竟然建築在一個這麼不穩的系統上, 而我們就是這些罪魁禍首.
user 也知道要避開白天跟許多人搶 server 的 space, 所以就在晚上補打單子, 但等發現到也有許多人有共同想法的時候, 也只能互相苦笑捉弄一番.
而我們這些精疲力盡頭腦已經不太清楚的人, 還要等到 user 走光才能開始下一步的實驗.
[ok, 誰能對 program 會死當提出看法?]
[...]
[其實真正死當的並不是這麼多, 因為有些 user 可能在還沒回應前就認為當了而中斷.]
[而且仔細分析並不是每支程式都會當, 而是集中在訂單系統.]
[訂單? 訂單有什麼特別?]
[...]
[訂單 master/detail 關聯比較複雜, 一共有 3 層 8 個 table.]
[...]
[ok, 看樣子要修改程式了.]
等待是令人期待的, 而結果卻是令人失望的, 要對一個正式的環境做實驗或調整, 是一件讓人手心冒汗的事, 但整件事情的發展已經失去了回頭的機會, 一次一次的失望都是用無數實驗與時間換來的, 我們已經無法宣告失敗, 要公司的資料庫迴轉到 6/30 的 Oracle 733, 沒有人承受的起這個損失, Oracle 也沒有 support 資料庫的 do
wngrade.
7/4 總公司對其他資料庫的 replication 啟動成功, 雖然新系統仍然有 program 死當的問題, 但企業的運轉還是不能停的.
7/11 JDN 的 user 連線成功.
7/12 HK 與 MEX 的 user 連線成功.
7/13 SPN 的 user 連線成功.
7/30 新的 HomePage show 出以下公告:
1.舊系統之查詢功能自即日起停止服務.
2.駐外單位已全數連線, 請總公司同仁不要再提供 fax, mail
...
從此總公司 client/server program 與 ASP CGI 網站全數停機, 不分遠近, 所有的 user 都是使用相同的 program 操作, 你可以從 TPE 輸入訂單, 而 MEX 的 user 可以同時在地球的另一邊將訂單開啟, 3 層 master/detail 共計 8 個 table, 這在過去是不可能實現的, 照理我們現在應該是歡欣鼓舞開香檳的時候, 但 program 會不定時的當機, 像個陰影尾隨不掉.
[BDE, Oracle 都做了 tunning, performance 有變好, 可是還是照當, 已經很多人告到老闆那邊去了.]
[想想一個 user 一天不要多, 只要當二次, 統統加起來就是幾百次, 老闆沒拿刀殺人就很仁慈了.]
[其實現在很明顯是 Socket server 出問題, 這玩意很不可靠, 但奇怪的是在 Socket server 掛掉的同時, DCOM 還是可以連的上, 要不要改成用 DCOMConnection 試試看?]
[也好, 死馬當活馬醫.]
8 月中的某一天, 天一樣的熱, 所有的程式都換成了 DCOMConnection.
[user 出現 "interface not support" 的訊息.]
[修改 DCOMCNFG.]
[ok]
替 user 解決 "interface not support" 的訊息不是難事, 重點是我們的運氣似乎開始好轉.
無疑 DCOM 要比 Socket 穩定許多, 一夜之間 program 變得不會當機了, 但要解決所有 user "interface not support" 的訊息並沒想像中簡單, 尤其是遠端的 WIN95, 98 ME 或 WINNT. 但重要的是可以報告老闆, 我們不會當機了!
解決這個問題不是靠 Borland 的文件, 也不是靠 patch, 而是靠運氣, Borland 並未告訴妳說 Socket 是有問題, 或是如何去避免, 雖然現在是解決了眼前的問題, 但還有多少問題是如冰山般未浮現?
以我們這個案例而言, 不靠決策高層堅定的支持, 早就宣告失敗砍人, 有幾個老闆敢拿公司開玩笑, 做無限制的實驗與等待, 故事的過程中除了對細節有所保留, 但所有的人物與時空背景都屬真實, 一方面為這場戰役留下紀錄, 也希望給所有投入在 Delphi 的工作者, 事業經營者做一個參考, 但我必須說既然在官方文件找不到的解答, 就不代表長久有效, 我們現在的環境是 Windows 2000 + Oracle 817 + Delphi 5.01 + DCOMConnection, 其中有任何一個改變了, 就可能得從頭開始再玩一遍.
這場仗打完了嗎? 才開始呢! 如果老闆不把我 fire 掉, 最起碼現在還有許多問題要克服:
1.Socket server 雖然不堪用, 但仍然有其優點, 其 port 固定(default 211) 在有防火牆的環境容易調整, 但 DCOM 竟然沒有固定的 port, 在有防火牆的環境裡死路一條. 這點不知該由 Microsoft 或 Borland 出面解決?
2.DCOM server 雖然穩定, 但在 WIN95, 98, ME, WINNT 的 client 環境設定非常複雜且不可預期.
3.CORBA 的優點講的令人佩服的五體投地, 但竟然無法穿越 internet, 至少這是 Borland 的說法, 若果真如此, 在 internet 的大環境中 CORBA 就出局了.
4.ap server 每隔二星期就得重開一次, 否則容易 BDE error.
5.ap service 只要 user 有 connection 就會吃一些 ram, 而且並不會因為這 connection 結束而釋放, 在 user 數多時這是很嚇人的.
6.BDE 支援 Oracle 8.1.x 是有名的爛, 光是 SQLORA8.DLL 就有好幾個版本, 讓人無所適從, 測到現在為止, 沒有一個是穩定的, 若要回到用 ODBC 就實在太可惜了!
簡單的講, 在有防火牆的 internet 環境裡目前 Delphi 似乎提不出解決的方法, 相信很多人會建議採用 web solution, snap, soap, web service...但我這裡講的是 ap, 若說要靠 web 做一套複雜的 MRP or ERP? 唉! 那只能祝你好運了!
放棄 Delphi? 坦白說不是沒有這個念頭, 但你會建議用什麼來替代? IBM 會說用 Websphere, Oracle 會說用 application server 9i, 每個公司都可以派一個 team 的 sales 來拜訪你, 但沒有一家會準備一個李維來解決你的問題, 若說要離開熟悉的 Delphi 投入另一批 sales 的甜言蜜語, 看來只是找機會讓老闆炒你魷魚.
終於還是鼓起勇氣將手上的 Delphi 6, Oracle 9i Database, Oracle Application Server 9i 分別裝進 3 台 server, 這一次要測的項目可多了:
1.Oracle 817 資料可否 export 到 9i?
2.Delphi 6 的 CORBA 與 Oracle 所附的 Visibroker 可否並存?
3.CORBA client 可否穿透 internet 連結 CORBA server.
4.CORBA 的 load balancing.
5.CORBA 的承受能力?
6.Delphi 6 的 Socket 可有改善?
只是為了實驗 817 database export 到 9i, 就將 Oracle 9i 重裝了好多次, 因為根本無法成功, 這點 Oracle 也提不出解決方法.
為了要將 Oracle Application Server 9i 連結到資料庫, 也重灌了 n 次才確定, 9i Application Server 竟然不能連結 9i Database, 只能連 8.1.x, 這可真夠邪門的了.
所謂重灌是指連 Windows server 都重新安裝, 你能想像花了多少冤枉時間去 try 一些令人無法置信的結果, 真正好戲是等到測 Delphi 6 的 CORBA 才開始登場.
當 Oracle 9i database, 9i Application Server 與 Delphi 6 都裝完以後, 你會發現竟然並存了好幾個 Visibroker 的版本, 光 Delphi 6 就可以讓你選擇 4.x 與 3.x 二種, 開玩笑, 當然是裝新版 4.x, 哪有裝舊的.
結果 Delphi 6 的資料庫元件竟然無法連結 CORBA 4.x, 唉! 只好又移除 Delphi 6, 再重裝一次, 這次就安裝了 CORBA 3.x, 果然, 可以順利做些實驗, client 可以連上 CORBA server, 而且 load balancing 也生效, 如同李維書上所說, 使用 CORBA connection 可以不用仰賴 SimpleObject 做 load balancing, 程式簡單多了, 但仍然無法穿透 internet.
再來的實驗呢? 做不下去了, 無數次的安裝移除, Delphi 6 不再讓我註冊了, Borland 美國的註冊 server 從此不再接受我的註冊, 縱然你手上握的是原版光碟, 但一下子卻成了非法的使用者, 我睜大了眼睛實在不敢相信, 這...Borland 實在讓我灰心透了, 不談這個小動作合不合理, 我實在對這一行突生厭惡, 我相信所有投入這個工作的人起始的出發點都是可敬可佩的, 我沒有遇到一個 programmer 是為了賺好多錢, 會在年輕時就開始了日以繼夜的工作, 他們所擁有的只是一個夢想, 雖不能當大老闆統領千軍萬馬, 但也能藉著完成一個電腦系統而實現管理化的那份成就感, 其中有多少人因為開發工具的先天不良而宣告失敗, 輕則離職, 重則賠錢挨告, 而所有開發工具的廠商能提出解決的方案卻是少之又少, 若你用 VB or Delphi 接一個 project, 最後可能因為失敗而被告, 但卻從來就沒有一個開發工具廠商因為這種事而被告, 他們每年不斷的要你花錢買一個修補漏洞的新版, 另外再送一些不穩定的新功能讓你測試, 現在, 乾脆直接說:
[嘿! 這個功能你只能測 10 次, 之後就 game over, 你必須重買一套.]
乖乖! 一套 Delphi 6 client/server 你知道要多少錢? 這個解決的方法歷經二個月 Borland 還是沒給我答覆, 也好, 不作實驗時間倒多出來了, 除了賞楓賞雪還可以寫寫文章投稿, 只是若不能再成為 Delphi 的 "合法" user, 這大概也是我在李維論壇的最後一篇, 從此不再玩 Delphi 了!
--
james
Sylix
幼幼班
11 Posts Posted - 12/16/2001 : 15:23:30
--------------------------------------------------------------------------------
有同感
dearkang
幼幼班
17 Posts Posted - 12/17/2001 : 00:11:39
--------------------------------------------------------------------------------
我在想這樣跨地理區域的系統是不是該用web當作interface比較適當呢？
在系統架構上大家是不是能提供一些意見？
guard
小班
78 Posts Posted - 12/17/2001 : 00:25:53
--------------------------------------------------------------------------------
但是用web來做AP我想以目前而言，真的是非常困難，在web環境，開發工具，使用者介面
都充滿著挑戰性。如果JChang先生出來寫作，相信也是一位好作家，因為其引人入勝的陳
述，可以為死板的電腦技術帶來更多的生趣。
dearkang
幼幼班
17 Posts Posted - 12/17/2001 : 00:35:38
--------------------------------------------------------------------------------
我想是否再確認李兄在其書中所提的：
給client的資料能做的少量、多次(fetch on demand)
減少client與remote server的呼叫往返(server把邏輯處理完後才把結果回傳client)
dearkang
幼幼班
17 Posts Posted - 12/17/2001 : 00:58:06
--------------------------------------------------------------------------------
※ 引述《guard》於 12/17/2001 00:25:53 發表之銘言：
>但是用web來做AP我想以目前而言，真的是非常困難，在web環境，開發工具，使用者介面
>都充滿著挑戰性。如果JChang先生出來寫作，相信也是一位好作家，因為其引人入勝的陳
>述，可以為死板的電腦技術帶來更多的生趣。
有沒有人試過用visual studio do
tnet來寫web form呢？
我覺得如果有delphi的基礎，vb.net或是c#都是非常容易上手的。
順便一提，我覺得vb.net的語言已經改到沒什麼重大缺點了，甚至就programming language
而言，可能已經超過object pascal。因此在公司裡，我很想把vb的程式員讓他們能成為vb.net的程式員（我不期望他們能接受C#或Java），進而能順便學習使用delphi，因為如果能搭配delphi及vb.net(或c#)一同使用(以COM當作interface)，對程式員來說，不儘在職業生涯或是工作上都是利多於弊的。
drowsy
幼幼班
China
37 Posts Posted - 12/17/2001 : 09:53:36
--------------------------------------------------------------------------------
建议不要使用BDE,而使用ADO Microsoft driver for oracle 很稳定，效率也很好；dbExpress 则提供了更好的效率，稳定性不敢说。
关于DCom Server 的设定，我想可以借助安装程序来完成，应该不是什么问题。
我喜欢borland 的delphi，目前使用delphi6， 做3曾开发和web开发，很好用，borland 的newsgroup 也能帮助解决不少问题: http://www.borland.com/newsgroups 。
祝你好运
>1.Socket server 雖然不堪用, 但仍然有其優點, 其 port 固定(default 211) 在有防火牆的環境容易調整, 但 DCOM 竟然沒有固定的 port, 在有防火牆的環境裡死路一條. 這點不知該由 Microsoft 或 Borland 出面解決?
>
>2.DCOM server 雖然穩定, 但在 WIN95, 98, ME, WINNT 的 client 環境設定非常複雜且不可預期.
>
>3.CORBA 的優點講的令人佩服的五體投地, 但竟然無法穿越 internet, 至少這是 Borland 的說法, 若果真如此, 在 internet 的大環境中 CORBA 就出局了.
>
>4.ap server 每隔二星期就得重開一次, 否則容易 BDE error.
>
>5.ap service 只要 user 有 connection 就會吃一些 ram, 而且並不會因為這 connection 結束而釋放, 在 user 數多時這是很嚇人的.
>
>6.BDE 支援 Oracle 8.1.x 是有名的爛, 光是 SQLORA8.DLL 就有好幾個版本, 讓人無所適從, 測到現在為止, 沒有一個是穩定的, 若要回到用 ODBC 就實在太可惜了!
>
swang
幼幼班
1 Posts Posted - 12/17/2001 : 10:23:43
--------------------------------------------------------------------------------
我們也遇到過相同的問題
後來是把AP server的Dll安裝到com+(MTS)的環境中
再使用socket server情況就好轉啦也不用改架構(如果AP 是dll)
另外你可以試試用ODA連oracle問題就比較少速度也快很多
其實我對DELPHI是很有很有信心的
你所說貴公司的情形我想對任何工具來說都是不簡單的事
另外走DCOM時client端為啥會出現"interface not support'
好像是Client端的DCOMConnection沒關的原因為在create datamoudle時
如果DCOMConnection的active是true他會去連apserver這是發生在你給定APServer之前的
加油把呵呵呵
omite
幼幼班
1 Posts Posted - 12/17/2001 : 10:57:54
--------------------------------------------------------------------------------
>另外走DCOM時client端為啥會出現"interface not support'
>好像是Client端的DCOMConnection沒關的原因為在create datamoudle時
>如果DCOMConnection的active是true他會去連apserver這是發生在你給定APServer之前的
>加油把呵呵呵
swang兄好久不見^_^
之前使用DCOMConnection時,interface not support常因為權限設定問題
client跟ap登入同一個網域,或者幫client在ap上設定帳號可以改善,沒有深入了解原因
另外有關使用socket server的經驗,曾測試過一個問題,
用socketconnection連上ap,之後用clientdataset跟ap要資料
再把socketconnection關掉,這時常常會出錯,記得是出現socket error之類的,
而且AP上的socketserver程式就不見了,曾懷疑是因為socketserver做object pooling造成的, 不知道大家有沒有遇過這個問題?
Gordon Li
班長
Taiwan
383 Posts Posted - 12/18/2001 : 17:32:47
--------------------------------------------------------------------------------
看著James兄的文章之後, 心中的感覺是很複雜的, 又讓我想起了幾年前我做多層案子時的情景.
誰說多層系統不困難呢? 不過多層系統顯然是趨勢, 在資訊界不得不繼續走下去. Delphi的MIDAS+MTS/COM+是如此, CORBA, EJB, .NET也都是. 記得我在4, 5年前第1次開始開發多層系統時也是覺得很好玩, 但是在系統準備分發時, 我只記得我就開發冒冷汗了, 因為使用者的環境是如此的不可知, 當時我的情形比James也好不到那裡, 不是RPC Error, 就是AppServer死當, 客戶端發生Memory Error, 再不就是Interface not supported, Access Deny, Access violation等. 即使是程式可以執行, 不是慢如蝸牛, 就是極不穩定, 總之所有可能發生的悲慘事情我似乎都遇上了.
在那個時候我可是叫天不應, 呼地不靈, 沒有任何書籍可以參考, 沒有人可以詢問和求救, 只能怪自己為什麼要使用多層系統, 雖然我心中也知道使用C/S也一定失敗, 因為系統是在14.4K的WAN的環境中執行, 我試過用C/S架構來連RDBMS, 結果是等了20分鐘資料也沒有處理完成, 因此C/S注定不可行, 那麼除了多層架構還有什麼可行?
心中想著橫豎是殺頭一途, 不如就趁這個機會好好跟多層架構玩玩. 不料一深入研究才知道Delphi 3的MIDAS Server是COM物件, 因此得瞭解COM, 又必須瞭解COM的安全存取機制才能夠處理Access Deny/Access violation等問題. 當時很少有這些資料, 只能靠摸索MSDN, 到這裡我的Team一半以上的程式師就掛點了. 接著必須知道如何瞭解和設計中介物件, 才能夠承載比較多的使用者, 在那時才摸索出一些心得和Design Pattern, 最後是如何佈署分發系統, 一路走來真是備嘗艱辛, 更不用說Delphi和MIDAS以及COM的一些Bug. 不過這的確讓我學到許多的東西, 也能夠和大家分享, 但是當時我也很想認識現在的李維.
從經驗中學到的是, 要開發多層系統, Leader或是Architect一定要經過設計的階段, 至少對架構有一定的概念, 這可從現在EJB的身上看到相同的想法. 因此現在要我再寫多層系統, 那麼:
在Window上使用Delphi+COM+, Forget MTS和Pure Midas Server. MTS/MIDAS Server只適合Pilot或是Prototype System. 不要用Socket Connection, 它的Scability有問題, 除非你準備自己改Source, 不過可用來快速建制Pilot或是Prototype System. 如此一來當然就要使用DCOMConnection了, 那麼你要準備好和COM的安全機制搏鬥, 有Firewall的話就要搭配其他的方案.
CORBA很好, 但是我建議你使用C/C++來寫CORBA Server/CORBA Object, 再使用Delphi寫客戶端. CORBA+C/C++有很好的效率的延展性, 也可和Firewall整合. 但是CORBA+C/C++的複雜度可能是N的平方, 特別是C/C++的Memory Leak問題會把人搞瘋悼.
EJB也很好, 但這也是一個複雜的世界, 而且最好只使用Java, 同時注意EJB在理論上和實務上的差別, 要設計良好效率的EJB系統可不能太拘泥於EJB的Design Pattern, Architect一定要真正的瞭解每一個EJB真正的目的, 否則實作出來的EJB系統可能也是一隻漂亮的蝸牛.
希望James兄只是一時的疲倦, 可不要真的離開, 否則又少了一個有經驗的朋友.
李維
Edited by - Gordon Li on 12/18/2001 17:37:25
幼幼班
Canada
9 Posts Posted - 12/16/2001 : 12:51:41
--------------------------------------------------------------------------------
2001/07/02 星期一, 是個重要的日子, 這個營業額近一百億的公司, 共計海內外 5 個資料庫, 11 個營業據點, 12 條 internet 專線, 4700 名員工, 今天要轉換系統, 總公司的 database 要從 Oracle v7.33 換成 v8.17, 更要從 client/server 換成 3-tier, 經過長時間的測試再測試, 延後再延後, 今天將不再順延, 全公司就靠妳了, Delphi!
6/30 v7.33 資料庫停止服務, 與其他資料庫中斷 replication, 在資料 export 之後, 當日深夜開始 import 進 v8.17, 這個動作已經演練了好幾次, 一切順利.
7/1 星期日, 外頭是艷陽高照, 假日的辦公大樓, 機房則是幾十台機器發出如火爐般的高溫, 大家已經在這個小房間裡日以繼夜的熬了好幾個星期, 總算已經到了該攤牌的時候了, 3 台 ap server 就緒, web-server 啟動成功, 第一個帳戶登入, 第二個帳戶登入, 第三, 第四...整個過程順利的難以置信, 在向老闆報告了工作狀況後, 確定明天轉換系統!
7/2 星期一, 早晨 8:30 user 開始湧入辦公室, 新的 HomePage show 出以下公告:
1.舊系統所有功能自即日起由新系統替代.
2.在 30 天之內舊系統仍保留查詢功能.
3.海內外之資料同步預定 7 日內恢復.
4.請各位同仁注意所公佈之學習課程.
...
11:00am
[主機還好嗎?]
[沒什麼 loading, 所以還看不出來.]
[為什麼?]
[大部分都還不會操作, 在等訓練課程.]
11:30am
[教室裡有一台 pc 出現 RPC 伺服器的 error message.]
[然後呢?]
[還在解決中.]
11.35am
[不好, 大部分的 user 都出現同樣的訊息, RPC error.]
[程式重新啟動呢?]
[也不行, David 課也教不下去了.]
[server 狀況怎麼樣?]
[Oracle 正常, ap server 沒有 loading, 但也連不上]
[是哪台出問題?]
[好像全掛了.]
...
[通知 user 下課吃飯, 下午繼續!]
大家看了便當, 卻一點食慾都沒有. 離下午上班還有 90 分鐘可以想對策.
[ap 重開就正常, 會不會是剛才線路出問題?]
[可是除了 ap 其他 server 全正常.]
[ap 的網路卡出問題?]
[可是 3 台都掛了.]
[奇怪, 測了這麼久都沒碰到這個什麼 RPC error, 上線第一天就掛了...]
[會不會是這些正式的 server 與之前測試的環境不一樣?]
[唯一不同的就是從前只有一台 ap, 而現在則是 3 台.]
[會不會是 load balancing 出了問題?]
[... 可是, SimpleObject 只是分配一個 ap server 給 client, ap 當掉跟 SimpleObject 有關係嗎?]
[不管, 下午先將 2 台 ap 離線, 只用一台看會不會好一點.]
1:40pm
[各位同仁很抱歉, 因為上午主機出了些問題, 所以現在繼續 ...]
2:00pm
[又是 RPC error!] Jerry 驚叫.
[ap 又掛了.]
[重開!]
[...]
好不容易熬到下班, 也數不清當了幾次. 同樣是這些人, 同樣是愁眉苦臉對著便當吃不下. 中央空調過了七點就沒了, 而夜卻長的很.
[ok, 看來唯一與測試環境不同的就是 loading, concurrent user 多了, ap 就掛了.]
[今天有多少 user?]
[教室裡 20 個, 外頭也有一些, 但教室這些是跟著老師的課程走, 所以會同時做相同的動作, 所以 ap 受不了.]
[才 20 個就受不了? 那這什麼爛貨, 還有誰敢用.]
這些人已經幾星期沒睡好覺, David, Jerry 更是好久沒回家了, 心中的怒火似乎就像外頭的氣溫.
[ap service 是用 Single 或 Multiple?]
[有沒有可能是 Oracle 817 的問題?]
[有沒有可能是 Socket Server 出問題?]
[有沒有可能是 ap 與 Oracle 中間的傳輸有問題?]
...
疑點愈來愈多, 但要從何下手? 而且做任何的改變都等於是拿真實環境做實驗, 一點退路都沒有, 頭上幾天 user 還能忍受, 只要再過幾天, 肯定就有人告到老闆那兒去, 那就 ...
[吃飯, 等一下把所有的 ap service 都改成 Single, 而且都裝到 817 同一台, 明天再跑跑看.]
這個改變可以知道 Single 與 Multiple 有沒有差別, 而且可以把 Oracle 與 ap 中間傳輸的問題給先排除, 讓問題比較好抓. 唉! 所有的狀況都事先做過測試, 就缺找 20 個人同時 run 一個 program...
7/3 星期二, 大家拖著疲憊的身子, 再度面臨沉重的一天.
[可以上課了嗎?]
[嗯! 開始]
所有人注意的焦點都在 20 個 user 的螢幕.
[RPC, RPC, 不要出來 RPC...]彷彿在唸著咒語.
時間一分一秒的過去.
[有 RPC 嗎?]
[沒有, 可是有 user 的 program run 一半當掉, 死當, 要強迫中斷才能結束.]
[多不多?]
[有幾個!]
[RPC 呢?]
[沒有.]
沒有 RPC error 了, 大家彷彿不信似的. 那到底是因為 Multiple 的問題, 還是 Oracle 與 ap 傳輸的問題造成 RPC?
再改, 下午再把 ap server 回復到 3 台.
中午休息時間似乎對所有的人都是個短暫的解脫, user 可以逃離這個讓人瘋狂的新系統, 而我們也可以關起門來想對策.
[早上 RPC 是沒有了, 可是因為只有一台 ap 而且 Service 都是 Single, 所以排隊的情形很嚴重, 往往一個 user 作個查詢要等前面 10 個人 run 出結果, 他才會有回應.]
[這可以先不管, 要確定 RPC 的問題已經解決, 否則這個系統根本 run 不下去.]
下午同樣沒有出現 RPC error, 看來很明顯是因為 Multiple 所造成, 雖然因為加到 3 台 ap server 排隊的現象緩和了些, 但 user 偶而會當掉 program 還是很令人心煩, 不過總比 RPC 要好多了.
[RPC error 是沒了, 可是 user 在抱怨做一個動作要等好久, 也不知道是當了還是在等待.]
[等了多久?]
[有 user 等了一二個小時.]
[天啊! 這麼笨, 當然是當了.]
[可是 user 分不出來要他等多久才算當掉, 而且往往打一張訂單, 在儲存時就沒回應, 你要他放棄將程式中斷, 他會殺了你.]
[...]
又是悶熱的夜晚, 還是這些人, 新系統上線第二天, user 加班變得更晚.
[耶! 存成功了!] 一個 user 冒出了一聲歡呼, 但我們這些人相對不語, 這一點都不好笑, 一筆資料能順利存成功, 變成了上天的恩賜.
這麼龐大的公司, 每天這麼多的交易, 現在竟然建築在一個這麼不穩的系統上, 而我們就是這些罪魁禍首.
user 也知道要避開白天跟許多人搶 server 的 space, 所以就在晚上補打單子, 但等發現到也有許多人有共同想法的時候, 也只能互相苦笑捉弄一番.
而我們這些精疲力盡頭腦已經不太清楚的人, 還要等到 user 走光才能開始下一步的實驗.
[ok, 誰能對 program 會死當提出看法?]
[...]
[其實真正死當的並不是這麼多, 因為有些 user 可能在還沒回應前就認為當了而中斷.]
[而且仔細分析並不是每支程式都會當, 而是集中在訂單系統.]
[訂單? 訂單有什麼特別?]
[...]
[訂單 master/detail 關聯比較複雜, 一共有 3 層 8 個 table.]
[...]
[ok, 看樣子要修改程式了.]
等待是令人期待的, 而結果卻是令人失望的, 要對一個正式的環境做實驗或調整, 是一件讓人手心冒汗的事, 但整件事情的發展已經失去了回頭的機會, 一次一次的失望都是用無數實驗與時間換來的, 我們已經無法宣告失敗, 要公司的資料庫迴轉到 6/30 的 Oracle 733, 沒有人承受的起這個損失, Oracle 也沒有 support 資料庫的 do
wngrade.
7/4 總公司對其他資料庫的 replication 啟動成功, 雖然新系統仍然有 program 死當的問題, 但企業的運轉還是不能停的.
7/11 JDN 的 user 連線成功.
7/12 HK 與 MEX 的 user 連線成功.
7/13 SPN 的 user 連線成功.
7/30 新的 HomePage show 出以下公告:
1.舊系統之查詢功能自即日起停止服務.
2.駐外單位已全數連線, 請總公司同仁不要再提供 fax, mail
...
從此總公司 client/server program 與 ASP CGI 網站全數停機, 不分遠近, 所有的 user 都是使用相同的 program 操作, 你可以從 TPE 輸入訂單, 而 MEX 的 user 可以同時在地球的另一邊將訂單開啟, 3 層 master/detail 共計 8 個 table, 這在過去是不可能實現的, 照理我們現在應該是歡欣鼓舞開香檳的時候, 但 program 會不定時的當機, 像個陰影尾隨不掉.
[BDE, Oracle 都做了 tunning, performance 有變好, 可是還是照當, 已經很多人告到老闆那邊去了.]
[想想一個 user 一天不要多, 只要當二次, 統統加起來就是幾百次, 老闆沒拿刀殺人就很仁慈了.]
[其實現在很明顯是 Socket server 出問題, 這玩意很不可靠, 但奇怪的是在 Socket server 掛掉的同時, DCOM 還是可以連的上, 要不要改成用 DCOMConnection 試試看?]
[也好, 死馬當活馬醫.]
8 月中的某一天, 天一樣的熱, 所有的程式都換成了 DCOMConnection.
[user 出現 "interface not support" 的訊息.]
[修改 DCOMCNFG.]
[ok]
替 user 解決 "interface not support" 的訊息不是難事, 重點是我們的運氣似乎開始好轉.
無疑 DCOM 要比 Socket 穩定許多, 一夜之間 program 變得不會當機了, 但要解決所有 user "interface not support" 的訊息並沒想像中簡單, 尤其是遠端的 WIN95, 98 ME 或 WINNT. 但重要的是可以報告老闆, 我們不會當機了!
解決這個問題不是靠 Borland 的文件, 也不是靠 patch, 而是靠運氣, Borland 並未告訴妳說 Socket 是有問題, 或是如何去避免, 雖然現在是解決了眼前的問題, 但還有多少問題是如冰山般未浮現?
以我們這個案例而言, 不靠決策高層堅定的支持, 早就宣告失敗砍人, 有幾個老闆敢拿公司開玩笑, 做無限制的實驗與等待, 故事的過程中除了對細節有所保留, 但所有的人物與時空背景都屬真實, 一方面為這場戰役留下紀錄, 也希望給所有投入在 Delphi 的工作者, 事業經營者做一個參考, 但我必須說既然在官方文件找不到的解答, 就不代表長久有效, 我們現在的環境是 Windows 2000 + Oracle 817 + Delphi 5.01 + DCOMConnection, 其中有任何一個改變了, 就可能得從頭開始再玩一遍.
這場仗打完了嗎? 才開始呢! 如果老闆不把我 fire 掉, 最起碼現在還有許多問題要克服:
1.Socket server 雖然不堪用, 但仍然有其優點, 其 port 固定(default 211) 在有防火牆的環境容易調整, 但 DCOM 竟然沒有固定的 port, 在有防火牆的環境裡死路一條. 這點不知該由 Microsoft 或 Borland 出面解決?
2.DCOM server 雖然穩定, 但在 WIN95, 98, ME, WINNT 的 client 環境設定非常複雜且不可預期.
3.CORBA 的優點講的令人佩服的五體投地, 但竟然無法穿越 internet, 至少這是 Borland 的說法, 若果真如此, 在 internet 的大環境中 CORBA 就出局了.
4.ap server 每隔二星期就得重開一次, 否則容易 BDE error.
5.ap service 只要 user 有 connection 就會吃一些 ram, 而且並不會因為這 connection 結束而釋放, 在 user 數多時這是很嚇人的.
6.BDE 支援 Oracle 8.1.x 是有名的爛, 光是 SQLORA8.DLL 就有好幾個版本, 讓人無所適從, 測到現在為止, 沒有一個是穩定的, 若要回到用 ODBC 就實在太可惜了!
簡單的講, 在有防火牆的 internet 環境裡目前 Delphi 似乎提不出解決的方法, 相信很多人會建議採用 web solution, snap, soap, web service...但我這裡講的是 ap, 若說要靠 web 做一套複雜的 MRP or ERP? 唉! 那只能祝你好運了!
放棄 Delphi? 坦白說不是沒有這個念頭, 但你會建議用什麼來替代? IBM 會說用 Websphere, Oracle 會說用 application server 9i, 每個公司都可以派一個 team 的 sales 來拜訪你, 但沒有一家會準備一個李維來解決你的問題, 若說要離開熟悉的 Delphi 投入另一批 sales 的甜言蜜語, 看來只是找機會讓老闆炒你魷魚.
終於還是鼓起勇氣將手上的 Delphi 6, Oracle 9i Database, Oracle Application Server 9i 分別裝進 3 台 server, 這一次要測的項目可多了:
1.Oracle 817 資料可否 export 到 9i?
2.Delphi 6 的 CORBA 與 Oracle 所附的 Visibroker 可否並存?
3.CORBA client 可否穿透 internet 連結 CORBA server.
4.CORBA 的 load balancing.
5.CORBA 的承受能力?
6.Delphi 6 的 Socket 可有改善?
只是為了實驗 817 database export 到 9i, 就將 Oracle 9i 重裝了好多次, 因為根本無法成功, 這點 Oracle 也提不出解決方法.
為了要將 Oracle Application Server 9i 連結到資料庫, 也重灌了 n 次才確定, 9i Application Server 竟然不能連結 9i Database, 只能連 8.1.x, 這可真夠邪門的了.
所謂重灌是指連 Windows server 都重新安裝, 你能想像花了多少冤枉時間去 try 一些令人無法置信的結果, 真正好戲是等到測 Delphi 6 的 CORBA 才開始登場.
當 Oracle 9i database, 9i Application Server 與 Delphi 6 都裝完以後, 你會發現竟然並存了好幾個 Visibroker 的版本, 光 Delphi 6 就可以讓你選擇 4.x 與 3.x 二種, 開玩笑, 當然是裝新版 4.x, 哪有裝舊的.
結果 Delphi 6 的資料庫元件竟然無法連結 CORBA 4.x, 唉! 只好又移除 Delphi 6, 再重裝一次, 這次就安裝了 CORBA 3.x, 果然, 可以順利做些實驗, client 可以連上 CORBA server, 而且 load balancing 也生效, 如同李維書上所說, 使用 CORBA connection 可以不用仰賴 SimpleObject 做 load balancing, 程式簡單多了, 但仍然無法穿透 internet.
再來的實驗呢? 做不下去了, 無數次的安裝移除, Delphi 6 不再讓我註冊了, Borland 美國的註冊 server 從此不再接受我的註冊, 縱然你手上握的是原版光碟, 但一下子卻成了非法的使用者, 我睜大了眼睛實在不敢相信, 這...Borland 實在讓我灰心透了, 不談這個小動作合不合理, 我實在對這一行突生厭惡, 我相信所有投入這個工作的人起始的出發點都是可敬可佩的, 我沒有遇到一個 programmer 是為了賺好多錢, 會在年輕時就開始了日以繼夜的工作, 他們所擁有的只是一個夢想, 雖不能當大老闆統領千軍萬馬, 但也能藉著完成一個電腦系統而實現管理化的那份成就感, 其中有多少人因為開發工具的先天不良而宣告失敗, 輕則離職, 重則賠錢挨告, 而所有開發工具的廠商能提出解決的方案卻是少之又少, 若你用 VB or Delphi 接一個 project, 最後可能因為失敗而被告, 但卻從來就沒有一個開發工具廠商因為這種事而被告, 他們每年不斷的要你花錢買一個修補漏洞的新版, 另外再送一些不穩定的新功能讓你測試, 現在, 乾脆直接說:
[嘿! 這個功能你只能測 10 次, 之後就 game over, 你必須重買一套.]
乖乖! 一套 Delphi 6 client/server 你知道要多少錢? 這個解決的方法歷經二個月 Borland 還是沒給我答覆, 也好, 不作實驗時間倒多出來了, 除了賞楓賞雪還可以寫寫文章投稿, 只是若不能再成為 Delphi 的 "合法" user, 這大概也是我在李維論壇的最後一篇, 從此不再玩 Delphi 了!
--
james
Sylix
幼幼班
11 Posts Posted - 12/16/2001 : 15:23:30
--------------------------------------------------------------------------------
有同感
dearkang
幼幼班
17 Posts Posted - 12/17/2001 : 00:11:39
--------------------------------------------------------------------------------
我在想這樣跨地理區域的系統是不是該用web當作interface比較適當呢？
在系統架構上大家是不是能提供一些意見？
guard
小班
78 Posts Posted - 12/17/2001 : 00:25:53
--------------------------------------------------------------------------------
但是用web來做AP我想以目前而言，真的是非常困難，在web環境，開發工具，使用者介面
都充滿著挑戰性。如果JChang先生出來寫作，相信也是一位好作家，因為其引人入勝的陳
述，可以為死板的電腦技術帶來更多的生趣。
dearkang
幼幼班
17 Posts Posted - 12/17/2001 : 00:35:38
--------------------------------------------------------------------------------
我想是否再確認李兄在其書中所提的：
給client的資料能做的少量、多次(fetch on demand)
減少client與remote server的呼叫往返(server把邏輯處理完後才把結果回傳client)
dearkang
幼幼班
17 Posts Posted - 12/17/2001 : 00:58:06
--------------------------------------------------------------------------------
※ 引述《guard》於 12/17/2001 00:25:53 發表之銘言：
>但是用web來做AP我想以目前而言，真的是非常困難，在web環境，開發工具，使用者介面
>都充滿著挑戰性。如果JChang先生出來寫作，相信也是一位好作家，因為其引人入勝的陳
>述，可以為死板的電腦技術帶來更多的生趣。
有沒有人試過用visual studio do
tnet來寫web form呢？
我覺得如果有delphi的基礎，vb.net或是c#都是非常容易上手的。
順便一提，我覺得vb.net的語言已經改到沒什麼重大缺點了，甚至就programming language
而言，可能已經超過object pascal。因此在公司裡，我很想把vb的程式員讓他們能成為vb.net的程式員（我不期望他們能接受C#或Java），進而能順便學習使用delphi，因為如果能搭配delphi及vb.net(或c#)一同使用(以COM當作interface)，對程式員來說，不儘在職業生涯或是工作上都是利多於弊的。
drowsy
幼幼班
China
37 Posts Posted - 12/17/2001 : 09:53:36
--------------------------------------------------------------------------------
建议不要使用BDE,而使用ADO Microsoft driver for oracle 很稳定，效率也很好；dbExpress 则提供了更好的效率，稳定性不敢说。
关于DCom Server 的设定，我想可以借助安装程序来完成，应该不是什么问题。
我喜欢borland 的delphi，目前使用delphi6， 做3曾开发和web开发，很好用，borland 的newsgroup 也能帮助解决不少问题: http://www.borland.com/newsgroups 。
祝你好运
>1.Socket server 雖然不堪用, 但仍然有其優點, 其 port 固定(default 211) 在有防火牆的環境容易調整, 但 DCOM 竟然沒有固定的 port, 在有防火牆的環境裡死路一條. 這點不知該由 Microsoft 或 Borland 出面解決?
>
>2.DCOM server 雖然穩定, 但在 WIN95, 98, ME, WINNT 的 client 環境設定非常複雜且不可預期.
>
>3.CORBA 的優點講的令人佩服的五體投地, 但竟然無法穿越 internet, 至少這是 Borland 的說法, 若果真如此, 在 internet 的大環境中 CORBA 就出局了.
>
>4.ap server 每隔二星期就得重開一次, 否則容易 BDE error.
>
>5.ap service 只要 user 有 connection 就會吃一些 ram, 而且並不會因為這 connection 結束而釋放, 在 user 數多時這是很嚇人的.
>
>6.BDE 支援 Oracle 8.1.x 是有名的爛, 光是 SQLORA8.DLL 就有好幾個版本, 讓人無所適從, 測到現在為止, 沒有一個是穩定的, 若要回到用 ODBC 就實在太可惜了!
>
swang
幼幼班
1 Posts Posted - 12/17/2001 : 10:23:43
--------------------------------------------------------------------------------
我們也遇到過相同的問題
後來是把AP server的Dll安裝到com+(MTS)的環境中
再使用socket server情況就好轉啦也不用改架構(如果AP 是dll)
另外你可以試試用ODA連oracle問題就比較少速度也快很多
其實我對DELPHI是很有很有信心的
你所說貴公司的情形我想對任何工具來說都是不簡單的事
另外走DCOM時client端為啥會出現"interface not support'
好像是Client端的DCOMConnection沒關的原因為在create datamoudle時
如果DCOMConnection的active是true他會去連apserver這是發生在你給定APServer之前的
加油把呵呵呵
omite
幼幼班
1 Posts Posted - 12/17/2001 : 10:57:54
--------------------------------------------------------------------------------
>另外走DCOM時client端為啥會出現"interface not support'
>好像是Client端的DCOMConnection沒關的原因為在create datamoudle時
>如果DCOMConnection的active是true他會去連apserver這是發生在你給定APServer之前的
>加油把呵呵呵
swang兄好久不見^_^
之前使用DCOMConnection時,interface not support常因為權限設定問題
client跟ap登入同一個網域,或者幫client在ap上設定帳號可以改善,沒有深入了解原因
另外有關使用socket server的經驗,曾測試過一個問題,
用socketconnection連上ap,之後用clientdataset跟ap要資料
再把socketconnection關掉,這時常常會出錯,記得是出現socket error之類的,
而且AP上的socketserver程式就不見了,曾懷疑是因為socketserver做object pooling造成的, 不知道大家有沒有遇過這個問題?
Gordon Li
班長
Taiwan
383 Posts Posted - 12/18/2001 : 17:32:47
--------------------------------------------------------------------------------
看著James兄的文章之後, 心中的感覺是很複雜的, 又讓我想起了幾年前我做多層案子時的情景.
誰說多層系統不困難呢? 不過多層系統顯然是趨勢, 在資訊界不得不繼續走下去. Delphi的MIDAS+MTS/COM+是如此, CORBA, EJB, .NET也都是. 記得我在4, 5年前第1次開始開發多層系統時也是覺得很好玩, 但是在系統準備分發時, 我只記得我就開發冒冷汗了, 因為使用者的環境是如此的不可知, 當時我的情形比James也好不到那裡, 不是RPC Error, 就是AppServer死當, 客戶端發生Memory Error, 再不就是Interface not supported, Access Deny, Access violation等. 即使是程式可以執行, 不是慢如蝸牛, 就是極不穩定, 總之所有可能發生的悲慘事情我似乎都遇上了.
在那個時候我可是叫天不應, 呼地不靈, 沒有任何書籍可以參考, 沒有人可以詢問和求救, 只能怪自己為什麼要使用多層系統, 雖然我心中也知道使用C/S也一定失敗, 因為系統是在14.4K的WAN的環境中執行, 我試過用C/S架構來連RDBMS, 結果是等了20分鐘資料也沒有處理完成, 因此C/S注定不可行, 那麼除了多層架構還有什麼可行?
心中想著橫豎是殺頭一途, 不如就趁這個機會好好跟多層架構玩玩. 不料一深入研究才知道Delphi 3的MIDAS Server是COM物件, 因此得瞭解COM, 又必須瞭解COM的安全存取機制才能夠處理Access Deny/Access violation等問題. 當時很少有這些資料, 只能靠摸索MSDN, 到這裡我的Team一半以上的程式師就掛點了. 接著必須知道如何瞭解和設計中介物件, 才能夠承載比較多的使用者, 在那時才摸索出一些心得和Design Pattern, 最後是如何佈署分發系統, 一路走來真是備嘗艱辛, 更不用說Delphi和MIDAS以及COM的一些Bug. 不過這的確讓我學到許多的東西, 也能夠和大家分享, 但是當時我也很想認識現在的李維.
從經驗中學到的是, 要開發多層系統, Leader或是Architect一定要經過設計的階段, 至少對架構有一定的概念, 這可從現在EJB的身上看到相同的想法. 因此現在要我再寫多層系統, 那麼:
在Window上使用Delphi+COM+, Forget MTS和Pure Midas Server. MTS/MIDAS Server只適合Pilot或是Prototype System. 不要用Socket Connection, 它的Scability有問題, 除非你準備自己改Source, 不過可用來快速建制Pilot或是Prototype System. 如此一來當然就要使用DCOMConnection了, 那麼你要準備好和COM的安全機制搏鬥, 有Firewall的話就要搭配其他的方案.
CORBA很好, 但是我建議你使用C/C++來寫CORBA Server/CORBA Object, 再使用Delphi寫客戶端. CORBA+C/C++有很好的效率的延展性, 也可和Firewall整合. 但是CORBA+C/C++的複雜度可能是N的平方, 特別是C/C++的Memory Leak問題會把人搞瘋悼.
EJB也很好, 但這也是一個複雜的世界, 而且最好只使用Java, 同時注意EJB在理論上和實務上的差別, 要設計良好效率的EJB系統可不能太拘泥於EJB的Design Pattern, Architect一定要真正的瞭解每一個EJB真正的目的, 否則實作出來的EJB系統可能也是一隻漂亮的蝸牛.
希望James兄只是一時的疲倦, 可不要真的離開, 否則又少了一個有經驗的朋友.
李維
Edited by - Gordon Li on 12/18/2001 17:37:25