面向服务的架构（SOA）已经被IT业界广泛的接受了。它主要被用作把传统的独立自治的软件系统联系起来。为了达到联系不同的且自治的系统的目标，SOA定义了一些核心设计原则：服务的边界要区分开来，服务间共享协议和架构；服务间交互通过使用基于消息的通讯；服务是自治的，且独立管理；服务使用策略声明来控制行为。

　　不过，对一个负责结合内部和外部的服务系统的健壮的架构（如同SOA）的需求不是没有挑战。这些挑战使得在企业中实现SOA困难重重。有些挑战必须通过技术架构师来解决，在他们整合系统的时候。系统包括一致的管理，分布环境中的授权，服务集合和实体集合。

　　这篇文章主要关注实体集合（EA）。明确说，它关注需要将不同系统提供的信息综合在一起时的问题。本文讨论了不同的用在EA解决方案中的解决方案模型，一些技术架构师在实现解决方案时遇到的一些基础的设计问题。最后，它包含了可能在构建EA解决方案中会使用到的微软技术。

　　随着近些年来商业的不断扩大，对IT系统的需求也不断增加。随着整合成为标准，对新系统的需求更大了。结果是，如今的企业都由许多各自独立的IT系统构成，有数以百计的应用程序孤岛。

　　在这个复杂系统环境下，存在着应用系统围栏。这些软件系统是自治的，对外面的世界完全不了解。诸如客户和雇员的商业理念随着他们自身的发展而在系统中复制。很长时间，这些独立系统的存在没有引起任何关注，因为它是典型的个体商业单元，自主运行，在系统间手动的进行配合活动。最近几年中，无论如何，商业界开始有新的需求，浮现出新的趋势。

　　有了这个趋势，系统间商业过程自动化的趋势提升了面向服务架构（SOA）的价值。集合来自不同系统的信息（实体）是构建支持这个趋势的解决方案所必须的。比如，许多商业环境中，雇员必须分别打电话给人力资源系统，支付系统和收益系统以便在不同的系统内更新他们的地址。通过SOA，许多系统结合起来，不同系统间的实体也集合在了一起。通过让这些简单过程的自动化，雇员现在可以只打一个电话或使用一个自助服务的入口来在许多系统中更新他们的个人信息。

　　把系统用面向对象的架构连接起来可以减少所有权的总成本（TCO）。随着时间的过去，企业IT团体可能计划藉由整合多样的系统直接地给使用者递送服务。这意谓着像是企业资源规划(ERP)系统和客户关系管理 (CRM)系统提供的服务，将会对最终用户是可得的，这造成TCO全面的减少。

　　SOA承诺继续刺激IT业的对话而且维持与寻求降低费用，增加在投资 (ROI) 方面的返回，举债经营现有的资产，而且整合系统。除此之外, 在实体集合解决方面的兴趣将会连同面向服务的架构的普及性一同增加。

　　采用一个面向服务的架构将不只是被牵涉的每个人的一个大任务，但是它也意谓着组织的一个重要变化。 结果，这一任务必须被适当地处理。这是实体集合扮演一个大角色地方。

　　实体集合解决能被设计成不只在存取信息方面担任一个单一点，也提供一个实体和实体模型的整体观察。另外地，实体集合处理一些设计问题以确保面向服务的架构成功实现。

　　本文的其它部分讨论实体集合。第 1 节讨论问题上下文和需要在不同的系统间进行信息整合的情况。第 2 节讨论能用来实现实质集合解决方案的各种不同的解决模型。第 3 节涵盖了解决方案架构师会遇到的一些关键的设计问题。第 4 节涵盖了能用来建立EA解决方案的微软公司技术。

　　注意：在本文中，服务和系统都表示包括ERP系统在内的各种商业应用。可以把一个商业应用程序当做一个提供商业服务给企业IT的软件系统。

　　本文为以下读者准备：拥有企业架构规范的IT架构师；需要在企业层次加强组织政策的商业程序拥有者；而且想要建立EA解决的技术架构师。

　　实体集合

　　在不同的系统间进行实体的集合本质上有三个理由。 如下：

• 　　实体的单一视图—— 对所有分布在企业系统里的普通实体做一个“360度”的视图，对商业用户有附加的好处。举例来说，客户实体的统一视图，名叫客户信息容器 (CIR)，是在许多企业中建立有效的解决方案时所必须的，尤其在银行业部门中。
• 　　水平划分——有实体信息分布在不同服务中的情况，基于例如地理边界等一些要素。
• 　　交叉结合的场景——这些情况需要在不同服务中的实体间交叉结合。
• 　　将实体集合的原因在下面会有更详细的讨论。另外，实体集合的目的和影响会进一步阐释。

