nio 和 soa 都有使用，最近重新看一些文章，結合自己的專案應驗，發覺nio的思想對soa也很有參考價值。
nio 關鍵是採用了被動的 observable 模式，或者說 listener 模式實現了 io 的非阻塞通訊，從而極大提高io效能。 我所體會的，其中的妙處在於 requestor 變主動模式為被動模式，避免乙個請求長時間獨佔資源，從而提高 io 的效率。
這讓我想到在專案中，業務方法(business method)通常納入乙個transaction事務中，而事務的過程通常比較消耗時間，即對資源占用較長時間；尤其在 soa 環境下，如果乙個 bm 需要呼叫其他乙個或多個ejb，web service 或 cics等服務介面，那麼transaction 占用的時間更長。
nio 的啟示是，改變設計模式就能帶來神奇的效果。
問題還是變主動呼叫為被動呼叫。 在 client + middlware + service的三層建構下， 中介軟體對 client 來說仍保持同步(sync), 而中介軟體以 listner 模式非同步監聽服務的呼叫回傳結果，避免連線，pipe等資源過長時間被堵塞，從而提高request的併發數，吞吐量，從而提高soa下分布式呼叫的效率。
像 axis2 等 web service 框架都提供web service 呼叫級別的非阻塞呼叫。而在具體專案中， 如果 service 是由 axis2 整合封裝，並且被整合的子服務都支援非阻塞呼叫，那麼ok， 這樣的目的可以達到； 而如果封裝的 facade 服務介面不支援 非阻塞，或者原子服務有其他協議，如 ejb，cics，corba 等，那麼可以考慮自己進行 nio 式的改造，來提高系統的效能。
SOA研究 1 從NIO開始
最近在看dubbo原始碼，覺得dubbo還是設計很優秀。有個想法模擬dubbo去寫乙個soa框架。編寫soa框架，首先要解決底層傳輸問題，雖然dubbo預設是用netty傳輸，但是也是基於nio。所以我自己寫了nio程式設計例項，開始研究soa之路。實現功能很簡單，client傳送訊息給server...
對SOA的理解
昨天與兩個同事聊到soa，由於大家都有在電信領域開發的背景，討論中形成了對soa較為準確和生動的理解，特寫此文以記之。現在soa的話語權主要集中在ibm，bea這樣的大公司手裡，在我看來，他們最擅於將簡單問題複雜化，用時下流行的話說，叫做 忽悠 愣是可以把乙個簡單的soa，劃分若干個看似nb的組成要...
我對SOA的反思 SOA架構的本質
年初的時候，寫過一篇名為 國內eai正當時，bpm為時尚早，workflow持續增長，soa依然概念 的blog日誌。那個時候，我認為soa還依然是個很 虛 的概念。而現在，我只能說 sorry，那時候的我，錯了。soa已經不再是概念，而是乙個實實在在的構架了。在寫完那篇帖子之後，我一直在反思soa...