基于应用范围

　　作为一种帮助企业面对更新现有系统需求的方法，企业应用集成的概念应运而生。现在，企业拥有大量前台应用系统，因此需要集成这些类似的系统，通过不同的方式处理、打包并提出同样的数据。

　　基于应用服务范围允许一个特定系统提供分组服务。这种方法使得管理和维持服务更加容易，因为一个领域内的系统对所有的服务都是一样的。

　　在上面的例子中，SAP，Siebel，PeopleSoft，IBM DB2与Oracle都是很好的基于应用范围的客户。这些范围中的一些典型服务列在下面。

　　SAP

　　·账户支付—帐目核对

　　·财政计算

　　PeopleSoft

　　·增加雇员

　　·更新补偿

　　Oracle

　　·数据复制

　　·基于账户信息的角色说明

　　服务打包

　　挑战

　　在SOA中，一个企业系统必须功能以服务为主。方便集成的构造系统可以很容易的做到这一点。面向结构的系统有一些困难。是一些集成电路应用构造了这些系统，系统包括了所有的商业规则与过程逻辑。这些信息被分配给多个多个连接程序的集合。

　　一个SOA支持独立的服务—没有任何其它服务的相关知识。结构化程序与特定上下文紧密联系在一起。这些结构化程序如何被再次打包围独立的服务？

　　方法

　　我们可以使用一个共有三个步骤地方法来应对这个挑战。这个方法包括在架构方案中定义逻辑商业领域、为这些商业领域分配程序集、并使两个程序集之间松耦合关联。这些步骤在下面详细说明：

　　·商业领域定义. 在这个步骤中，我们建立商业功能的逻辑域。我们可以使用程序调用规划图和过程流图来定义这些商业领域。我们也可以通过调节架构系统的程序间的关系来定义商业领域。[架构系统的程序往往是与其它程序有关。在这种程序到程序的关系中，有一些通用的商业方法。]

　　·程序分配. 在标准的商业领域，我们分配独立的程序到一个特定的领域。我们非常需要再分配那些没有讲自己关联到对应商业领域的程序，使在特定商业领域内排列更有规则。在前面讨论过的服务范围概念的引导下，这样一组程序集可以排列的更好。

　　·松耦合关联. 在这一点上，甚至即使这些程序已经在标准商业领域内排列过了，她们海狮需要彼此间相互关联。在最后这一步骤中，我们将原来的轻度耦合关联替换为一个更加松散的耦合。为了这样做，我们重新定义架构程序界面，这样其它的应用可以调节自己；程序提供同样输出并且接受同样输入，就像它们开始做的那样。这个重定义过程提供了一个非常好的机会来确保这些程序就像一个整体来服务企业，而不是单个程序独立服务企业—就像它们开始被创建时那样。这个方法同时也使现有架构系统朝着面向服务方向靠近，配置他们使它们在内部是结构系统，外部对服务用户来说是面向服务的。

　　服务协调

　　一个特定服务的存在是因为至少有一个服务消费者发出了这项服务的请求。然而，在一些情况下，一个服务不得不调用许多其它服务来满足服务消费者的原始请求。简单的情况导致一个特定服务扩展原始请求到一个或者更多其它服务上。然而，复杂的情况可以导致大量服务的递归调用，在一些极端的例子里，一些服务的内部依赖调用—可以导致死循环。

　　这里有一个例子。当一张机票被出售时，下面的服务需要被执行：

　　取得消费者

　　取得日程表

　　检查可用信息

　　提供费用
　
　　接受支付

　　构建协调能力使得每一服务在如此复杂情况下都能顺利执行

　　如图7所示。

　　图7 . 服务协调挑战

　　这些综合服务如何被协调？

　　商业过程管理方法

　　这种方法使独立的服务更简单：这些服务没有能力来协调其它为了满足请求而调用的服务。

　　替代性的，这种能力被放置于商业过程层。商业过程负责调用每一个子服务，这样来提供组合服务来满足消费者的原始请求。商业过程就成为一个组成服务的专业例子。

　　图8 . 商业过程管理方法

　　图8说明了这张机票购买的商业过程，包括每一个独立执行的逻辑步骤。这个商业过程通过一个简单的访问来查找服务，然后按顺序协调为适当步骤。

　　服务发送

　　挑战

　　SOA还要提供对消费者的地域透明性：服务消费者必须能够在任意服务范围内发送任意服务的请求。同时，在调用一个服务前访问服务库是一个减少时间的步骤。这些架构在保证可接受的系统性能水平的同时，如何提供地域透明性？

　　方法

　　我们能够用两种方法解决服务发送挑战。

　　智能服务

　　使用这种方法，我们为所有的服务建造各自的地域信息。这就消除了一些跳跃性的请求同时也导致了服务重载。考虑到服务以及服务所在场所的更新频率，这种方法有着持久性。另外，这种方法并不与松耦合的服务架构时刻一致。不过，他支持一个更高层次执行的解决方案。