　　实体的单一视图

　　今天的企业IT的信息本质上是“非整合的”。时常有不同的系统定义商业观念（比如客户）。举例来说, 一个人力资源管理系统 (HRMS) 程序，薪资帐册程序和收益程序分开的定义一个职员实体，在系统之间造成不谐和。结果，趋势应该是通过维护一个统一视图来加强系统间的一致性。该视图关注总体而不是局部1。在构建职员自助式服务入口时，整体视图而不是一个点或块的情况，对职员是必需的。

　　图 1 表示一个定义在企业资源规划（ERP）系统中和客户关系管理（CRM）系统中的客户实体。在这二个系统的顶端，如此的自助服务类型程序能同对客户的整体视图一起构建。

图 1 实体的统一视图

　　水平划分

　　有因地理的限制而需要在服务间划分实体的情形。在特定的时候，解决方案可能需要一整组的信息以获得服务的详细情况。图2示例了一个划分的例子。可以把股票贸易当做一个跨过各种不同的地理位置的被区分的实体。

图 2 实体划分

　　实体交叉查询

　　一些情形需要对实体的特别处理。在这些情况下，不同的服务封装到相关的实体，而且解决方案需要在他们之间的做一个复杂的接合。尝试在服务边界实现接合操作是典型的不推荐的，因为性能降低。为了获得适当的性能，相关的实体需要被带到一个一般的地方——最好是一个关系数据库管理系统(RDBMS)数据库——这里可以实现高效的接合。

　　图 3 举例说明零售业的情节。 因为详细目录系统储存着产品目录，订单管理系统储存着订单数据，所以解决方案包括一个接合处。当存货需要再补足的时候，零售解决方案有一个场景将会帮助他们的商业分析者做出何时补足存货的决定。 解决方案将会首先需要一项包括订单实体和产品目录实体的数据的综合分析。

 
图 3 实体交叉查询

　　实体集合服务

　　实体集合服务的目标是设计一个实体集合层，它可以访问存在于多种系统里的信息。实体集合服务有下列的职责：

• 　　作为一个统一的实体来源。
• 　　提供一个实体的整体视图。
• 　　提供一个实体模型的整体视图——实体和它自身与其他实体的关系。
• 　　提供位置透明——实体集合合层的用户不需要知道谁拥有信息。
• 　　加强商业规则，用以确定给定的上下文中取回的实体片段。
• 　　为构成一个实体的每种数据元素决定记录系统。
• 　　丰富系统间的组合数据模型——整体比部件的集合要好。

　　为了支持这些职责，一个EA服务需要关于实体的资讯, 像是实体的结构，包含实体的服务，所有权信息，实体的服务视图。这数据能被储存为元数据。图4解释实体集合服务：

图 4 实体集合服务

　　解决模型

　　当计划一个实体集合服务的时候，这一个部分阐述了可能的解决模型。 实体的整体视图，由实体集合服务提供对它的用户，通过直接完全处理(STP)方式或应答方式来实现。

　　直接完全处理

　　直接完全处理方法从适当的服务中实时地获取信息，将信息关联进一个整体视图。这暗示实体集合服务和服务间具有实时连接性。除此之外，一个EA服务获取来自不同服务的实体的信息的机制能通常被做成一个自动过程计划模型。 在这一种情形中，EA服务应该能够联合来自不同的系统的实体。

　　应答

　　在这一个机制中， EA服务应答实体。 当服务的实时连接性失去的时候，该方式尤为需要。需要实体间的一个复杂的接合处，或者，性能是解决方案的主要驱动力。

　　这一个机制应该提供跨实体服务边界应答实体的功能。基于服务的应答机制可以代替基于数据库的应答机制。基于服务的应答使得EA服务和遗留服务间实现松散的耦合。举例来说，如果遗留服务改变了实体的根本表现，因为应答机制在以服务为基础的方式上被建立，它将不影响 EA 服务。

　　局部应答模型

　　有的情形不需要应答关于一个实体的所有信息。举例来说，有普遍使用的属性为了较快速的性能被应答的情节，而且访问其他属性都使用STP机制。

　　数据库应答的限制

　　以数据库为基础的应答的问题是EA服务的和遗留服务的数据模型应该被排列整齐并且紧紧的连接在一起。依靠现有的遗留服务的数据模型是不可取的，因为当遗留系统升级后，或重写后，又或被其他系统代替后，就有可能导致数据模型的业务流程再设计。除此之外，当从多个信息源组合一条信息时，应答方案一般会出现问题。

　　设计问题

