Message Oranted System
延續很多相關軟體建置的經驗，許多系統都會遇到，流程，主從，處理速度等等不同的問題。
而問題的根源，是因為系統直接就面對了資料庫，所以牽一髮而動全身，而這大型一點的系統，要改，大家都會怕，為何？因為，大。誰知道改了A、B還能不能用。雖然會有很多人狂喊很多開發方法論，測試方法論。問題是，誰能確保團隊裡的{每一個}人都認真且嚴謹的遵守著方法做事？扯遠了！
回題，所以軟體系統的演進，有了n-Tier的商業系統架構，想在前端跟後台中間多隔離幾層，把商業邏輯掛在中間，有任何萬一需要修改的，改一個就全改了。這就是他的理想國。但是，技術性跟系統整合的難度，讓這類系統很少在市面上出現。
走向了網路，更慘，一串的web server對應另一串的ap server再去面對後台(這還算是理想一點的，有很多網站是一串web server就直接面對後台了)，客戶端的運算力？系統要安裝，難管啦，通通網頁化！不直？這是使用者要訓練，不是系統的問題，更不是WEB的先天限制。又扯遠了！
商業軟體最容易遇到的就是，流程。而通常的做法就是每套系統有自己的流程控制系統，所以，要改？一套一套來。要互連？當然是Web Service啊。那Web Service接口掛點怎麼辦？流量太大，系統運算力不足以處理怎麼辦？加機器，加機器。可是系統原來的設計有包含到平行擴增的功能嗎？沒有的話，就變換器換大，換非常大，換到沒機器為止。反正系統不會用這麼久，而且硬體這麼便宜！
無解嗎？當然有解，就像大家喊SOA或SaaS都會有一個集中式的平台，那企業內系統不能嗎？當然可以。一定要是Web Service嗎？那是賣ESB平台的人唬的，Web Service可以直接匯入系統當API，那其他的Binary Protocol不行？XML才應該統治世界？反正頻寬越來越便宜，用plain text不算浪費？ 當然是浪費啊！不然為何要gzip壓縮？
企業內平台可以換另一個角度來處理，就是Message Queuing。把中介都經由MQ來轉接、轉發。這樣系統容量不足？多加幾個處理的channel listener，愛擺在一台或多台，都隨你。消息量大到MQ無法處理？市面上的Queuing System都具有平行擴展功能，我有見過TPS 3000的單一系統，也就是說每天可以處理295.2B筆的transaction(request)。一般PC(p4-2.8G)的TPS要超過150也很容易。
這樣的系統設，前台都要面同樣的Queue就好了，容量可以平行擴增，要增修功能，也會因為這樣先天的系統分離，而減少一些複雜度。如果能在設計時強制性的作{無狀態}的要求，那系統會更容易做高度的分離，對於寫系統的人來說，會困難一些，但是對於用系統跟維護系統的人來說，使用的便性了，系統也更好維護。
尤其是高度依賴流程的軟體，這樣等於是把前後台強制切割，可以連廠商都任意更換。這也算是一種SaaS吧。