作為技術愛好者的我，常常從技術的角度考慮問題，也往往陷入技術的細節，而忽略了大局觀。
當不斷閱讀業界的文，尤其是soa相關分析，我日益感覺如是考慮問題的弊端，或許這也是開發者（junior, senior software developer）與系統架構師（system designer and architecture）的區別。前關心技術細節和技術的深度；后關心技術的解決問題面和技術的寬度。
回頭再思考soa，才發現通過技術角度幾乎無法理解soa的本質和初衷。web service的鐵三角：服務提供者、服務消費者、服務注冊中心。 soa的鐵三角：數據、業務構件、組合。技術我門關注了web service,一種很好的分布式系統、異構系統間互聯互通的解決方案，也是一種很好的面向接口的設計思想；sca sdo則因為web service的不能描述服務間依賴和服務組合而提出（附注1），也很好的體現了所謂的業務數據的組織。僅此而已，再多一點，esb負責消息路由和交互功能也隱含于sca的部署描述符來完成，esb的事件觸發機制.....；或許我們能夠很好的理解技術，正如架構師和高級開發人員區別所體現，我們對技術的初衷和目地有清晰的了解么？我們能夠針對某一個目標選擇出合適的技術來么？我慚愧的感覺自己的力不從心。
依然以soa為例來說這個問題。soa和web servie的初衷并不完全吻合，如果說web service是soa實現手段也有點牽強附會。web service初衷是什么？web service為解決互聯互通的分布式應用的互操作而生；而soa并不是為互聯互通的目標，而是為業務敏捷性而生。也道出soa實際本質背后的業務模型和業務數據；它要使得業務具有敏捷性，必然要求技術實現和業務脫離；這樣業務才能夠快速只管有效的表達和示意；相應，輔助手段也就有了要求，就是構件，業務負責人就可以如同堆積木般組織業務，技術人員拿到業務模型后開發就是，新需求或者業務需要就是變更和重組業務，對業務模型進行重組和重構，就是soa提供的有效手段 。
作為開發者的我，往往會因為一種技術的熱門而去跟蹤或者拼命想用于項目，但是它真的被需要么？真的是必要的么？是預期資源可控的么？沒有去想，怕的是被潮流或者趨勢淘汰，哪怕并不合理，也不理會性能和效率。你是否也具有此問題呢？
所以理智的對待問題，在時間、團隊、資源內考慮技術的選擇，從技術初衷以及技術的優缺點去選擇技術，從宏觀上理智的把控，而不是人云亦云。譬如大家批判ejb，因為ejb的初衷應用背景往往被濫用。這也符合spring創始人的“循環設計”理念。
附注1：
組合服務：
1）bpel也是組合服務，但我更覺得他用于流程控制；
2）web servie的不足：定位于接口的暴露，但是不解決服務組合問題；
或許你可以說，設計一個類，包含所有需要的業務，然后把類發布成服務。可是需要組合得業務往往來源于不同系統，異構即不同語言，你如何表達于一個類呢？
或許你又可以說，設計一個類，里面聚合很多服務，然后把類再次發布為服務，這部也是一個聚合服務么？
對，是很好，但是如果業務再次變化呢？sca或許好一些，通過配置描述符。此處留下一點不確定，希望大家討論。