　　当计划一个实体集合服务的时候，一些设计考虑需要选择。一个实体集合服务应该仔细设计，使它集合的实体间有效的联系，高效的在多个实体间查询。其他的设计考虑包括下列各项：

• 　　架构调整
• 　　所有权断定
• 　　实例调整
• 　　CRUD语义
• 　　生存周期问题
• 　　架构调整

　　不同的服务不只是有对实体的不同视图，他们也可能有他们自己的视图架构。为了要达成一个实体的统一的视图，EA服务协调不同服务间的架构是必要的。为了做这个，EA服务应该首先知道每个服务如何表现一个实体。另外地， EA服务应该合乎逻辑地联合各种不同的视图以定义整体视图。同等重要的是，给EA服务找到一个方法来表现在一个实体的服务视图和整体视图之间的转换。下图表示在多个服务中的客户信息。

图 5 架构调整

　　在图 5 中，EA服务创建了一个统一的架构，包含对客户实体的整体表现所必需的所有属性。Service1和Service2都定义了他们自己的客户实体视图。EA服务也定义了在个别的服务视图和统一架构的映射。

　　在水平划分场景下，架构调整通常不是一个问题，因为服务分享相同的架构。

　　架构表示

　　表示实体视图有很多选择，包括XML——架构表示，实体——系模型，和对象模型。

　　可扩展标示语言（XML）——架构是表现一个实体的一个流行的方法,如同它是平台中立者一样。 XML——架构以一非常天然的方式取得实体的定义。他也支持牵制类型的概念还有多值属性。如果XML——架构被用作实体表现, 然后扩展的样式转换语言（XSLT)能用来表现在二个不同的视图之间的转换。

　　虽然XML—架构是一个保存企业广泛逻辑模型的平台中立的方法，独立的服务也是很好的办法，来使ER模型和对象模型来保存各自的数据。

　　参考

　　实体参考引用信息必需要唯一的识别一个实体实例。 每个服务可能维持一个或更多个关于一个实体实例的唯一参考。 参考类似数据库表的主要钥匙。在一些情形中，实体有唯一的，全面验证过的钥匙，像是人的社会安全号码或一个组织的DUNS数字。要知道，甚至唯一的外部标识符可用在一个实体中，系统仍然时常使用另外的内在标识符确定对内在的数据一致性的完全控制。期待如此的情形，一个EA服务应该能够将参考映射到一个单一实例。

　　除了由其他服务掌握参考，一个EA服务能产生并且维持它自己的参考（作为主参考），还可以将该参考映射到一个独立系统参考上。因为新系统可以在不影响EA参考的情况下加入，这就降低了EA服务和独立系统的耦合性。目前，许多解决方案都沿用此方法。

　　主参考

　　通过使用一个叫做主参考的参考，一个实体集合服务可以唯一的识别一个实体实例。有两种方法可以设定主参考：

　　可以是一个系统持有的参考。例如，可以赋予客户实体一个主参考，该参考由CRM系统持有。
实体集合服务可以创建新的主参考，并将其映射到其他系统持有的其他参考。在分离的情节情况中这非常有用，在较后的部分中讨论。
所有权断定

　　不同的服务拥有实体的不同部分是有可能的。考虑职员实体的情形；薪水系统拥有一个职员实体的一些属性，比如说薪信息。同样地，一个收益系统拥有职员的收益信息。许多系统拥有相同的信息也是可能的。举例来说，比如姓和名这样的属性就可能出现在许多系统中。 而且，这些属性的值在所有的实例中不可能都是相同的。在这情况下，EA服务应该为其指定如“权威来源”的一个服务。

　　有一个“权威的来源”对“创建——读——更新——删除”（CRUD）有意义。举例来说，属性将总是从权威来源中得到。如果另外的一个系统中有相同的属性，那些属性值将会被EA服务忽略。

　　更新有不同的语意。当EA服务接受一个实体的一个更新请求的时候，更新应该传播到所有的拥有者。

　　所有权优先

　　有些情况下，一个属性的值不是来自权威来源中，该值应该从一个替换的来源中取来。为了要适应这一个情境，所有权优先可以这样定义：每个服务被分配一个优先级——高的级别意味着高的优先水平。

　　水平划分的所有权断定

　　在水平划分的情况，实体实例以实体属性的数目为基础来划分。举例来说，假设次序实体跨过两个服务水平地被划分，基于地理位置，比如说纽约和伦敦。在这情况下，决定实体例证的所有权的表述会看起来像下列各项这样：

以下是引用片段： 　　Predicate for Service1 = <Location = ‘NY’> Predicate for Service2 = <Location = ‘London’>

　　符号

　　本节讨论可以实体集合中表示各类东西的符号。

