構件，本是一個很古老的主題，SUN最初推出javabean即是一種可視組件的萌芽，可惜如同java的動態代理的潛伏期一樣，一直沒有足夠的人發現并重視起來。
與此同時，另外的陣營，Boland的delphi，Microsoft的V*家族以及現在.Net家族，卻不斷制造著高產易用的神話。
Java本來就是重視擴展和讓涉足的人享受背后機理的語言，如同做飯而非速餐，這早已成為一個很好的說辭。
今天，為了互操作而退出的webservice，實際就是接口的更泛化拓展；構件也從了組件的泛化延伸，成為一個極大成者。我們擁有了構件，我們也將走向了高速和易用，我們是否可以反思，當初闡釋不進Microsoft陣營的冠冕堂皇理由，是否經得起構件的洗禮？
想到了構件，不由延伸到了sca,更不由的觸及soa,從一個聽不懂的概念炒作歷經幾年之久走過多個版本的演化，成為今天的方法論和架構方法標準工具。曾經一味的熱情投入著，呼吁吶喊著，從為集成而生的理解到當今稍微成熟的soa本質既業務敏捷，也就是變化的需求；依然沒有逃出任何技術產生的直接機理：適應需求的變化。換句話說，一切技術思想方法論無不是為更好的適應需求的變化而生。
那中間的esb等是否真的是過度的羔羊？如果諸如IBM，BEA同樣擁有雄厚的ESB產品線的話，今天的soa定當別論；歷史不可假設，演化不可逆轉，soa的路也得益于此倆巨頭的“盲區”，否則tibco必然不會讓出esb頭把交椅。
那soa是否真的可以實現業務敏捷？摸著頭皮思考，良久良久，受個人閱歷（剛有不足3個月工作經驗）之限，雖閱讀各家之言，然不由悶笑。構件顯然不是，因為架子在具體細節依然離開不具體實現技術，一旦涉足技術就無法避免軟件工程的延遲等諸多風險因素，業務敏捷談何而來？如果說加強了業務人員和開發人員的溝通，亦為必然。不認為有了一個可以看得外貌就可以確定一些理解上的盲區，能畫出來的大多自然是彼此不存在疑惑的地方，但是很多地方亦是模棱區，產品或者說項目不是兒戲，不存在不可確定的東西，是就是非就非，最后落實的溝通是最有效的方式，也可能是迭代感知，這些都不是soa之大手筆。
那soa為何會走過如此多的路，最后走向了一個“無就是有有就是無，更多的成為道家的境界呢？”我覺得就是因為解決不了定位的目標，那歸結為一個無限大的話題---本來就是要正面的主題，肯定不會錯，改進多少年，反正都是在解決這個目標，這就是soa。
個人一時亂彈，友善交流，請勿攻擊漫罵之。