cuiyi's blog（崔毅 crazycy）

粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。举个例说明最为清楚:向计费系统中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统中，添加详细的客户联系方式、添加计费信息等等。

采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够。Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。

除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中止。与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反馈的唯一途径。

Code First vs WSDL Frist 如果要构建一个Web Services，CXF提供了两种构建方式一个是Code First，另一个WSDL First。接触过WSDL的朋友应该都有这样的感觉，WSDL虽然是用XML来进行描述的，但是如果让你在不借助任何工具的情况下写一个正确的WSDL，或者是改正一个错误的WSDL是很难的。Code First可以说是为我们提供了一个不错的选择。

但是Web Services的Best Practies并不推荐Code First这一Web Services的构建方式。原因是什么呢？

这是因为我们在使用Code First构建方式时很少考虑到Web Services之间的交互是以文档方式进行（这样可以大大提高Web Services的互交互性），如果是使用Code First来构建WSDL信息，在描述描述交互信息的XML Schema都是以我们的Code中定义的类型信息来生成的，这样就可能会暴露一些比较细粒度的信息。同时大家知道不同的语言（C＋＋，Java， C＃，PHP）对XML Schema映射是各不相同的，如果我们Code中定义的类型很特殊，就可能产生出一个不能互操作的现象。

所以Best Practies建议你在创建Web Services从交互的消息Schema入手，构建一个中间层来提供一个比较粗粒度的描述，这样可以比较好的解决Web Services的互交互问题。

分级

一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差的服务。

在服务分级方面，须注意服务层的公开服务通常由后台系统（BES's）或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。

松散耦合

SOA具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。

服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。

大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现，Web服务对于SOA服务接口来讲是一个重要的标准。

当使用者调用一个Web服务时，被调用的对象可以是CICS事务、DCOM或CORBA对象、J2EE EJB或TUXEDO服务等，但这与服务使用者无关。底层实现并不重要。

消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购订单），而非一组离散的参数。Web服务接收整个文档、进行处理、而后可能或者不会返回结果信息。由于客户和Web服务间不存在紧密耦合请求响应，消息类Web服务在客户和服务器间提供了更为松散的耦合。

明确的边界
通过跨越定义明确的边界进行显式消息传递，服务得以彼此交互。有时候，跨越服务边界可能要耗费很大的成本，这要视地理、信任或执行因素而定。边界是指服务的公共接口与其内部专用实现之间的界线。服务的边界通过 WSDL 发布，可能包括说明特定服务之期望的声明。

精确定义的服务接口

服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意的关键点是，服务契约必须进行精确定义。

META将SOA定义为：“一种以通用为目的、可扩展、具有联合协作性的架构，所有流程都被定义为服务，服务通过基于类封装的服务接口委托给服务提供者，服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。

 面向文档