　　实体视图

　　不同的服务有他们各自的对某一实体的视图。推荐实体视图与定义视图的服务一起取得资格。下列的表示法能用来指示实体视图：

　

以下是引用片段： 　<ServiceName>.<EntityName> Example: CRM.Customer

　　ServiceName 表示服务的名字，而且EntityName指实体的名字。举例来说，CRM.Customer指CRM系统对这个实体的视图。

　　实体视图架构表示法

　　实体视图被描述为一组属性。一个属性可能是单值的或多值的。以一个订货实体来举例说。它有一个叫LineItem的多值属性。另外地，一个属性可能是参考的一部份。下面是一个例子：

以下是引用片段： Entity View = <attrib1, attrib2, attrib3>  Attribute = attribute name(Single/Multi-valued, Reference) (Default is single)  Example: CRM.Customer = <CustID(Ref), LastName, FirstName, TelNos(Multiple)>

　　注意EA服务的对一个实体的整体视图是一个“特别的”视图。除了定义视图之外，EA服务也应该有关于个体维修在一个实体上的把握叁考的资讯。 这可能被定义为下列各项：

以下是引用片段： Ref<Entity> = { <Service, References> } Example: Ref(Customer) = { <ERP, ERPCustID>, <CRM, CRMCustID> }

　　实例调配

　　为了提供一个实体的统一视图，EA服务需要能够将一个服务中一个实体的实例关联到另一个服务中的实例。有许多方法可以实现这种关联。举例来说，可以通过基于一些匹配断言来实现实体实例间的匹配。

　　匹配断言

　　匹配断言是将一个系统中的实例映射到另一个系统中去的一种表示方法。考虑这样的情况，在ERP和CRM系统表示一个客户实例。他们各自的视图如下所示：

以下是引用片段： ERP.Customer = <ERPCustID(Ref), LastName, FirstName, Address, SocSecID, Email addr, …>  CRM.Customer = <CRMCustID(Ref), LastName, FirstName, SSID,…>

　　ERP系统和CRM系统都使用相同的属性——ERPCustID 和 CRMCustID来识别他们的系统中的一个客户。如果两者的参考对所有的实例都有相同的值，匹配断言可以像如下定义：

以下是引用片段： <ERP.Customer.ERPCustID = CRM.Customer.CRMCustID>.

　　然而，参考的值不可能总是相同的。在这些情况，一些其他的属性或属性的组合能用来定义匹配断言。举例来说，一个社会安全号码能用来将ERP系统中的实例映射到CRM系统中的实例中。下面的一个例子表示了一个匹配断言：

以下是引用片段： <ERP.Customer.SocSecID = CRM.Customer.SSID>

　　匹配断言可能是包括超过一个字段的一个逻辑表达式。 同时，对匹配断言能够有效地在系统之间工作来说，在实体实例之间的一对一的关系是一个基本的需求。

　　没有匹配断言也可以解决问题。举例来说，不同的视图间可能有一个共同的字段，不同的系统可能不分享钥匙。这些情况下需要人工的映射相关信息。

　　关系图表

　　一个图表能表示一组匹配断言。在这张图中，节点代表服务，边代表实体视图间的关系（即关系断言）。考虑在三个不同的系统——像是 HRMS，薪水和利益系统中表示职员实体的一个例子：

以下是引用片段： HRMS.Employee =  <HRMSEmpID(Ref), LastName, FirstName, Address, SocSecID, Position, …>  Payroll.Employee = <EmpID(Ref), LastName, FirstName, SSID, Bank Information …>  Benefits.Employee = <EmpID(Ref), LastName, FirstName, SSID, 401k Info, Medical InsuranceInfo …>  Match predicates Payroll.Employee.SSID  = HRMS.Employee.SocSecID Benefits.Employee.EmpID = Payroll.Employee.EmpID

　　上面相同的数据如下图所示。

图 6 双向图

　　一个有特定的终点的双向连接的的双向图意味着关联是自动完成的，没有人工的帮忙；如果图没有完全连接起来，它意谓着集合不能够自动完成。这种情况下，专业人士的人工干涉是必需的，比如一个商业分析师或数据库架构师。

　　注意对理解以属性为基础来获取实体实例的相关信息的过程，针对图表的静态分析将会有帮助。

　　识别匹配断言

　　识别匹配断言需要对不同系统减包含该实体信息的数据进行深度分析。使用以属性的名字为基础的推论是一个不可靠的方法，因此不推荐。直到有底层数据(名字，前缀，住址, 等等)的标准化，提高建立可行的匹配断言的机会必需使用其他的方法。

