Soa不能广泛推广的原因(数据不统一)

客户没有急于采用面向服务架构(SOA)并且从中获益的原因之一，是服务只是一种有效的获取分散在企业信息的方式。尽管标准和技术越来越成熟，可以帮助IT组织将应用逻辑加入到服务中，仍然没有足够的成就能够确保这些服务能够可靠和稳定地去访问和理解他们所依赖的底层数据。由此导致了重用的缺乏、服务开发时间、复杂度和维护成本的增加。

缺少的部分是数据集成层，它将业务逻辑从底层数据结构中抽象出来。数据集成层理解并且维护底层数据的位置、结构、格式、同步模式和交叉引用关系。它利用这些信息作为基础，提供数据集成服务，对数据进行可靠的读取与更新，提高了生产率，降低了创建和维护业务服务的成本与复杂度，从而实现SOA。此外，数据集成层为把数据统一到一个单一的逻辑视图提供了信息和处理流程，这个逻辑视图可以被存储到一个操作数据库或者数据仓库或者通过访问业务活动监控(BAM)工具提供实时的报告。

应对未来的业务挑战

当今的企业面临着日益增长的挑战，为了保持竞争力，快速并且准确地获取信息成为他们成功的重要因素。更好的获取信息可以提高运作效率，增强客户服务满意度、增加市场效力并且能够更好地进行资产和资源的管理，这些都对企业成功运作有积极的推动作用。

比如，制造业企业可以从他们可视化的供应链中获益，来减少订单的处理时间并且更好的管理他们的盘存；零售业企业可以使用实时的销售数据制定进货计划和清空库存；金融服务企业可以基于他们的统一客户视图，更高效地进行交叉销售和向上促销。经过合并和收购活动，企业可以基于一个统一的客户信息视图的企业，为现有的和新的客户提供更好的服务。

数据管理的瓶颈

在大多数企业中，数据都以不同的格式分布在不同的系统中。数据通常以一种为某种应用系统优化的形式存储，并且很少与其他应用系统存储的信息关联。通常不同系统中数据需要被合并和关联，形成一种业务信息，被决策者使用。将这些数据开放出来的障碍，就是存储他们的系统之间的连通性问题。这些年随着集成技术的成熟，基本数据的访问已经不是问题。但是，这种越来越容易的数据访问方式也突显出了一种新的问题，就是如何能够理解和管理这些跨越多个系统的数据，这中间还有很多数据是属于不同的部门的而且在部门中间只有很少的合作。企业中的数据问题在下列情况下将会更加严重：

l         在过去的几年中，企业内的数据量急剧增加

l         日益增长的业务发展速度迫使企业去获得他们需要的信息或者被潮流抛弃。

IT部门试图通过集成软件或者服务来解决信息管理方面的不足。然而，相反作用的处理方式却经常被使用，导致了非常多的点对点的集成接口，很不灵活而且维护成本也很高。那些经验老到的IT部门对他们的IT环境采取了自上而下的整体解决方法，将消息中间件作为信息总线，促进企业中进行信息的流通。在面向服务架构(SOA)的演进中，市场已经走出了这一步，它提倡企业中数据和应用程序逻辑不再专属于任何一个系统，而是转换成可重复使用的共享服务，可以跨系统并且作为组件组合成新的复合应用，推动自动化的业务流程以及为公司提供决策支持。

虽然业界对SOA和SOA策略的组件的确切定义可能还存在争论，但是有一个普遍的共识，这种方式如果架构设计合理可以导致了更大的重用、提高了生产率和可操作性并且IT部门可以以比较低的成本来获得它。到目前为止，建立SOA的技术标准已经获得了很大的进步，比如SOAP和WSDL，它们就着眼于将那些与企业中日常运作的应用系统紧密关联的业务逻辑分离出来，创建成服务。但是对于应用系统中的数据却没有引起足够的重视。结果是，IT部门仍然要为使那些服务所依赖的数据正确、有效并且易于理解而努力。即使这些数据是可以通过适配器和代码进行读取的，但是分布在多个不同系统中的数据仍然没有明确的语义。这就对将数据汇总并形成业务意义造成了障碍。最终，不同的服务消费者在点对点方式中访问同一套数据却没有使用一致的格式化、清洗和解释数据的规则，这样就导致了错误的发生。

障碍——目前实施的局限性

目前的集成解决方案，包括当今大多数的SOA方式，都着眼于将应用系统中的业务逻辑封装成服务。就像业务服务和复合应用系统的开发者使用明确定义的接口将业务逻辑封装成可重用的服务一样，这些服务反过来，也需要通过一个数据集成层来访问底层的数据。而当服务的提供者和消费者通过消息框架或者企业服务总线形成松耦合交互的时候，服务和底层数据之间的交互仍旧是点对点的。

