面向组件COP

原文：http://www.ibm.com/developerworks/cn/linux/software_engineering/l-frmwk/index5.html

几个重要的概念：

服务，服务（Service）是一组接口，供客户端程序使用。例如，验证和授权服务，任务调度服务。服务是系统中各个部件相互调用的接口；

组件，组件（Component）实现了一组服务，此外，组件必须符合容器订立的规范，例如，初始化，配置、销毁；

通过定义组件之间的协作关系（通过服务）来完成系统的构建。这样做的好处是能够隔离变化，合理的划分系统。

理解组件

理解组件

组件不是一个新的概念，Java中的javaBean规范和EJB规范都是典型的组件。组件的特点在于他定义了一种通用的处理方式。例如，JavaBean拥有内视的特性，这样就可以通过工具来实现JavaBean的可视化。
所以，组件比起对象来的进步就在于通用的规范的引入。通用规范往往能够为组件添加新的能力（就像上面所讨论的），但也给组件添加了限制

组件的粒度

组件的粒度是和系统的架构息息相关的。组件的粒度确定了，系统的架构也就确定了。在小规模的软件中，可能组件的粒度很小，仅相当于普通的对象，但是对于大规模的系统来说，一个组件可能包括几十，甚至上百个对象。因此，对使用COP技术的系统来说，需要正确的定义组件的粒度。较好的定义粒度的方法是对核心流程进行分析。
针对接口

接口和实现分离是COP的基础，没有接口和实现的分离，就没有COP。接口的高度抽象特性使得各个组件能够被独立的抽取出来，而不影响到系统的其它部分。

接口和实现分离有以下几个好处：

1、 在模块/组件/对象之间解耦。

2、 轻松的抽换实现，而不用修改客户端。

3、 用户只需要了解接口，而不需要了解实现细节。

4、 增加了重用的可能性。

理解服务

在讨论组件时我们谈论了组件粒度的问题。当组件的粒度不仅仅限于单个对象的时候。在构成组件的多个对象中，有些对象处于组件内部，不和其它的组件交互，有些对象需要和外部组件进行交互。后一种对象起的就是服务的作用。
服务订立了组件和组件之间的契约。这种契约是稳定的（如果业务需求是稳定的），不会随着组件内部的变化而发生变化。

要理解这一点也非常的容易。对于一个提供用户认证的组件，一个可能的服务对用户进行认证和授权，至于组件内部采用LDAP还是关系数据库来存放用户信息，对服务来说没有任何的差别。

这样做的好处有很多，一是组件之间能够以一种稳定的方式存在，组件内部的变化不至于扩散到整个软件系统。二是软件设计将会转向重点设计组件之间的服务，而组件的实现细节将会隐藏起来，这不但有助于设计者更好的把握软件的全局架构，而且有助于分工的细化。

服务并不是什么新颖的概念，RPC、IDL都是类似的技术。但我们谈的服务侧重架构和理念，不涉及到具体的技术，这一点同SOA和WebService的关系类似－SOA是一个结构性的概念，而WebService是实现SOA的一种适合的技术

服务最好实现为接口。原则上服务可以是任何一种技术：JMS、WebService、RPC、或是简单方法调用。但是出于服务的稳定性的考虑，我们不应该将一个服务和具体的技术绑定起来，这样会使的服务发生变化的可能性增大。在Java语言中，接口是具有极大的灵活性的，因此，将接口实现为普通的Java接口是较好的选择。不过，这样做的话，我们也许就不能够使用远程调用，Web服务之类的功能了，不过这并不要紧，以下就是原因
服务适配器

客户端可以直接使用接口，也可以通过适当的适配器来将普通的接口服务转换为特定技术实现的服务。

如上图所示，一个普通的接口通过适配器模式转换成和特定技术相关的服务。在JMX技术中，也采用这种方式，JMX平台能够将一个普通的服务端口通过适配器进行转换，以适用于各种的协议，例如http、sock、snmp等等。