　　通常，IT组和商业代表共同努力，可以成功识别匹配断言。大部份的情形下，只有商业分析师和数据库架构师可以成功的识别正确的匹配断言。

　　表现实例关系

　　为了更新不同系统的一个实体例证，一个EA服务需要每个服务持有的实体实例的参考。为了更新一个实体实例，一个EA服务可能需要明确地储存参考数据。

　　也有许多情形下参考不需要明确储存。STP解决模型中，参考在不同的系统中共享，这种情况下，明确地储存参考数据是不必要的。然而，如果解决模型要复制数据，那么EA服务必须持久稳固的储存关于实体实例的参考。

　　CRUD语义

　　这一个部分从实体集合服务的观点来讨论创建——读取——更新——删除(CRUD)语义学。 CRUD解决同STP解决模型和回答解决模型是不同的。

　　直接完全处理

　　读取

　　读取请求本质上是一个基于属性的搜索。例如，从一个遗留系统中获取一个实体实例，调用者起码要提供一个属性，比如一个参考（钥匙），或是姓氏。为了找到一个实体实例，EA服务应该基于输入的属性从不同的服务中获取该实例的适当的视图，然后将这些视图集合起来。这是一个预定的过程，包括从独立的服务中获取信息，然后将其集合起来。

　　下面的例子举例说明了这是怎样工作的。这个例子显示了在HRMS，薪水（Payroll）和收益（Benefits）系统中是如何表示一个雇员实体的。

以下是引用片段： HRMS.Employee =  <EmpID(Ref), LastName, FirstName, Address, SocSecID, Position, …>  Payroll.Employee = <EmpID(Ref), LastName, FirstName, SSID, Bank Information …>  Benefits.Employee = <EmpID(Ref), LastName, FirstName, SSID, 401k Info, Medical InsuranceInfo …>  Match predicates Payroll.Employee.EmpID  = HRMS.Employee.EmpID Benefits.Employee.EmpID = Payroll.Employee.EmpID

　　由上面例子中的匹配断言，可以看到三个系统都共享相同的参考数据。图10中描述了如何基于一个EmpID属性来获取一个雇员实例的过程。

图 7 读取过程

　　因为参考在三个系统中共享，可以从所有系统同时获取数据。一旦结果被取到，来自三个系统的数据被集合起来。集合过程包括将从遗留系统中取得的数据进行转换，然后映射到一个整体视图。

　　有时并不是所有的系统都共享相同的参考。下面的例子阐释了这个场景：

以下是引用片段： HRMS.Employee = <HRMSEmpID(Ref), LastName, FirstName, Address, SocSecID, Position, …>  Payroll.Employee = <EmpID(Ref), LastName, FirstName, SSID, Bank Information …>  Benefits.Employee = <EmpID(Ref), LastName, FirstName, SSID, 401k Info, Medical InsuranceInfo …>  Match predicates Payroll.Employee.SocSecID = HRMS.Employee.SSID  Benefits.Employee.EmpID = Payroll.Employee.EmpID

　　本例中，薪水和收益系统仍然共享相同的参考。然而,HRMS维持它自己的参考。从HRMS到薪水系统匹配一个实例的唯一方法是在两者的视图中都使用那社会安全号码属性。图12展示了这个过程：

图 8 不同匹配断言的读取过程

　　这个查询的过程跟先前描述的过程看起来十分不同，先前的过程中三个系统共享相同的参考信息。另外注意到这个过程中的步骤是连续的。

　　注意“由于查询属性，匹配断言和所有权信息不通，过程的结构也不同”

　　过程的自动生成

　　在不工作时，或是在设计时，通过使用匹配断言，关系图，参考属性和所有权信息，自动生成过程是可能实现的。

　　下面的伪代码解释了一个用于搜索条件的机制，该搜索条件包含一个属性。也可以将它修改，以用于基于多种属性的搜索条件。典型的，查找程序将搜索条件视为一个参量，而且它将返回一个实体的实例，以该实例的整体形式。

　　这个算法中的第一步是找到用在这个搜索条件中的属性的所有者。一旦所有者被确定，就在关系统中执行一个修改深度优先搜索：

以下是引用片段： EA_DFSVisit(node, searchcriteria, instance of holisticview) Begin If node is visited, then return Fetch information from the service based on the search criteria Populate the appropriate fields in the holistic view Node.visited = true //Execute the following loop in parallel. For each child node connected to this node  Begin    Find the match predicate along the edge connecting the node    and child node.    Identify the attributes involved in the match predicate.    Form a new search criteria based on these attributes    and the values for the attributes previously fetched.    EA_DFSVisit(childnode, new criteria, holisticview) end end

