I2:名称:竖井方法

    问题：此反模式带来的问题是标识服务的方式。当根据独立的应用程序(而不是以企业策略为中心)对服务进行标识时，期望 SOA 实现所带来的好处将永远不能实现。

    环境：此反模式主要出现在根据独立工作的具有塔状结构的功能模型进行组织的企业中。每个功能塔所享有的自治权将导致采用竖井方式进行工作。

    症状：此反模式的一个症状是不同的小组使用不同的名称对相同的服务进行标识。没有标识公共服务，或未实现服务共享，同样也清楚地表明应用了此反模式。

    结果：由于采用竖井(silo)方法会导致服务被多次标识和实现，不必要的昂贵开发成本或服务重复使得采用 SOA 所能带来的好处大打折扣。而且，由于使用此反模式，会使不同应用程序的受益人间的重用减少或完全消失。

    根本原因：在大多数情况下，组织的边界和约束是此反模式的根本原因。在某些企业中，缺乏对“服务公开决策”的有所控制的方法也是根本原因。

    解决方案：此反模式的解决方案是建立一个控制框架，以确保跨功能塔进行服务标识和通信。另外，还应当进行以标识公共服务为目的的相关工作。这可以通过使用 SOMA 等好的服务建模方法来完成。

    解决方案示例：标识公共服务

    像大多数企业一样，一家大型银行是按照业务塔进行的组织，这些业务塔为不同类型的银行客户提供类似的业务功能。SOMA 用于开发服务模型，以促进业务塔间的重用和了解此类重用机会。从更高的角度来看，在支持业务功能所需的业务服务中，约有 90% 都具有相似性，这是潜在的重用领域。

    I3:反模式名称:注册中心行为不正常

    问题：在没有一致的 SOA 控制模型的情况下采用 UDDI 将导致流程和设计的效率低下。特别是重复的注册中心可能导致效率低下，使得性能下降，并可能产生安全和遵从性漏洞。

    环境：没有注册中心控制协议，但却尝试建立 UDDI 用途的企业将经常遇到此反模式。

    症状：考虑到 UDDI 是标准而不是产品，如果使用不恰当，可能导致建立重复的服务注册中心和重叠的、不明确的关系。这将表现为不正确的、容易引起误会的服务接口信息，特别在共享服务模型内的组合服务场景的发现操作期间表现得十分明显。尽管注册中心中单个服务接口的描述是正确的，但重复的条目将导致整个服务的发现不正确。而且，缺乏控制模型可能是由于服务在生命周期流程的各个阶段注册，当不具有一对一的所属关系转换时被遗弃而造成的。例如:假定某个开发人员向内部 UDDI 添加了三个服务。然后，服务管理员可能会将其中两个迁移到生产 UDDI 中。这就产生了孤立服务。服务组件也可能出现类似的情况。

    结果：在试图确定注册中心中哪个服务导致无法满足 SLA 时，重复的注册中心将导致控制灾难和运行时混淆。此外，此类重复还会导致性能下降和安全漏洞及遵从性漏洞。此类反模式的另一个结果就是由于重复而会产生计划外成本。

    根本原因：缺乏设计时一致性(SOA 控制模型)是导致此反模式的主要原因。具体来说，此问题的核心是服务注册中心所属关系不清楚且没有建立和执行企业级 SOA 参考体系结构。

    解决方案：为了避免此反模式，公司必须建立 SOA 控制模型，以定义和采用服务注册中心非常好的实践、所属关系以及相关团队间的通信。这将消除重复条目和不正确的接口信息，并最小化包含孤立服务的结果。由于只有一个服务描述源(其中包含关联的 SLA 和策略)，因此还可以消除运行时混淆。使用 SOA 企业级参考体系结构间建立和执行遵从性应是 SOA 控制模型制度化的第一步。