【转】在SOA中转换服务角色

  

当某个机构开始推行面向服务的架构计划时，他们经常会在大量数据资源中遇到数据和语义集成的问题。一种应用程序提供的数据表达与另一种应用程序提供的数据表达不匹配是这个艰巨问题的核心内容。

　　当某个机构开始推行面向服务的架构计划时，他们经常会在大量数据资源中遇到数据和语义集成的问题。一种应用程序提供的数据表达与另一种应用程序提供的数据表达不匹配是这个艰巨问题的核心内容。 对 SOA 实施来说，数据集成问题同样非常棘手，因为它会限制服务提供商与消费者之间的 “ 松耦合 ”(loose coupling), 除非有什么有效的途径可以减弱提供商和消费者数据表达间的差异。需要获取来个众多不同资源格式的、大量的、不同类型的信息是语义集成的挑战，是今天的企业、机构、组织必须解决的问题。

　　有效的服务组合需要有效的语义集成

　　有两方面原因使有效的数据和语义集成成为一种挑战：首先，通常信息的表达和信息本身紧密相联 ; 第二，信息经常缺少背景。开发人员经常要考虑的不是数据本身而是这些数据的结构：词汇描述 (schemas) 、数据类型、相关数据库结构、文家格式等等外部结构，这些并不与手头信息直接相关的信息，然而我们认为数据应该是什么样的。

　　此外，公司经常对不同方面的业务采用不同类型的技术，一段时间后，把自己置于对不同的系统进行整合的复杂境地。另外，许多行业容易出现收购和合并，使公司内部成为拥有不同技术的复杂混合体。所以，很少在采用技术方面做统一决定，而差异性使不同的业务部门采用满足自身市场变化需求的产品。因此，公司总是面临着对持续变化着的不同环境进行整合的问题和挑战。

　　解决语义集成问题的困难限制公司快速回应市场变化的能力，所以也就限制了 SOA 提供敏捷业务表现的能力。就坚持标准来说，在一定程度上，松耦合 (loose coupling) 与服务和数据组合之间有交换机制，但是并不能保证交换来的、有独立服务的数据将会被广泛理解、使用。即使当企业机构中使用 XML 这样的元数据标准来规范信息，一种服务的词汇描述还是可能与另一种词汇描述不匹配，或拥有一样含义的字段却使用不同的标签。

　　为了使数据在整个 SOA 架构中畅流无阻，我们必须公开服务提供商和消费者之间数据格式的知识。服务需要有语义含义的数据参与，而不是数据格式。这里的问题就是一种松耦合 (loose coupling) 。尽管我们可能减弱一对应用程序接口间的联系，可是，如果用一样的方式处理数据 ―― 通过在服务消费者身上插入服务提供商的数据结构，结构却可以与之前的方法一样实现紧耦合 (tightly coupled) 。为了兑现无缝数据整合的承诺，我们必须超越对应用程序接口进行的松耦合 (loose coupling) ，另外提供语义层次的松耦合 (loose coupling) 。

　　一种面向服务的数据整合方法

　　如果在服务消费者和服务提供商之间存在语义差异，那么为了克服这些差异，我们需要先完成一些其他工作，为其提供 SOA 架构下要求的松耦合 (loose coupling) 。而一种解决数据整合、面向服务的方法就是使这些数据就像服务提供商和服务消费者之间的中介一样，发挥映射变化的服务性能，使服务提供商和服务消费者不再紧紧盯着数据格式，而是关注数据的语义内涵。

　　使用数据转换服务，通过将服务提供商关心的与服务消费者关心的分开促进松耦合 (loose coupling) 。特定服务的创建者可以全心关注服务的核心功能，而实施面向服务流程的面向服务的业务应用 (Service-Oriented Business Application ， SOBA) 的设计者可以全心关注流程级别设计问题。转换服务使数据转换问题被隔离，使具有转换技术专长的人可以全心地投入开发数据转换程序。这种方法提高了解决方案的可维持性，使组织各部分可以各司其职，各尽其力，使组织可以更有效地使用资源。