　　该算法在某些情况下可以优化。举例来说，如果所有的系统都支持用在搜索条件中的属性，那么数据可以简单的从不同系统并行的取道。在设计时创建预定的过程可以遵循相同的算法。

　　更新

　　更新一个实体实例也可以被模拟成一个预定的过程，过程中的每一个行为都向相关的服务发送一个更新请求。跟读取机制相似，有好多种方法来设计更新进度表。

　　更新请求通常包含二种元素：可唯一识别实例的参考，和一个更新负荷，该负荷需包含有更新属性和属性值的信息。进度表的结构将会是不同的，基于参考属性。类似读取机制，基于参考属性，匹配断言，所有权信息和关系图生成一个进度表是完全可能的。

　　补偿

　　如果有一个服务无法处理更新请求，那么EA服务应该能够处理这个异常。处理意外的机制包括一个为之前的行为进行补偿的流程。

　　商业分析师经常来决定补偿逻辑。补偿逻辑可以是自动或手动的。例如，当一个服务返回一个异常时，补偿行为应该给监测设备发送信号，然后寻求手动解决。

　　选择需要更新的服务

　　有些情况下所有服务的更新请求并不需要。例如，有些商业过程适当接受一些在HRMS或其他系统中的雇员实体的更新记录是可能的。这些情况下，EA服务应该发送一个更新请求到HRMS系统中，而不是所有三个系统中。在引入新的过程前，更新服务中存在的过程必须仔细考虑。这种方法同样应用在创建和删除操作中。

　　也有些情况更新操作需要人工干预。在这些情况下执行更新操作同时包括人工流程和自动进度两种机制。

　　创建和删除

　　如同更新请求，创建和删除请求也可以被模拟成一个预定的过程。创建和删除请求过程也跟补偿原则相关。

　　直接完全处理的局限性

　　STP 的限制包括返回超过一个实例的搜索。使用STP返回一组实例同在表中做数据库合并是相似的，这种情况下只需要在服务边界做合并。

　　当视图间的合并变得更复杂的时候，实现 STP 解决的困难增加。如果解决方案需要查询返回一系列实例，因此，考虑使用一个应答模型代替STP模型。

　　即使当要获取一个单一实例时，有些情形下STP也是不适用的。当查询基于多个属性时，而且那些属性被不同服务拥有的时候，这一种情形可能发生。再一次，一个数据库合并操作是需要定位满足标准的实例。

　　复制模型

　　在一个复制模型中，一个EA服务维持实体例证的地方副本。当缺少服务间的实时连通性，保证高性能，或在跨越服务的一个实体的多个实例间做复杂的结合的时候，尤其需要复制模型。

　　复制模型的执行需要EA服务来维护一个实体实例的拷贝，以其整体形式，还有一份由参与的服务所持有的参考的拷贝。

　　操作模型

　　EA服务可被配置成能够在两种模式下工作：只读模式和读写模式。这种配置设置在实体级别。有了几个特定的实体，EA服务就可以工作在只读模式下，有其它的实体，也可以工作在读写模式下。注意，读写模式同多个所有者的场景类似。

　　针对复制模型的EA服务的架构如图13所示。EA服务提供CRUD服务给它的用户。它也有一个本地存储，包含了实体的副本和每个服务所持有的对某一个特定实体实例的参考列表。为了生存周期管理，需要使用一个快照处理器和同步部件。这些问题在下一部分讨论。

图 13 复制模 ——架构

　　本节其余的部分为复制模型检查CRUD语义。几个部分——包括生存周期问题，操作问题，快照问题——都被检查。

　　读取操作

　　从复制模型中取出一个实体实例就像从本地存储中取出实例的数据来一样简单。

　　创建

　　读操作在本地复制中创建一个实例，同时发送一个信息到同步引擎。晚一点，新创建的实体的参考在同步期间被更新。

　　注意直到所有的参考都被收到，才可以在一个实体实例上进行更新或删除操作。知道创建操作在只读模式和读写模式下工作状态是不同的非常重要。

　　创建新实体有时候是准备过程的一部分。比如说，准备一个新雇员的过程中的一部分就是创建一个雇员实例。

　　更新和删除

　　更新删除操作同创建操作是十分相似的。该两个操作从本地副本中更新删除相关合适的实例，然后发送一条更新和删除信息到同步引擎，确保同步。

　　生存周期问题

　　实体例证的生活周期包括二个阶段，供给状态和同步状态。 和关于实体的装备议题的供给状态交易为 EA 服务消费者引以为例。 同步逐步运行有在 EA 之间的复制品的关于同步的议题交易服务和拥有者服务。