消息被构造为“纯文本的”XML文档（换句话说，数据的格式只对XML有意义）。 消息通常用于传输业务文档，比如购买订单、发票和提单。这种交互类型与同步消息排队系统的兼容性很好，比如MQ Series、MSMQ、JMS、TIBCO、IMS等等。 

    SCA主要是针对在面向服务的计算环境里，组件的实现方法。同时，它强调了这些组件与现有的平台，组件之间的关联，并描述怎样通过已有的技术、平台甚至于现有的组件来实现面向服务组件。另外，在将这些服务组件实现以后，它们的接口以及这些接口的语义是怎样描述的。

    其实，新的组件描述应该是技术独立、平台独立、语言独立的，也就是说它是一个开放的规范，这样就可以让很多IT厂商在不同的平台上用不同技术和语言来参考和实现这些技术。除此之外，面向服务的组件需要相互之间的交互，这种交互应该是松耦合的，也就是说需要打破过去那种紧耦合的现象。因为不管是.NET、J2EE还是更早的CORBA等技术，它们在支持分布式计算时，其组件往往和平台、语言以及实现技术紧密相关。       　

    过去，如果一个组件要调用另外一个组件的功能，它需要知道后者的接口在什么位置，使用什么协议和消息格式，这往往与其实现技术有直接的关系，所以技术、平台、语言和位置等各种各样的因素的透明性对于组件之间的交互就是非常重要的一件事情了，而SCA恰恰就规定了这一部分的内容。                                                                                 

    过去我们所采用的技术中，不管是.NET也好，J2EE也好，它们都有基于自身平台下的规范，比如在J2EE环境下，我们就会通过JDBC、Entity Bean这样的方式访问数据库或者其它数据源;而在.NET下同样有类似ADO这样的方式来访问各种不同的数据源。这里面的问题在于，平台透露了太多的技术细节，程序员需要了解很多相关的内容，比如他需要创建一个JDBC或ODBC的数据源，再利用这些规范所提供出来的编程接口来想办法得到数据源中的数据，为达成这个目标，程序员还需要去做对象-关系映射，以实现对象到关系数据库或者与之相反的数据转换。目前有一些技术可以用来解决这些问题，比如前段时间在Java社群中一直都非常流行的Hibernate等，诸如此类的方法和工具很多，他们都是用来协助程序员处理上述工作的。但无论如何，你都无法逃避地要看到很多这些方法中非常底层的技术细节，而且，程序员需要学习所有这些不同的技术，了解它们适应于什么情况，处理各种情况下的不同技术细节。事实上，程序员需要抽象层次更高的东西，比如业务数据对象(Business Object)以及它内部各种细粒度数据对象之间的关联，这是可以用一致、通用的方式来表示和操作的。有了抽象层次更高的模型，程序员就可以通用的方式来定义和访问业务数据，从而以统一的方式来描述和访问不同的数据源，降低对程序员技能的要求，提高生产率，更容易在不同的应用环境交换。

　　这样，不管是Java或者C++语言描述下，程序员都不必去了解平台上的技术细节，用一个XML Schema描述这样的通用、简单的的业务数据模型，然后在运行将对象持久化到你的关系数据库、XML或者其它数据源中。

    SDO 的目标有很多，从某种程度上讲 SDO 看起来好像是 J2EE 的一把多功能“瑞士军刀”，因为它包含的特性可实现多种不同种类的功能，基本来讲，SDO 及其相关的技术设计有以下五大主要专题:

　　1）简化数据访问:第一个目标是提供对多种企业信息系统 (EIS) 的统一的数据访问，包括数据库、遗留应用程序(使用 JCA)、XML 或者是 Web 服务数据源。通过使用 SDO 的一种独特而简单的模型，应用程序摆脱了使用多种 API 和框架进行数据访问的复杂工作。

　　2）数据提取:使用 SDO 后，数据的表示是独立于其数据源的，它采用了一种叫做 Domain Store 的 J2EE 模式，这种级别的数据提取有很多优点，例如使数据操作变得更容易，实现了不同层之间的松耦合。

　　3）数据操作:一旦检索到信息后，SDO 会提供一种统一的编程语言进行数据操作，简单的说，就是通过使用 API 及其接口，SDO 客户机可以读取数据和修改数据。SDO 为此提供了连接和断开连接的两种模型。

　　4）数据传输:SDO 有一部分概念是关于传输对象 (Transfer Object) 和传输对象组装程序 (Transfer Object Assembler) 模式的。数据封装到 SDO 对象中后，它就可以在 J2EE 层间高效地传输。

　　5）设计模式的采用:SDO 的一个关键目标是鼓励大家采用公用的 J2EE 模式，这也是 SDO 体系结构以一些广为人知的模式为基础的原因，例如传输对象 (Transfer Object)、数据访问对象 (Data Access Object)、传输对象组装程序和 Domain Store等。如果使用了 SDO，应用程序就可以从这些经过了验证的设计策略中受益，从而可以推动分层技术和松耦合的发展。