在SOA设计方式目录中的所有的方式中也许没有任何一种方式能够像典型模式那样很容易理解但是很难应用。还有一些方式引起了许多争论。事实上，典型模式的应用潜力能够成为确定一个服务清单架构的范围和复杂性的基本的影响因素之一。
所有这些都归结为建立基准的户操作性。典型模式保证根据能够共享基于标准的数据模式的合同建立服务。与众所周知的典型数据模式(Hohpe, Woolf)不同，典型数据模式主张把单独的应用程序集成在一起根据统一的数据模型共享数据。典型模式要求我们提前把这些统一的数据模型建在我们的服务合同中。因此，这种方式的成功的应用总是要求我们建立和不断地强制执行设计标准。
但是，在我们讨论数据模型标准化和设法使这个事情发生所有的有趣的事情之前，让我们先后退一步解释一下”基准互操作性“是什么意思。
当服务和服务消费程序相互沟通的时候，数据将根据一些结构和一套规则进行传送(通常用消息的形式)和编辑。这种架构和相关的规则构成了数据的正式模型。
当不同的服务旨在与不同的数据模型代表相同类型的数据的时候，它们将遇到共享这个数据的问题，因为这种数据模型是不兼容的。要解决这个问题，要使用一种称为数据模型转换的技术开发数据模型镜像逻辑。让这种服务交换的数据在运行的时候动态地从一种数据模型转换到另一种数据模型。这种技术非常成功，已经开发出了相应的数据模型转换方式。
然而，采用数据模型转换带来了一些问题。过度使用数据模型转换带来了一些真正的问题，如架构的复杂性、增加的开发的努力和运行时间的性能要求。这些问题对于更大的服务组合会影响到这种程度：如果你把耳朵贴近你的中间件软件，你实际上会听到这种额外的运行时间延迟的运转和摩擦声。
这些问题以及其它细节和问题将在即将推出的本系列文章的”数据模型转换方式“中单独论述。对于我们来说，现在最重要的是理解我们使用典型模式的主要目标是为了避免使用”数据模型转换“。
这使我们回到了设计标准及其应用的范围的问题上。把典型模式作为不同的项目团队在不同的时间提供的服务的一部分需要每一个项目团队同意使用相同的预先确定的数据模式作为统一的业务文件。这听起来好像是一个简单的要求，但是，有时候简单并不等于容易。许多机构过去都很难强制执行和治理标准化的数据模型，甚至达到导致机构权利斗争的程度，个人恩怨被强制执行了并且出现了大规模遵守和改变数据模型管理的技术困难。
所有这些是典型模型方式经常与域清单一起使用的全部原因。限制应用程序、强制执行和治理标准化的数据模型以定义一个可管理的规模的服务清单能够显着提高成功地实现这种方式的全部潜力的可能性。
典型模式概括了从基于竖井的集成的企业向面向服务的企业转变。这种模式解决了一个大问题，但是，要求我们对于其应用做出同样大的承诺。
未经允许不得转载：DOIT » SOA：容易理解很难应用的典型模式