　　注意在直接完全处理模型中没有生存周期问题，但是设计复制模型时会遇到。这一节的其它部分讨论复制模型和生存周期相关问题。

　　预备

　　在两个独立的时间段会有预备工作，一个是步步为营的阶段。这是当EA服务的副本需要同个体服务的拷贝协调一致的时候，通过EA服务或独立服务创建了一个实体实例的时候。

　　步步为营

　　在一个实体被设置成使用复制解决模型后，EA服务应该能够获得副本，从拥有它们的服务中。快照能用来获得这些副本。快照的观念被数据库复制组件应用，在基于服务的复制中也有应用。

　　申请初始快照

　　个体服务发布实体视图的快照。EA服务首先使用该发布的快照，然后处理他们，而且更新本地副本和参考。这一个程序与传统的用在数据仓库存储环境中的提取——转换——加载(ETL)机制类此。图14举例说明快照处理：

图 10 快照处理

　　快照格式

　　实现快照的设计考虑是选择正确的快照格式。这很重要，尤其是实体有很多的实例时。有一些快照格式可以选择：

• 　　可扩展标示语言(XML)数据集——这是为其它服务发布快照的一个自然的格式。根据使用的编码机制，快照可能变的很大。所以，经常使用二进制编码。
• 　　CP 格式——这是在数据库中进行大量上载时使用的格式。数据库格式对基于服务的复制不是一个理想的机制。内部数据库表示法应该对EA服务可见。
• 　　定制格式——一个例子是逗点分割格式（Comma Separated Format，CSV）

　　快照传递

　　一旦快照被发布，不仅EA服务可以取回快照，而且发布者也能把快照推送给EA服务。基于比如快照大小或传送限制等一些参数，适用不同的传送器。可以使用基于网络服务的机制（Web—service）。如果快照非常大，可以使用FTP传送。

　　基于推送的传递可以使用Web服务发布快照来实现，在这种情况下，服务所有者应该为快照的取回实现服务接口。

　　快照处理

　　有许多不同的方法执行快照处理。

　　举例来说，EA服务能等到接受完来自不同服务的所有快照后然后一起处理他们。或者，EA服务可选择在每个快照到达时就处理。快照的处理跟应用在数据仓库里的ETL处理方法相似。

　　创建新实例

　　在系统中创建一个雇员实例将触发一个过程，该过程在不同的系统间创建一个雇员实例。这是一个典型的供应过程。一个实例被创建，通过EA服务或是一个个体服务。

　　通过EA服务创建实例

　　当通过EA服务创建实例时，本地副本进行更新，同时将创建一条消息并发送到同步引擎。该同步引擎负责将创建的消息传播到所属的服务。

　　通过所属服务创建实例

　　有些情况下直接在遗留系统里创建实例。例如，HRMS用户在HRMS系统中创建雇员记录。所属服务不仅要明了创建的记录，还要发送一个商业事件，包含新创建的实例和其参考的信息。再一次，同步引擎负责处理这些生成的商业事件。

　　许多情况下，在EA服务接受到关于该实例的信息后，一个实例被准备出来。EA服务有一个实体实例的参考，可以执行更新或删除操作。有些情况下部分准备的实体也是可以接受的。

　　同步

　　同步引擎负责在EA的副本和所属服务持有的拷贝间进行同步。同步引擎结合了下列部件：EA服务的CRUD部分，包含副本和参考的本地存储，和所属服务。

　　本节剩下的部分处理同步引擎和不同部分的交互作用，还有通过交互作用来交换消息的处理机制。

　　CRUD部分和同步引擎的交互作用

　　当一个CRUD部件收到创建/更新/删除的请求（CUD），他们更新本地存储，发送CUD消息到同步引擎。这个交互作用本质上是单向的。这个执行过程包括将请求排队的发送器，接收请求并进行处理的接收器。在发送器和接收器间需要有保证的传送。图15展示了CRUD部件，同步引擎和本地存储间的交互作用。

图 11 CRUD和同步引擎间的交互作用

　　当一个CRUD请求被接受到，CRUD部件首先判断操作模式是否是读写的。如果是，CRUD部件更新本地拷贝，将告知同步引擎的变更通知排队。建议把图11中第2步和第3步作为原子事务来执行。另外的，变更通知有可能没有发送出去，即使本地拷贝已经被更新过了。

　　同步引擎和所属服务的交互作用

　　在同步引擎和所属服务间交换更新通知来在同步间保存副本。变更通知流向两个方向。例如，当EA服务更新一个实体实例时，同步引擎发送一个变更通知到所属服务。服务然后更新他们的本地存储，或者他们可以返回一个冲突的通知。类似的，有实体实例直接通过服务来更新的情况。服务发送变更通知消息到同步引擎。