比如，银行可能会为客户服务代表提供客户信息，使他们能够更好地为客户提供服务，充分利用向上促销和交叉销售的机会。为了达到这个目的，他们需要获取分散在多个系统中的客户信息。他们需要建立一些服务，能获得到像采购历史信息、地址和票据信息之类的客户信息。IT部门决定建立一些可重用的服务，比如GetCustomerHistory和GetCustomerAddress。所有的服务发布了不同的客户数据视图并与调用系统松耦合。像采购历史这种数据通常不过只存放在一个地方，可能需要汇总多个订单系统的数据。如果使用服务合成工具来开发这些服务，比如TIBCO BusinessWorks(或者任何标准的服务容器比如.net或Java EE)，服务的开发者们需要去理解这些数据以什么样的结构和关系存储在底层系统中，如何将他们进行汇总和交叉引用产生出需要的信息视图。如果足够幸运，开发人员们可能会得到IT部门维护的数据结构文档，比如底层的系统的Schema和API手册。假设这些文档都能用，目前更重要的，他们仍然要做大量的数据集成开发工作，即使服务需要的是相同的信息的超集。因此，如果底层系统的数据结构有所改变，就会对这些服务产生影响。这样就增加了开发时间、复杂度和维护的成本，妨碍了SOA所承诺的那种将服务快速配置和编排，形成复杂应用的能力的实现。

一旦这些服务建立起来，需要获取客户采购历史信息和客户地址的应用系统和人就需要依靠这些服务来发布信息，业务就会成为一个整体利益。然而，如果开发和维护这些服务的时间和成本没有降低，随着服务的增加，更大的SOA解决方案的成本变得令人望而却步，那么SOA 的好处和承诺就丧失掉了。

创建健壮的数据集成层

在理想的情况下，每当一个访问客户信息的服务被创建，它不需要去读写多个底层系统中的数据，因此，它也不需要去理解客户信息是以什么样的格式、结构和关系进行存储的。

一个解决方法是创建数据集成层，使客户相关的数据与它的存储分离。这就需要IT部门首先为客户、产品和雇员等信息定义一套标准的数据模型。这就意味着不论数据在企业中是如何被存储的，它们必须被定义成一种逻辑数据结构，这种数据结构能够体现业务意义，并且能满足所有依靠这些数据实现业务功能的使用者。比如，IT部门发现客户数据对象需要包含10个属性，包括姓名、地址、电话号码、账号等等。然后，他们就必须分析实际的数据并理解数据的物理结构和性质。大多数企业低估了这项任务，没有花费足够的时间和力量去管理他们的数据资产。一旦这种模型被定义了，接下来进行数据映射的艰巨任务就变成了将数据存储到逻辑数据模型中。

创建一个通用的数据模型然后对物理数据进行剖析并且映射，这个工作本身看上去就是令人恐惧的，会使IT部门变得懈怠。最好采用循序渐进的方式。IT部门可以选取一个业务对象，比如产品或者客户，或者其他类似的业务对象的子集，从这些地方开始工作。

物理模型的结构，逻辑模型，从物理模型转换到逻辑模型的规则都是数据集成层所要包含的元数据。这些元数据的知识和获取它们是获得SOA解决方案所承诺的重用和高生产率的关键。这些规则包括数据的位置、格式、关系、转换逻辑、清洗规则，还有将数据从多个离散的系统中转译成通用逻辑数据模型的交叉引用关系。这些规则可能还包含自定义的业务逻辑，定义了数据在内部是如何被处理的，比如如何计算客户的信用卡积分。

一旦这样的数据集成层就位，开发人员只需要访问元数据来构建服务就可以了。元数据可以使用流行的标准进行维护，比如XML；并且存放到一个数据仓库中，使它能够被安全的访问，可版本控制和在功能变化时可管理，比如影响分析。

用于理解并维护底层数据的位置、结构、格式和关系的数据集成层，允许实际数据和依赖这些数据的服务松散耦合。这种架构极大的降低了成本，减少了实施SOA的复杂度，因此应该成为SOA解决方案中不可缺少的组成部分。

SOA的一个实际例子——操作型数据存储

