作为技术爱好者的我，常常从技术的角度考虑问题，也往往陷入技术的细节，而忽略了大局观。
当不断阅读业界的文，尤其是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或许好一些，通过配置描述符。此处留下一点不确定，希望大家讨论。