　　为了实现某个数据整个目标，当某个应用程序或服务的数据必须从一种格式转换为另一种格式时，最常用、最直接的方法就是直接在应用程序中嵌入数据转换逻辑，具体说明如下所示：

使用嵌入式转换

　　将转换逻辑嵌入到应用程序中是一种成熟的、面向对象的技术，因为在面向对象领域，应用程序将内在逻辑打包，包括转换逻辑。然而，将转换逻辑嵌入到应用程序有明显的缺点：

·                                 　　1. 其他应用程序或服务无法在此使用嵌入式转换。

·                                 　　2. 由于嵌入数据转换，不可能降低 CPU 消耗

·                                 　　3. 在应用程序中转换逻辑与业务逻辑紧密相关，降低了应用程序的灵活性和再利用能力。

·                                 　　4. 转换逻辑直接通过元数据操作，进一步阻碍了应用程序的灵活性。

　　尽管在很多情况下，数据转换逻辑可能过于专业使其不可能被其他服务或应用程序所用，也可能数据转换逻辑建得太好以致于不能利用许多资源，不过数据转换逻辑的真正问题在于它的限制性，公司最终会有许多为特定目的建造的、编码复杂的、使用范围固定的转换逻辑分布在企业中。这也说明了在企业中隐藏转换的危险性：如果我们将转换的复杂性和消耗隐藏在整个应用程序的消耗中，我们就没有办法测量转化的真正消耗。

　　在应用程序中代替嵌入式转换逻辑的另一种方法是使用外部转换服务解决问题。一个转换服务，在实施 SOA 中的松耦合 (loose coupling) ，以一种格式接收数据，再用另一种格式输出相同语义的信息，如下文所示。

　　 面向服务的转换

　　除了外部数据和语义集成逻辑，使用外部转换服务可以降低 CPU 负荷，为系统操作选择最佳数据转换。尽管使用在远程系统中的服务流量可能引起与远程服务器传输数据的流量，但是外部传输逻辑是松耦合 (loose coupling) 的面向服务的方法，可以通过服务接口，使组织可以在不影响现有服务实施的情况下，独立执行服务器转换服务。

　　除了松耦合转换逻辑的优点之外，转换服务还通过减少数据整合和转换工具的杂烩，大幅度减少了组织的花销。这些工具的证书花销总和也有所降低，同时由于减少了解决方案的数量，从而降低了花销。另外，通过使用转换服务，组织可以提高企业中转换活动的可见度。对转换活动的深入理解为容量计划提供了有价值的意义，同时，如果可能，也为保证数据迁移产生积极影响。解体的转换工具不能提供这些见解。

　　 ZapThink 公司的想法

　　企业、机关和组织为了每天的日常运转、重大决策的制定和与客户、合作者和供应商的正常合作，仍需要应付大量不同类型的数据资源， SOA 的实施并没有改善这一局面。公司仍然面临着在持续变化的不同环境中满足数据和应用程序整合需求的挑战。

　　语义集成问题仍然是全面实现 SOA 业务便捷承诺的主要障碍，然而。企业、机关和组织努力思索看如何将数据含义从数据表达结构中解放出来，这样一来信息就可以在服务之间无缝畅流，促进业务发展。数据转换服务可以解决数据和语义集成的问题。通过单独转换为独立的服务，可以解决数据转换问题，增强转换的灵活性。

　　在 SOBA( 面向服务的业务应用 ) 中，转换服务是最有用的服务，通过转换可以实现在应用程序之间共享服务。编制逻辑可以在向服务发送信息之前，和在处理服务回执之前，通过转换服务追踪信息。从 SOBA( 面向服务的业务应用 ) 开发者的角度看，转换服务不仅仅是一种服务，它使应用程序间的数据从一个服务无缝畅流到另一个服务。转换服务是保证整个过程顺利完成的必要步骤。