　　发送

　　另一种方法是智能的移动将发送从一个发送组件移动到独立的服务。这些发送组件可以在两种层次：服务域和服务。

　　·服务域发送. 一个服务域发送在所有服务域的场所上是智能的。当接收到一个请求，它确定是否它能够仅靠自己支持的服务来满足这个请求。如果能，它处理这个请求。如果不能，它将这个请求传送到正确的可以满足这个请求的服务范围。

　　·服务发送. 一个服务发送在一个服务范围内被调用，在域内将请求发送到正确的服务。只有哪些可以在域内满足服务的请求被传递给服务发送。服务发送减少了各个服务上场所信息的负载。

　　服务域发送和服务发送对那些包括一定数量服务的服务域来说更加实用。对那些只有几个的服务，智能服务是一个可行的选择。

　　图9 . 服务域发送和服务发送

　　图9说明了一个域内服务域发送与服务发送的概念。

　　服务管理

　　挑战

　　不管一个企业以何种方式定义服务域，这里有几种哲学与技术上的方法来创建新的服务或修改现存的服务。谁来监控，定义和管理企业内这些对现存服务的改变？

　　方法

　　一个企业可以通过建立一个内部管理体来更有效的应对这个挑战。大量的管理模型都是可能的。下面讨论了一些。

　　中心管理

　　通过中心管理，企业内的管理体从各个服务域和各个没有直接依赖于各个服务域的部分得到说明。也必须从不同的商业部门和一些事件处理专家那里得到说明，这些专家可能在解决方案的关键技术组件上发表看法。中心管理体就像一个服务的删减后的完整回顾，也包括对现存服务的改变，在允许他们执行前。

　　图10 . 中心管理模型

　　如上面图10所示，中心管理体依赖于企业建立与执行SOA时的指导方针与标准。还依赖于通过这些标准与其他商业部门，架构小组和技术小组的交流。

　　分布式管理

　　通过分布式管理，每一个商业部门可以独立控制如何在自身组织内部提供服务。分布式管理要求一种功能性服务领域方法。一个服务架构委员会可以依旧提供高水平的指导方针的标准给服务执行，但是委员会不必批准商业部门内部对现有服务架构的调整。委员会可以建议与指导方针保持一致但不能强迫这样做。

　　图11 . 分布式管理模型

　　如图11 分布式管理模型所示，商业部门A与B都有权利来建立他们自己的独立的标准。然而适当的被动标准（架构和程序标准）都在适当的位置等候部门去遵守。

　　服务通信标准采用

　　挑战

　　对纵向工业来说，通信标准是不同的，这导致了基于一个数据元素集合和通信方式的标准。然而，在一个独立数据元素层次，这些标准是弹性的，企业能够适应它们来与企业特定商业限制保持一致。这样，同一企业内的不同的商业部门可以通过不同方式与统一标准保持一致。另外，这些标准还提供了客户数据元素的创建。

　　举例，IFX标准确定了多种方式对一个顾客：

　　·〈客户唯一标识符〉内部数据库用来唯一标识消费者

　　·〈客户登录标识符〉消费者登录使用的账号

　　两个域都是唯一的。企业采用IFX标准就必须决定使用每个域的时间和地点。有时，消费者甚至决定忽略这两个标识符，自己重新创建一个客户域，这个客户域对企业记录系统更适合！

　　如何使企业选择一个单独的标准成为可能？

　　元数据管理方法

　　企业内元数据库支持关键商业体的可靠描述。这些描述是分布在多个企业系统上信息的扩展集。数据字典也就是逻辑与物理数据模型是元数据库定义和维护的关键输入。

　　元数据管理组在前面讨论过的中心管理模型中应该是一个焦点集中的组。元数据管理必须在企业层次执行。换句话说，即使一个企业选择了分布式管理模型来维护服务，它也必须选择一个中心管理模型来支持元数据。

　　在上面的例子中，消费者的元数据包括一个简单形式的标识符，这个标识符是唯一的。另外，元数据要确保维持管理信息的描述，这些描述包括登录帐号和密码。因此，即使一个企业已经通过一个客户域为消费者选择了唯一标识符，这个客户域也必须在元数据库中被描述。

　　结论

　　像一声春雷，SOA已经被IT界迅速接受，它帮助企业用模块化的方法搭建并部署服务。然而，架构的实际应用需要仔细的规划。感兴趣的企业必须首先确定他们适合长期应用和支持SOA。

　　通过开发并制定一个实现路线图，企业可以预先应对好一系列将遇到的挑战。每个企业都将面对一个独特的挑战集；相应的应对这些挑战的方法也就各自不同。这些挑战的影响—在执行中与执行后—还依赖于这些特定企业的环境。