Things to Consider When Building Large Business Systems

最近小弟我在看Marstering in EJB2
(可在TheServerSide.com上Free DL ^_^)
在第一章Page38-39中列出了的一項大型商業系統需求清單

在要開始往下了解為啥米要使用EJB前，
先了解大型商業系統所需達成的目標。
所以我想這份清單蠻重要的。
小弟現將其翻譯出來與大家分享

原書中這份列表只是將這些項目列出來並稍作說明。
小弟將我所能理解的意思照翻。
希望大家發覺有錯誤之處能加以指正。
或是覺得原書中過於簡略說明的部份，想加以補充也歡迎修正。

希望這樣的補充能對大家思考如何建置一個完備的系統有所幫助。

Things to Consider When Building Large Business Systems

建置大型商業系統時需列入考慮幾項部份

Remote method invocations.

我們需要將server-client之間透過網路連結的關係邏輯化
這包含了分派服務需求、管理參數及其他更多的細節。

Load Balancing.

Clients應該是以最輕負載來對Server發出請求服務。
如果某一台server發生超載，
那麼應選擇由另一台server來執行此項服務。

Transparent fail-over

一旦某一台server掛點或是網路掛了。
可以在無中斷服務的情況下快速導向至另一台server嗎?
如果可以，那麼有多快可達成錯誤回復?是幾分?還是幾秒?
這是指你的商業服務所能忍受中斷的回復時間。

Back-end integration.

商用資料在寫回資料庫時需考慮與原先舊有系統的資料間有良好的整合。

Transactions.

當有二位客戶同時存取資料庫中的同一欄位時。是否會使資料庫資料損毀。
交易的確認及保護是此項議題的重點。

Clustering.

如果server所保存的狀態毀壞了，這個狀態的值是否已備份至其它server上了?
而clients是否可以繼續使用不同的server所提供的服務。

Dynamic redeployment.

當系統正在持續運作時，我們該如何對它來作更新的動作哩?
你需要暫時的關機停止服務或是能夠持續地執行服務呢?

Clean shutdown.

如果你需要將server關機時，你能很順利的管理資源的回收或資料的保護，
而又不中斷目前正在服務的項目嗎?

Logging and auditing.

當系統出現錯誤時，我們能擁有完整的log來解決或發現問題原因嗎?
完整的log可幫助我們發掘問題的關鍵點並使它不再發生。

Systems Managemetn.

當災難性的錯誤發生時，誰來監控我們的系統?
我們需要一項軟體來自動監控，
以便當災難發生時自動去呼叫管理者來處理。

Threading.

假設現在我們有許多的clients要與server作連結，
而server必須有能力去處理這些client同時發出的服務需求。
這表示server必須是具有多執行緒的能力。

Message-oriented middleware

clients-server間是以明確的訊息型態為基礎來構成此鬆散的架構。
我們需要一些基礎架構來包含處理這些訊息。

Object life cycle.

存在於server上物件的產生及消滅，由client的需求而定。

Resource pooling.

如果某一client不再使用先前所取得的server端資源，
那麼server端的資源將被集中在一處(Resource pool)
等待其它clients連結後再利用。
這包含了像是sockets(例如與資料庫的連線)也如同一些存在於server端的物件。

Security.

系統及資料庫皆須要保護以免受到外來的惡意破壞。
執行使用者命令前，
應確認使用者所執行的是經由允許且他們有權執行的操作指令。

Caching.

讓我們來假設一種情況，
這兒有些資料庫的資料是要讓所有clients所共享及使用。
比方如：一般的產品型錄。
那麼為何我們要讓server一次又一次不斷的去和資料庫取得這些相同的資料。
我們可以讓這些資料保存在server的記憶體中
去避免往返於資料庫之間的存取動作。

當然還有更多更多建置大型商業系統時需列入考慮部份

上述的每一項議題都是一項可分離的服務，
皆須要認真的思考如何處理這些伺服端的運算。
而這些服務是在任何商業問題及各種獨立的企業都所需要的。
現在這些服務被稱之為中介軟體(middleware)