浅析微软模式与实践小组的Service Layer Guidelines和OSOA架构体系(SCA,SDO等)之间的对应关系。
注：本文假设您已了解熟悉了SOA的一些重要概念，包括 SCA , SDO , BPEL , ESB ,以及微软体系下的WCF,消息队列,WorkFlow等概念。因为下文中将会通过对比一下这两个SOA技术体系的架构图来介绍一下其中的一些有意思的东西。
其组件中的数据操作要按业务规则进行。规则描述了数据如何被操作和传输。且业务规则可能简单也可能很复杂，这取决于业务本身。
说到这里，可以大胆的猜测一下：
微软的方案中虽然没有像OSOA中的流程编排层，业务服务层，服务组合层，但其Business Components应该也是支持服务（组件）组合功能和类似的流程编排层功能的（通过工作流提供）。而被组合起来的业务组件会以新的服务形式出现，当然也可以将这种组合类型组件看成是一个新的“组件”。一但这些组件被 开发
完毕要么以服务接口发布出去，要么被业务工作流进行编排驱动，从而完成相应的业务操作（工作流也 可以 以服务形式发布）。
其中，这里要介绍一下什么是“ 业务过程”：
一个业务过程就是一系列结合到一起的业务活动。每个业务活动完成整个过程中的一个具体的业务步骤。我们可以将Business Component看成是一个个具体的业务活动，而业务过程可以看成是业务工作流。当然业务工作流也可以看成是一个组合业务活动（composite business task），其自身也可以看成是一个业务组件，它还可以通过WCF方式的发布访问。说到这里，感觉微软的Business Components和BusinessWorkflows似乎有些重叠了，因为工作流所提供的业务编排功能，我通过组件复合方式也能提供呀（甚至在Service Layer中的ServiceInterface里），的确在开发层面上是这样的。但如果业务变化频繁时，我还有时间（开发和测试时间）去再写一个新的复合业务组件吗？而工作流就要简单了，只是拖拽之间就完成了业务逻辑的修改（当然这也是为什么要引入BPEL的原因之一）。当然体现这种优势的前提就是一开始设计开发出来的业务组件足够短
小精悍（粒度适中），便于组合(接口粒度)。并且能够很方便的通过业务规则进行消息数据的通信(不同协议)，
路由，传输等。
当然在看模式与实践小组的文章之前还看过另外一篇好像是“ 同一个妈生的文章”：
分层式体系结构中的实体框架
虽然简单但却非常清晰，不是吗？且其提供了相应的 实例代码 ，可以很容易让我们了解如何开发这种架构的软件。
说了上面这些，有人会说在OSOA中有ESB（ 不懂ESB的话去侃SOA，肯定要让人当成是一SB ），而微软的这个文档中好像没有，但仔细分析，不难发现，这里面还是有ESB的影子的。比如说图中的Cross-Cutting里的三个基本要素：安全(Security), 通信，操作管理就是ESB所强调的。
另外ServiceInterface关注的就是服务组件的发布（WSDL,UDDI等），注册，布署等相关内容。而消息路由，事务通信也都是通过WCF来实现的，所以这里是看不到的（因为已成为WCF的基本功能了）。因此在这里可以近似的认为：
WCF与WORKFLOW 这一“黄金搭挡”出现的结果就可以看成了一个ESB功能的精简版本
当然WCF在这里所起到的作用是决定性的，我们只要按自己的设计思路，用不同的属性绑定关键字以及配置相应的服务端和客户端的config中的通信结点即可。当然也曾有人说过BIZTALK也可以看成是ESB的重量级实现版本。但本人对这个服务器不了解，就不便多说什么了。
当然在CODEPLEX上已有一些ESB开源的项目，如ESB.NET，impleServiceBus(NServiceBus的精简版，只提供消息队列实现功能）等。
通过上面所说的内容，可以看出，微软是要“ 走自已的路，让OSOA去说吧 !”。必定手中有开发语言，工具，框架，技术等资源，何必受制于人呢，还不如按自己的想法大干一场，这应该也是其在“真实世界中的SOA”文中所表达的思想吧。
==========================================================================
相比较微软的架构图，OSOA的架构图要复杂一些了，起码多出了 一些层 ，当然在微软的架构中， 这些层所实现的功能和架构思路是被合并到了Business这一层中了 （参见上文）。但凭心而论，OSOA这个图是我看到的最清晰明确的SOA架构路线图了，并且其分层结构也考虑了EAI方面的因素。
首先是SOA特有的层（银白色图形区域）：
服务基础架构层： infrastructure service layer
该层主要是非业务性的功能。这些服务是基础类服务，不包含任何业务逻辑。纯数据读取类服务也是基础服务；它们只是把对底层数据存储层的访问作为一种服务。这一层也可以称为功能服务层。基础服务依赖于当前的企业数据层和企业业务层。
业务服务层： business service layer
可以认为业务过程中的每一个步骤都是一个服务，即业务服务。业务服务的粒度取决于该服务所需实现的业务活动。业务服务层依赖于当前的企业数据层和企业业务层。 该层与下面的服务组合层可以与上面微软架构中的Business层中的Business component功能相近 。
服务组合： service composition layer
我们把实现组合业务活动的（即上文中所提到的）服务称为一个服务组合。组合业务活动构成了一个抽象层，隐藏了内部详细的业务活动。另外，还能比较容易地加入新服务，而无需对既有的接口作出任何改动。该层依赖于业务服务层和基础服务层。设计时与部署时程序组装都可以用来创建组合服务。设计时程序集要编写业务服务（或基础服务）的调用顺序。这种实现方法称为设计时程序组装。部署时程序组装通过配置来确定顺序，即调用顺序是通过合适的配置语言来实现的。这种方式需要底层软件的支持。
流程编排层： Orchestration Layer
流程编排服务包含了所有的业务过程。像业务流程执行语言（ BPEL ）之类的语言就是用来实现流程编排服务的。流程编排服务由所需的业务服务、服务组合和基础服务组成。这一层也可以称为业务过程层。 该层与微软架构中的Business层中的Business Workflow功能相近 。
服务注册： Service Registry
服务注册层（service registry）记录着可用服务的信息。服务注册信息可以不必局限于统一描述与发现和集成协议（UDDI）或Java命名与发现（JNDI）接口标准，它可以储存为任何方便查找服务的形式。注册信息包含了流程编排服务、组合服务、业务服务和基础服务的详细信息。这一层也就是企业当前业务目录。 微软WCF提供了该功能 。
消息传输层： Messaging
消息传输层包括服务层内的业务消息交互；这些消息负责消息层内的消息传输。对这些消息的定义也是这一层的一部分。消息传输层还为其它层之间的消息传输提供消息系统支持。消息系统便于服务层之间进行交互。比如，可以认为企业服务总线就是服务的消息系统。 微软WCF提供类似功能 。
服务管理： Service Management
服务管理和监控系统是服务管理层的一部分。监控系统可以提供与服务相关的有用信息，比如使用率、处理能力和其它性能相关的信息。可以利用这些系统提取与业务关键性能指标相关的实时信息。服务管理工具也是这一层的一部分，包括安全辅助管理工具、负载平衡工具和其它与服务管理相关的工具。这一层也可以称为SOA管理层。业务活动监控工具可以提供与这一层相关的支持。
除了上面SOA的特有层之外，就是我们平时开发应用时所惯用的分层方式：
企业数据层： 数据层
企业数据层就是企业的数据存储库。一项成功的商业操作所需要的所有数据都是这个逻辑层的一部分。这些数据包括数据库信息、文件系统、分层目录、遗产储存系统以及其它储存介质。这一层就是传统的多层架构中的数据层。
企业业务层： 业务层
企业业务层由企业的业务应用（与逻辑）构成。它包括使用.Net、企业版的Java平台或其它各种技术开始的应用程序（与逻辑）。例程的逻辑也包括在这一层中。简单来说，这一层就是企业当前业务的主干和传统的多层架构中的业务层。
企业前台应用/通道： 表现层
所有业务的前台应用和通道都是这第三层的一部分，包括依赖企业骨干系统运行的整个桌面和Web前台。业务通道包括外部的B2B接口系统，比如交易系统和地址确认系统。这一层组成了传统的多层架构中的表现层。
通过OSOA的架构图，我们很容易看过如果企业或公司要进行业务整合或开发SOA应用软件的话，从什么地方入手。比如进行业务整合时，数据层，业务层，表现层就是我们已有的IT软件资产，我们则要在表现式层与业务层之间，加入我们采用SOA思路设计架构的代码。而如果是开发新的SOA系统，我们只要按这种架构之后，将来出现系统与其他外部系统整合时，而会很容易进行二次开发只要添加或修改SOA特有层中的代码就行了（当然也有可能会修改业务层Enterprise Business Layer代码）。
"当然该图也可以帮助确定当前的环境与目标SOA设施之间存在的差距，作为开发可重用的SOA框架的项目的参考，把产品环境映射到逻辑结构中，从而有效地确定项目所需的SOA相关产品。"
说到这里其实还有很多话题没说，比如开发业务组件的问题，BPEL到底该是什么样子等等，以后再聊吧。
注：本文假设您已了解熟悉了SOA的一些重要概念，包括 SCA , SDO , BPEL , ESB ,以及微软体系下的WCF,消息队列,WorkFlow等概念。因为下文中将会通过对比一下这两个SOA技术体系的架构图来介绍一下其中的一些有意思的东西。
首先登场的就是
OSOA中的架构图：
先聊一下微软的架构图：
在微软图中的Business (业务层) 和Services (服务层)，其中的Services层中包括两种组件：
ServiceInterfaces：用于暴露服务接口，其核心内容就是对业务逻辑层的实现进行“封装”，而这些服务会被调用这些服务的对象所消费(Custom)。
MessageTypes: 消息类型，即在服务层上进行交换的数据类型。其数据结构采用消息结构进行封装，以支持不同的操作。包括：命令消息（数据）, 文档消息（Document message）或其他在服务的提供者（message contracts）与消费者（consumers ）之间进行通信的消息契约(message contracts).
可以看出前台的业务表现层(presentation)以及外部系统协作都是使用这一层提供的服务接口和定义的消息类型数据。
注：上面两层中的ServiceInterfaces与OSOA标准体中的ServiceRegistry功能很相似（后面会提到），而MessageTypes可以看成是OSOA体系中SDO的“微软版本”。
在上图中的Business层与OSOA图中的差别偏大。因为OSOA中也有Enterprise Business Layer(企业业务层)，并且在此基础上引入了而基础服务架构层（infrastructure service layer）、业务服务层（business service layer）和服务组合层（service composition layer）又可以统称为服务层。
而微软则通过业务工作流，业务组件，业务实体类，并在此基础上进行应用级别的封装(ApplicationFacade) , 按说这种结构倒是很接近于我们日常开发中所使用的业务逻辑封装方式。且其BusinessWorkflows与OSOA中的流程编排层的设计意图很相近，因为流程编排服务包含了所有的业务过程。且BPEL之类的语言就是用来实现流程编排服务的。这就是解释了为什么不少人把微软的工作流看成了BPEL的“变身”，当然两者的差别还是很大的:)
而Business Components（业务组件）又很像是OSOA中的 SCA，按照“模式与实践”小组的文档中的描述是这样的：
在微软图中的Business (业务层) 和Services (服务层)，其中的Services层中包括两种组件：
ServiceInterfaces：用于暴露服务接口，其核心内容就是对业务逻辑层的实现进行“封装”，而这些服务会被调用这些服务的对象所消费(Custom)。
MessageTypes: 消息类型，即在服务层上进行交换的数据类型。其数据结构采用消息结构进行封装，以支持不同的操作。包括：命令消息（数据）, 文档消息（Document message）或其他在服务的提供者（message contracts）与消费者（consumers ）之间进行通信的消息契约(message contracts).
可以看出前台的业务表现层(presentation)以及外部系统协作都是使用这一层提供的服务接口和定义的消息类型数据。
注：上面两层中的ServiceInterfaces与OSOA标准体中的ServiceRegistry功能很相似（后面会提到），而MessageTypes可以看成是OSOA体系中SDO的“微软版本”。
在上图中的Business层与OSOA图中的差别偏大。因为OSOA中也有Enterprise Business Layer(企业业务层)，并且在此基础上引入了而基础服务架构层（infrastructure service layer）、业务服务层（business service layer）和服务组合层（service composition layer）又可以统称为服务层。
而微软则通过业务工作流，业务组件，业务实体类，并在此基础上进行应用级别的封装(ApplicationFacade) , 按说这种结构倒是很接近于我们日常开发中所使用的业务逻辑封装方式。且其BusinessWorkflows与OSOA中的流程编排层的设计意图很相近，因为流程编排服务包含了所有的业务过程。且BPEL之类的语言就是用来实现流程编排服务的。这就是解释了为什么不少人把微软的工作流看成了BPEL的“变身”，当然两者的差别还是很大的:)
而Business Components（业务组件）又很像是OSOA中的 SCA，按照“模式与实践”小组的文档中的描述是这样的：
After a user process collects the data it requires, the data can be operated on using
business rules. The rules will describe how the data should be manipulated and transformed
as dictated by the business itself. The rules may be simple or complex, depending on the
business itself. The rules can be updated as the business requirements evolve.
business rules. The rules will describe how the data should be manipulated and transformed
as dictated by the business itself. The rules may be simple or complex, depending on the
business itself. The rules can be updated as the business requirements evolve.
其组件中的数据操作要按业务规则进行。规则描述了数据如何被操作和传输。且业务规则可能简单也可能很复杂，这取决于业务本身。
说到这里，可以大胆的猜测一下：
微软的方案中虽然没有像OSOA中的流程编排层，业务服务层，服务组合层，但其Business Components应该也是支持服务（组件）组合功能和类似的流程编排层功能的（通过工作流提供）。而被组合起来的业务组件会以新的服务形式出现，当然也可以将这种组合类型组件看成是一个新的“组件”。一但这些组件被 开发
完毕要么以服务接口发布出去，要么被业务工作流进行编排驱动，从而完成相应的业务操作（工作流也 可以 以服务形式发布）。
其中，这里要介绍一下什么是“ 业务过程”：
一个业务过程就是一系列结合到一起的业务活动。每个业务活动完成整个过程中的一个具体的业务步骤。我们可以将Business Component看成是一个个具体的业务活动，而业务过程可以看成是业务工作流。当然业务工作流也可以看成是一个组合业务活动（composite business task），其自身也可以看成是一个业务组件，它还可以通过WCF方式的发布访问。说到这里，感觉微软的Business Components和BusinessWorkflows似乎有些重叠了，因为工作流所提供的业务编排功能，我通过组件复合方式也能提供呀（甚至在Service Layer中的ServiceInterface里），的确在开发层面上是这样的。但如果业务变化频繁时，我还有时间（开发和测试时间）去再写一个新的复合业务组件吗？而工作流就要简单了，只是拖拽之间就完成了业务逻辑的修改（当然这也是为什么要引入BPEL的原因之一）。当然体现这种优势的前提就是一开始设计开发出来的业务组件足够短
小精悍（粒度适中），便于组合(接口粒度)。并且能够很方便的通过业务规则进行消息数据的通信(不同协议)，
路由，传输等。
当然在看模式与实践小组的文章之前还看过另外一篇好像是“ 同一个妈生的文章”：
分层式体系结构中的实体框架
其结构图如下：
虽然简单但却非常清晰，不是吗？且其提供了相应的 实例代码 ，可以很容易让我们了解如何开发这种架构的软件。
说了上面这些，有人会说在OSOA中有ESB（ 不懂ESB的话去侃SOA，肯定要让人当成是一SB ），而微软的这个文档中好像没有，但仔细分析，不难发现，这里面还是有ESB的影子的。比如说图中的Cross-Cutting里的三个基本要素：安全(Security), 通信，操作管理就是ESB所强调的。
另外ServiceInterface关注的就是服务组件的发布（WSDL,UDDI等），注册，布署等相关内容。而消息路由，事务通信也都是通过WCF来实现的，所以这里是看不到的（因为已成为WCF的基本功能了）。因此在这里可以近似的认为：
WCF与WORKFLOW 这一“黄金搭挡”出现的结果就可以看成了一个ESB功能的精简版本
当然WCF在这里所起到的作用是决定性的，我们只要按自己的设计思路，用不同的属性绑定关键字以及配置相应的服务端和客户端的config中的通信结点即可。当然也曾有人说过BIZTALK也可以看成是ESB的重量级实现版本。但本人对这个服务器不了解，就不便多说什么了。
当然在CODEPLEX上已有一些ESB开源的项目，如ESB.NET，impleServiceBus(NServiceBus的精简版，只提供消息队列实现功能）等。
通过上面所说的内容，可以看出，微软是要“ 走自已的路，让OSOA去说吧 !”。必定手中有开发语言，工具，框架，技术等资源，何必受制于人呢，还不如按自己的想法大干一场，这应该也是其在“真实世界中的SOA”文中所表达的思想吧。
==========================================================================
相比较微软的架构图，OSOA的架构图要复杂一些了，起码多出了 一些层 ，当然在微软的架构中， 这些层所实现的功能和架构思路是被合并到了Business这一层中了 （参见上文）。但凭心而论，OSOA这个图是我看到的最清晰明确的SOA架构路线图了，并且其分层结构也考虑了EAI方面的因素。
首先是SOA特有的层（银白色图形区域）：
服务基础架构层： infrastructure service layer
该层主要是非业务性的功能。这些服务是基础类服务，不包含任何业务逻辑。纯数据读取类服务也是基础服务；它们只是把对底层数据存储层的访问作为一种服务。这一层也可以称为功能服务层。基础服务依赖于当前的企业数据层和企业业务层。
业务服务层： business service layer
可以认为业务过程中的每一个步骤都是一个服务，即业务服务。业务服务的粒度取决于该服务所需实现的业务活动。业务服务层依赖于当前的企业数据层和企业业务层。 该层与下面的服务组合层可以与上面微软架构中的Business层中的Business component功能相近 。
服务组合： service composition layer
我们把实现组合业务活动的（即上文中所提到的）服务称为一个服务组合。组合业务活动构成了一个抽象层，隐藏了内部详细的业务活动。另外，还能比较容易地加入新服务，而无需对既有的接口作出任何改动。该层依赖于业务服务层和基础服务层。设计时与部署时程序组装都可以用来创建组合服务。设计时程序集要编写业务服务（或基础服务）的调用顺序。这种实现方法称为设计时程序组装。部署时程序组装通过配置来确定顺序，即调用顺序是通过合适的配置语言来实现的。这种方式需要底层软件的支持。
流程编排层： Orchestration Layer
流程编排服务包含了所有的业务过程。像业务流程执行语言（ BPEL ）之类的语言就是用来实现流程编排服务的。流程编排服务由所需的业务服务、服务组合和基础服务组成。这一层也可以称为业务过程层。 该层与微软架构中的Business层中的Business Workflow功能相近 。
服务注册： Service Registry
服务注册层（service registry）记录着可用服务的信息。服务注册信息可以不必局限于统一描述与发现和集成协议（UDDI）或Java命名与发现（JNDI）接口标准，它可以储存为任何方便查找服务的形式。注册信息包含了流程编排服务、组合服务、业务服务和基础服务的详细信息。这一层也就是企业当前业务目录。 微软WCF提供了该功能 。
消息传输层： Messaging
消息传输层包括服务层内的业务消息交互；这些消息负责消息层内的消息传输。对这些消息的定义也是这一层的一部分。消息传输层还为其它层之间的消息传输提供消息系统支持。消息系统便于服务层之间进行交互。比如，可以认为企业服务总线就是服务的消息系统。 微软WCF提供类似功能 。
服务管理： Service Management
服务管理和监控系统是服务管理层的一部分。监控系统可以提供与服务相关的有用信息，比如使用率、处理能力和其它性能相关的信息。可以利用这些系统提取与业务关键性能指标相关的实时信息。服务管理工具也是这一层的一部分，包括安全辅助管理工具、负载平衡工具和其它与服务管理相关的工具。这一层也可以称为SOA管理层。业务活动监控工具可以提供与这一层相关的支持。
除了上面SOA的特有层之外，就是我们平时开发应用时所惯用的分层方式：
企业数据层： 数据层
企业数据层就是企业的数据存储库。一项成功的商业操作所需要的所有数据都是这个逻辑层的一部分。这些数据包括数据库信息、文件系统、分层目录、遗产储存系统以及其它储存介质。这一层就是传统的多层架构中的数据层。
企业业务层： 业务层
企业业务层由企业的业务应用（与逻辑）构成。它包括使用.Net、企业版的Java平台或其它各种技术开始的应用程序（与逻辑）。例程的逻辑也包括在这一层中。简单来说，这一层就是企业当前业务的主干和传统的多层架构中的业务层。
企业前台应用/通道： 表现层
所有业务的前台应用和通道都是这第三层的一部分，包括依赖企业骨干系统运行的整个桌面和Web前台。业务通道包括外部的B2B接口系统，比如交易系统和地址确认系统。这一层组成了传统的多层架构中的表现层。
通过OSOA的架构图，我们很容易看过如果企业或公司要进行业务整合或开发SOA应用软件的话，从什么地方入手。比如进行业务整合时，数据层，业务层，表现层就是我们已有的IT软件资产，我们则要在表现式层与业务层之间，加入我们采用SOA思路设计架构的代码。而如果是开发新的SOA系统，我们只要按这种架构之后，将来出现系统与其他外部系统整合时，而会很容易进行二次开发只要添加或修改SOA特有层中的代码就行了（当然也有可能会修改业务层Enterprise Business Layer代码）。
"当然该图也可以帮助确定当前的环境与目标SOA设施之间存在的差距，作为开发可重用的SOA框架的项目的参考，把产品环境映射到逻辑结构中，从而有效地确定项目所需的SOA相关产品。"
说到这里其实还有很多话题没说，比如开发业务组件的问题，BPEL到底该是什么样子等等，以后再聊吧。
好了，个人主观上“胡说八道”了一些东西，希望我没有理解错这些图和相应概念。当然大家如果有不同意见，欢迎在回复中进行讨论。必定SOA这个东西覆盖面广，新名词多，且所涉略的技术领域前后关联密切。
本文转自 daizhenjun 51CTO博客，原文链接：http://blog.51cto.com/daizhj/124342，如需转载请自行联系原作者
