上周跟一个客户交流关于SOA架构设计和服务工程的话题，期间谈到面向服务的应用开发与传统的应用开发最大的不同点在于对问题域求解的企业级视野，不想引发了一场关于Service和Component的讨论。有人说，正因为视野的不同，Service是关注企业内不同应用之间的共享，而单一应用本身的设计构造单元是Component，不需要Service。我想这代表了一部分人对SOA和Service的看法。而我认为，SOA可以也必须应用于单个业务系统本身，以共享Service为中心来构建。

从设计哲学来说，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。