　　来自EA服务的更新

　　从一个CRUD部件收到一个创建通知消息，同步引擎确定所属服务，然后将一个整体视图转换成所有者视图，发送一个创建消息到所有者。所有者必须返回一个消息，包含刚创建的实例的参考的信息，或是一个事件异常。在这一点上，同步引擎使用这个包含参考信息的返回消息来更新这个参考地图。

　　注意因为执行的操作的类型（比如创建，更新，删除）不同，同步机制也不同。

　　图12中的表格展示了描述过的步骤的顺序。

图 12 同步引擎和所属服务间的交互作用

　　在同步引擎和所属服务间的交互作用不一定要是请求——回馈形式的。有些情况下，所有的消息自然同步，所有的回馈返回的时间都不一样。比如说，设想一下，所属服务不在线，接收回应的唯一途径是通过某些批处理机制。同样，同步引擎应该支持成批发送的模式，一批变更通知可以被发送到所属服务中去。

　　更新请求的处理有些许不同。更新过本地副本后，CRUD部件将更新请求排队到同步引擎。有许多方法来定义更新请求的结构：

• 　　包含所有属性的旧值和新值的更新请求。
• 　　仅包含更改过的属性的旧值和新值的更新请求。
• 　　包含变更过的属性和实体实例的版本信息的更新请求。

　　同步引擎处理通过识别更新过的属性和其所有者来处理更新请求。对每个所有者来说，同步引擎为所属服务识别实体实例来创建一个有合适参考的更新请求。所属服务然后返回一个成功或失败的消息。为了结构更新的冲突，可以使用标准的冲突解决方法。见图13。

图 13 冲突解决

　　注意处理删除请求和处理更新请求是十分类似的。

　　来自所有服务的更新

　　这个部分讨论了来自所属服务的更新的处理。这个例子中，在所属服务中执行CRUD操作。EA服务负责保证副本同步。本质上有两个机制，推和拉，可以实现这个处理。

　　在推的机制中，当新实例被创建时，或一个实例被更新或删除时，所属服务发布事件。同步引擎预定该事件，更新其本地拷贝。不像“推”的机制，在“拉”机制中同步引擎周期性的更新所属服务。同样，通过方法断言可以配置一个时间段。

　　平台支持

　　SQL服务器分布式查询技术

　　分布式的查询从多许多种不同种类的数据源中访问数据，这些数据源可能存储在同一个或不同的电脑上。Microsoft? SQL Server? 2000支持分布式的查询，通过适用OLE DB，一个针对数据访问的微软标准的API。

　　分布式的查询提供SQL服务器用户对分布的数据的访问，这些数据存在SQL服务器的许多实例中，不同的数据存在不同的相关的或不相关的数据源中，通过使用OLE DB提供者来访问。

　　OLE DB提供者以一种叫做rowsets的表格对象公开数据。SQL Server 2000允许rowsets 以Transact-SQL表述引用，如果他们是SQL服务器表。这个技术可以用来建立一个STP解决方案。这个技术的不利方面是双重的，但是：

　　不依赖其他系统，发展遗留系统时，会出现问题。因为实体集合服务应该知道这个服务的内部数据库架构。

　　仅仅允许直接完全处理。这暗示了遗留系统必须随时可用。

　　BizTalk控制

　　聚合数据的过程使用STP从多个遗留系统中获取和关联数据。BizTalk技术提供了一个设计工具来可视化的设计这些过程。“进度表”被编译成一个叫做XLANG的过程语言。BizTalk同时提供一个运行时可以来执行这个进度表。当然，这个工具也有一些限制。比如说，仅仅支持STP解决模型。另外，对从多个服务中集合数据来说，这不是一个建模工具。BizTalk是以过程为中心的，而实体集合是以数据为中心的。

　　数据转换服务

　　Microsoft? SQL Server? Data Transformation Services (DTS)是一些列图形工具和可编程的对象，你可以从不同的数据源中提取，转换，加固数据到单一或多个目的地。

　　DTS也能被用在STP模型中。在STP模型里，DTS 能在供给状态期间被用做匹配不同的服务中的实例，而且在EA服务中上传映射表。

　　在应答解决模型中，DTS能在供给状态期间被用做申请最初的快照和更新参考映射表。

　　结论

　　在企业中实行SOA时，实体集合是架构师遇到的一个主要问题。在本文中，我们介绍了实体集合的概念，需要实体集合的场景，还有可以用来实现一个实体集合解决方案的不同的解决模型。我们还讨论了在实现实体集合时遇到的一些设计问题，以及解决这些问题的方法。