在SOA中,复合服务是非常重要的一个概念。总体来说,按其复合程度,复合服务可以分为:一般意义上的“简单”复合服务和“工作流类型”的复杂复合服务两种。
一般意义上的“简单”复合服务
这类复合服务就是将已有的一些细粒度的服务重新整理包裹成一个粗粒度的服务。大多数的复合服务都属于此类型。值得深入探讨和研究的是“简单”复合服务的应用场景,这里列举两类典型场景:
场景一:为满足应用集成的需要,在集成多个既有系统的服务基础之上,又实现了一部分“集成逻辑”的服务。例如:假定存在两个独立的系统:销售系统和财物系统,销售系统有合同信息,财务系统有客户的信用信息,假设现在要对两个系统进行集成,希望集成后的系统能根据财务系统中客户信用对销售系统中的合同进行风险评估,将这一功能抽象成一个独立的服务后,我们不难发现,它需要同时调用财务系统的CreditService和销售系统的ContractService,这个服务就是一种典型的复合服务。
这一问题正是通过“复合服务”来解决的,由“复合服务”来协调各既有系统,保证数据的一致性。这就回答了前面提出的“以谁为准”的问题,那就是以这个“复合服务”为准。下图描述了复合服务在此类场景下的应用:

一般意义上的“简单”复合服务
这类复合服务就是将已有的一些细粒度的服务重新整理包裹成一个粗粒度的服务。大多数的复合服务都属于此类型。值得深入探讨和研究的是“简单”复合服务的应用场景,这里列举两类典型场景:
场景一:为满足应用集成的需要,在集成多个既有系统的服务基础之上,又实现了一部分“集成逻辑”的服务。例如:假定存在两个独立的系统:销售系统和财物系统,销售系统有合同信息,财务系统有客户的信用信息,假设现在要对两个系统进行集成,希望集成后的系统能根据财务系统中客户信用对销售系统中的合同进行风险评估,将这一功能抽象成一个独立的服务后,我们不难发现,它需要同时调用财务系统的CreditService和销售系统的ContractService,这个服务就是一种典型的复合服务。
场景二:在某公司的多套遗留系统中都涉及到了“订单”实体,在实现集成后,如果要“增删查改订单”的话,应该如何保证各遗留系统中的订单数据保持一致呢?这在应用集成中是一个非常典型的问题,这个问题也可以表述为:在多个系统中都存在的某个实体,到底应该以谁为准呢?下图是对这一问题的一个形象的描述(以Customer实体为例):

这一问题正是通过“复合服务”来解决的,由“复合服务”来协调各既有系统,保证数据的一致性。这就回答了前面提出的“以谁为准”的问题,那就是以这个“复合服务”为准。下图描述了复合服务在此类场景下的应用:

“工作流类型”的复杂复合服务
本文介绍了SOA架构中复合服务的概念及其应用场景。复合服务分为简单复合服务和工作流类型的复杂复合服务两大类。前者用于集成多个系统的服务并解决数据一致性问题;后者则代表一个业务流程,通常使用BPEL定义。
385

被折叠的 条评论
为什么被折叠?



