文档介绍：在ＳＯＡ中创立独立的数据清洗服务 独立的人格 经典语录
在SOA架构中开发一个独立的服务，它能够在服务之间进行数据交换时检测和清洗错误，这么不但能在第一时间确保数据质量，而且能够避免为每个包括数据交换的服务开发错误数据检测和清洗程序，从而大大降低了程序员的开发工作量。
SOA为IT系统的设计、开发和布署提供了一个新的思绪。经过引入SOA的架构，IT系统处理了系统紧耦合、异构系统的互联互通及标准服务契约等问题。尤其是SOA把Web Service作为SOA中的服务的标准实现方法，为后续的服务组合和业务步骤编排提供了基础。然而，SOA只是为IT系统提供了好的基础架构，至于服务怎样组合和服务之间的数据怎样交换还需要另外考虑。比如，确保服务之间交换的数据的正确性就一直是组合服务时一个很头疼的问题，因为数据的质量不但影响服务组合后的运行结果，很可能还会影响未来基于这些数据所做决议的正确性。
实际上，相关数据质量确保的研究在很多领域全部在进行中，尤其是在数据库和数据挖掘领域。这些研究关键集中于在数据库中标识脏数据，比如在数据库中标识某个表中的多出值或名字和结构冲突等。其次，使用统计的方法来标识数据集合中的可疑数据或丢失数据的研究也在进行中。不过，这些措施全部是在数据搜集保留下来以后对数据进行处理的，属于事后处理，而本文提出在服务之间进行数据交换的同时进行数据清洗。
独立数据清洗工具的不足
布署独立的数据清洗工具几乎是现在进行数据质量确保最为流行、也最为有效的措施，市场上也有不少商业化的数据清洗工具可供选择。不过，假如SOA环境中数据清洗只是单纯地依靠某个清洗工具，将会引发部分问题。比如，只依靠某个数据库的清洗工具或数据挖掘系统来完成数据清洗的话，可能因为数据库和应用系统的数据规则不一样而造成应用程序无法处理，从而引发程序错误; 或将不正确的数据存入数据库，从而造成未来决议和系统间对账的不正确。为了处理这些问题，很多应用系统不得已另外引入了数据清洗工具，尤其是在和数据挖掘相关的应用中。然而，这些工具通常全部只应用于数据挖掘等特定应用的特定数据种类，而且它们是独立开发的，通常极难在SOA架构内部使用。详细而言，独立的数据清洗工含有以下不足:
首先，不可能确保服务之间数据交换的质量。比如，两个交互服务之间要交换数据，服务B将数据集的某个数据删除了或系统中的清洗工具正在对它进行清洗，不过服务A并不知道，可能要一直等候这个数据的到来。要避免出现这种情形，就要求数据清洗服务能够在服务中实时地监测数据的交互。
其次，在SOA架构下，开发者为了满足服务对数据输入和输出的要求，往往需要对服务的内部进行调整。比如，经过集成服务A和服务B来创立一个新的服务，假设A已经输出数据集，但B只是处理该数据集中的部分数据，而且A中的数据并不完全符合B对输入数据的要求，这时，就需要对B服务进行修改，此时独立的数据清洗工具派不上太大用场，而能单独管理服务间的数据交换的独立服务则能完成这一任务。
第三，即使有一个由单独组件开发的清洗工具，假如不满足一定的要求，依然不太可能灵活地进行脏数据检测。换句话说，即使一个清洗工具被开发成一个组件应用于服务A和服务B，要让清洗引擎反复更新以反应规则中的任何改变，从而建立新的规则去检测从服务A输