关于service和component的讨论

　　从设计哲学来说，Service和Component都是随着软件规模扩大追求软件生产的经济节约和灵活响应，从重用的角度来定义软件构造块，因此它们之间具有很多的相似性，但二者的抽象层次上截然不同。所谓抽象，简单的来说，就是用一种简单的视角表达事物的技巧，只描述与该视角相关的部分，而忽略其它不重要的内容。对于软件开发而言，抽象的一个具体方式和结果，就是通过更贴近问题域的形式化表达和重用，减少对底层代码行的依赖，来提高软件的生产效率，降低生产成本。大家从子过程、库函数以及OO中对象和类的演进过程中都可以找到抽象的痕迹。Component代表了一种从IT实现角度的抽象，它通过接口与实现分离，将功能分解成独立的构造单元，可以单独生产和管理。它依赖于某一特定的技术规范和容器(例如J2EE/.Net)，需要考虑如何实现，打包和部署。Component 的重用，一般是通过在应用开发过程过程中Plug和Assemble实现，与应用具有相同的生命周期。不同的应用需要部署相同的Component，因此在应用上线和运行周期内Unplug和Refactoring变得不是那么容易。而Service的出现，则代表了一种更高层次的抽象和演进。它从使用者的视角，更直接地描述到底能提供什么，而不关注它是怎么提供的。只要它提供了业务需要的行为和质量，谁又关注它到底是通过Component实现，还是Legacy系统开放出来的适配接口？较Component而言，它提供了独立于应用部署的可能性，可以与应用具有不同的生命周期，可以独立的重构和演进，使得大规模的重用变得更加的容易。

　　简而言之，Service在问题域和实现域之间增加了一个中间层，让业务和IT可以更好的对话。反映到系统设计开发上，SOA并不是彻底颠覆传统面向对象和组件的软件工程方法，而是在分析问题和解决问题方法上的进一步演进，并因此带来新的关于服务工程学的内容，包括服务的识别发现，服务设计实现，服务管控治理等一系列的过程和活动。就此回答此文开始的问题，服务的使用范围绝不限于企业内不同应用之间的集成，还包括单个应用内部，甚至企业与企业之间的重用和共享。只是不同的重用范围，会影响一系列的架构决策。如果一定要区分应用内部的服务和应用之间的服务的话，我更愿意借用OO中关于作用域的定义，将应用内部的共享服务称作private service，而将应用之间的共享服务称作public service。