为了最大限度的实现SOA的优势，数据集成层应该不只是管理数据信息，需要提供一种对数据进行可靠的获取和更新的方式。创建逻辑数据模型以及管理相关的元数据和规则是最大的挑战。一旦这种基础架构就位，掌握了这些知识和工具的IT部门就可以在企业中以有利于业务的信息格式获取和发布信息。比如，通过多个系统汇总客户的采购历史信息。一种受欢迎的对信息进行获取和共享的方式是创建操作型数据存储(ODS，Operational Data Store)。在IT部门中逻辑数据模型有详细的文档并且很好的共享，在ODS中信息就会被以这种模型的格式进行存储。需要获取这些信息的业务服务，比如客户数据，可以在ODS中读取和更新数据，这样就可以独立于复杂的底层系统。ODS起到了将底层数据汇总成单独的逻辑数据视图的作用。在很多方面这和数据仓库提供的功能有些相似。根本的不同是，ODS是业务视图的一部分，并且包含有实时的和潜在的数据。它可以为特殊的决策以及传统的日报或周报提供参考。因为它支持提供特殊决策，经常被认为是实时的数据仓库。通常企业中的数据仓库也作为ODS的数据源之一，所以操作型数据可以通过相关的数据得到加强，提供更深层次的信息。在前面提到的元数据，包括数据的位置、格式、关系、转换逻辑、清洗规则和交叉引用关系，将会促进创建ODS并保证它与底层系统的同步，为数据集成服务的创建提供需要。

ODS的不同数据组件对业务规则有不同层次的业务需求。库存信息会有实时性要求，因为它经常变化；但是客户地址信息只需要一天刷新一次；客户订单历史信息只会在需要的时候才会被刷新。数据服务平台不只要理解底层数据的语义和结构，还要知道数据的潜在需求和同步模式来保证ODS与底层系统的同步。数据集成服务的必须以最高效和优化的方式发布，以满足在服务的消费者应用和ODS之间潜在服务需求。它们必须足有足够的灵活性，因为有些目前还是准实时需求功能，将来就可能会变成实时的，必须要能应对这类业务变化的挑战。

最后，整个的平台环境必须是安全的、可监控的和可管理的。底层数据集成流程必须具有高可靠性、高可用性和可扩展性，为关键性任务提供支持。

 

图1 SOA中的数据集成

向敏捷企业迈进

将一个健壮的数据集成层作为SOA的基础架构，不论从近期目标还是从长远利益，都会帮助企业获益。随着企业内数据量的膨胀和系统复杂度的增加，这就成为一个棘手的任务，因此无人愿意接手。然而，当这个任务被很好的完成，将会获得很多的能直接转化为业务效益的技术效益，那时CEO，CFO和相关的业务领导都会非常的赞赏。数据集成层不但能增强SOA现有的优势，还会带来更多的好处。

技术效益

充分利用已有的数据资产——SOA将独立的应用系统所私有的数据释放出来，使已有的IT投资得到了充分的利用，减少了每次新功能开发所需要的投资成本。

降低开发和维护成本——通过重用诸如集成服务和元数据之类的现有的资产，开发人员可以在部署新功能的时候极大的增加他们的生产率。因此，如果服务能够遵循已经建立的通用数据语义模型，开发人员可以依靠并与其他的服务进行互操作。这样，IT部门就可以充分的降低开发和部署新功能的风险和成本，并且降低维护已有系统的成本。

随须应变——SOA要求服务的消费者和生产者之间是松耦合关系，它们之间甚至不需要知道对方的存在。另外数据集成层以及由元数据驱动的数据集成流程，在服务和它们所需要的数据之间也是松耦合的。这种数据和功能之间的握手方式，使业务逻辑能够根据业务的需求迅速的作出变化，使IT部门面对需求的变化更具灵活性和适应性。

业务效益

统一的数据——一个强大的建立在通用数据对象模型之上的数据集成层，允许数据在企业内部进行发布，这些数据可以被获取、关联并通过一定的方式进行汇总。决策者可以通过单独的统一数据视图获取信息并采取行动，而不是通过哪些不相关，描述不同的事情的数据。

快速响应市场需求——SOA提供了一种可重用、高生产率的基础架构，使得新的应用功能可以快速的部署。在业务层面，这可以转化为一种充分利用市场机会的能力，可以在尽可能短的时间内为用户提供新产品或者服务。

更好更快的决策——当数据集成基础架构是用一种支持SOA原则的方式部署，企业可以更好的获取，共享和理解企业中的信息，通过这种方式决策者不但可以看到这些信息，还可以更好的利用这些信息。

低成本——通过SOA实现重用、生产率、互操作性和快速部署等好处，可以转化为对已有业务流程和新的业务功能的低成本的支持和开发。结果是为公司节省了时间和成本。