仍然有一些人(不論是內部或外包廠商) 根本沒有用腦子好好想過 , 所以就會有雖然是使用 Web 應用系統但是仍舊套用 Desktop 應用程式的方式去設計與實做
這樣會有什麼問題?
舉例來說 , 有些企業可能會有需要人工按下一個按鈕 , 然後那個工作可能是轉檔程式或者是其他需要較久處理時間的作業 , 以往如果是使用 VB6開發程式 , 反正頂多出現 一個沙漏 , 或者是進度bar 顯示目前正在處理中 , 然後作業完成 , 跳出一個對話窗表示處理完畢 , 有可能是 1 小時 或者是更久 , 反正就是放著讓它跑
這樣的模式套用到 Web系統會有什麼問題 ???
Web 的Timeout 會是第一個問題
一般網頁的處理的Timeout 設定都不會設的很長 , 所以碰到這種長時間作業的 , 就會發生 , 作業到一半就會 timeout 的問題 , 就會有廠商可能直接將 timeout 時間設定更長 , 這樣也只是頭痛醫頭 , 一點意義都沒有 , 想想看 , 如果有一個作業需要 5 個小時 , Web 的timeout 時間你想要設的多長 ?
建議的設計方式:
這種長時間作業的 , 應該是要設定成 非同步的處理模式 , User 透過網頁按下 開始處理 , 系統收到 Request 後 , 應該是設定成 Server端的排程作業 去處理 , 然後 網頁立刻回覆 , 已設入排程 , 結束...
User 應該是在事後 , 的某個時間點再去檢視 Server端排程作業狀態頁面 , 看看 先前的作業的作業狀態是 已完成 , 或是仍在進行中 , 或是已結束但是有錯誤發生 , 另外如 何時開始作業 , 何時完成作業 也應該是在該頁面中檢視
為何不是像建議的設計方式這樣做?
因為廠商可能沒腦子 , 或者是為了省事(省人力 , 省錢) ,
用原來的Client , Server 的寫法 , 只需要寫一個 處理頁面就完成了(雖然它會有我上面所說的重大問題) ,
如果換成我上面所說的建議設計方式 , 則需要寫的頁面會變多 , 但是不會有上述所說的重大問題 , 但是需要較多的人力跟開發成本
另外 DB 的 Timeout 會是第二個問題
在現在使用 J2EE Server 的企業有不少 , 也都會去設定 DataSource ,
但是 仍然可以發現到 很多企業的系統 , 對於相同的資料庫並沒有切出多組的 DataSource來作區隔設定
這樣的問題是什麼?
例如你是線上同步作業的 DataSource 與 大量批次轉檔非同步作業的DataSource 是否是使用相同的DataSource 或者是不同的DataSource ??? ,
兩者的Timeout 設定可能就需要不一樣的設定 , 大量轉檔作業可能需要耗時 5 個小時 , 那去使用一般的DataSource 時 , 可能程式跑到一半就會 Timeout 掉 , 你要去修改 一般的 DataSource 的 timeout 時間為 5 個小時嗎 ? 那麼其他線上作業的程式(Web)使用這個DataSource 時 , 它可能會變成 Web Page 的回應時間可能會拉長 , 使用者等待的時間會拖的更長....
建議的解決設計:
將 批次大量作業使用的 DataSource 與 線上作業使用的 DataSource 分開設定
在企業內部設計應用系統 , 不是讓系統執行工作後就沒事了 ,
你還必須考慮 , 該工作何時執行 , 何時結束 , 結束狀態是成功 , 或失敗 , 失敗的原因是什麼 ,
發生錯誤了 , 系統要能自動化的發出通知 , 通知維護人員進行檢視與處理
系統如何做失敗的錯誤回復 , 把原先的工作繼續成功的處理完畢 , 這些都是必須考慮的
如果沒有好好考慮就會發生 , 錯誤發生了 , 沒人知道 , 或者是無法做後續的錯誤回復處理
這樣會有什麼問題?
舉例來說 , 有些企業可能會有需要人工按下一個按鈕 , 然後那個工作可能是轉檔程式或者是其他需要較久處理時間的作業 , 以往如果是使用 VB6開發程式 , 反正頂多出現 一個沙漏 , 或者是進度bar 顯示目前正在處理中 , 然後作業完成 , 跳出一個對話窗表示處理完畢 , 有可能是 1 小時 或者是更久 , 反正就是放著讓它跑
這樣的模式套用到 Web系統會有什麼問題 ???
Web 的Timeout 會是第一個問題
一般網頁的處理的Timeout 設定都不會設的很長 , 所以碰到這種長時間作業的 , 就會發生 , 作業到一半就會 timeout 的問題 , 就會有廠商可能直接將 timeout 時間設定更長 , 這樣也只是頭痛醫頭 , 一點意義都沒有 , 想想看 , 如果有一個作業需要 5 個小時 , Web 的timeout 時間你想要設的多長 ?
建議的設計方式:
這種長時間作業的 , 應該是要設定成 非同步的處理模式 , User 透過網頁按下 開始處理 , 系統收到 Request 後 , 應該是設定成 Server端的排程作業 去處理 , 然後 網頁立刻回覆 , 已設入排程 , 結束...
User 應該是在事後 , 的某個時間點再去檢視 Server端排程作業狀態頁面 , 看看 先前的作業的作業狀態是 已完成 , 或是仍在進行中 , 或是已結束但是有錯誤發生 , 另外如 何時開始作業 , 何時完成作業 也應該是在該頁面中檢視
為何不是像建議的設計方式這樣做?
因為廠商可能沒腦子 , 或者是為了省事(省人力 , 省錢) ,
用原來的Client , Server 的寫法 , 只需要寫一個 處理頁面就完成了(雖然它會有我上面所說的重大問題) ,
如果換成我上面所說的建議設計方式 , 則需要寫的頁面會變多 , 但是不會有上述所說的重大問題 , 但是需要較多的人力跟開發成本
另外 DB 的 Timeout 會是第二個問題
在現在使用 J2EE Server 的企業有不少 , 也都會去設定 DataSource ,
但是 仍然可以發現到 很多企業的系統 , 對於相同的資料庫並沒有切出多組的 DataSource來作區隔設定
這樣的問題是什麼?
例如你是線上同步作業的 DataSource 與 大量批次轉檔非同步作業的DataSource 是否是使用相同的DataSource 或者是不同的DataSource ??? ,
兩者的Timeout 設定可能就需要不一樣的設定 , 大量轉檔作業可能需要耗時 5 個小時 , 那去使用一般的DataSource 時 , 可能程式跑到一半就會 Timeout 掉 , 你要去修改 一般的 DataSource 的 timeout 時間為 5 個小時嗎 ? 那麼其他線上作業的程式(Web)使用這個DataSource 時 , 它可能會變成 Web Page 的回應時間可能會拉長 , 使用者等待的時間會拖的更長....
建議的解決設計:
將 批次大量作業使用的 DataSource 與 線上作業使用的 DataSource 分開設定
在企業內部設計應用系統 , 不是讓系統執行工作後就沒事了 ,
你還必須考慮 , 該工作何時執行 , 何時結束 , 結束狀態是成功 , 或失敗 , 失敗的原因是什麼 ,
發生錯誤了 , 系統要能自動化的發出通知 , 通知維護人員進行檢視與處理
系統如何做失敗的錯誤回復 , 把原先的工作繼續成功的處理完畢 , 這些都是必須考慮的
如果沒有好好考慮就會發生 , 錯誤發生了 , 沒人知道 , 或者是無法做後續的錯誤回復處理
