SOA 实现反模式

    此类反模式捕获实现服务的最差实践。

    R1:反模式名称:通信较多的服务

    问题：此反模式描述开发人员通过实现一系列 Web 服务(这些服务彼此需要就一小部分数据进行通信)来实现服务的情况。同一个反模式的另一表现是服务实现最后会进行大量的微型信息通信，而不是采用将数据组合到全面的类似于文档的格式中。

    环境：如果组织中的开发人员急于在没有恰当的建模的情况下开始进行实现，这些组织将最终受到此反模式的困扰。在某些情况下，开发人员被要求在没有了解如何从 SOA 获得最大利益的情况下使用 Web 服务替代 API，将通常会导致此反模式。

    症状：如果有实现大量过分细粒度服务的需求，则表明应用了此反模式。

    结果：性能下降和开发成本增加是此反模式的主要结果。此外，使用者必须进行额外的工作以对这些过分细粒度的服务进行聚合，以实现相关优势和获得如何将这些服务一起使用的知识。

    根本原因：由于不知道任何更好的办法，很多开发人员采用的方法就是采用 Web 服务的形式模拟 API 的实现。这与我们在最开始采用面向对象的编程技术时的情况(开发人员使用面向对象的语言来开发过程型的程序)十分相似。另外，急于采用这项新技术，可能会导致所有内容都成为 Web 服务，却不能带来任何好处，而且成本会急剧增加。

    解决方案：为了避免此反模式，需要集中精力进行设计重构，以将各个数据片断组合到一个文档中，以消除通信量过多的服务。另外，就 API 和服务之间的区别进行培训(并强调恰当的服务粒度)，也会有用。不过，避免此反模式的最有效办法是定义映射回业务目标的服务。可以通过引入和使用好的服务建模技术来为业务解决方案确定恰当的粗粒度服务，从而完成此工作。这将最小化服务通信过多的行为，因为此行为已在 SOA 中正确的粒度级别得到了标识。应用 Service Litmus Test (SLT) 也可以帮助确定要公开的正确服务级别。SLT 的一个例子是考虑服务是否提供了支持业务流程和目标所需的业务功能单元。

    R2:反模式名称:点到点服务

    问题：基本问题是开发人员在不考虑使用环境的情况下尝试使用点到点 Web 服务作为集成方法替代中间件。

    环境：此模式出现在缺乏长期系统集成远景而强调短期结果的组织中。

    症状：此反模式的一个表现是在内部应用程序之间使用 SOAP over HTTP。

    结果：由于使用此反模式，点到点集成解决方案将作为企业的事实上的集成模式出现。这将对任何实现恰当 SOA 实现的所有优势的可能带来负面影响。

    根本原因：此模式的主要根源是缺乏对总体系统的长期维护和发展的考虑(可能是由于强调短期解决方案而造成的)。在某些情况下，急于在别处使用服务也可能导致此类点到点服务方法使用的增多。

    解决方案：为了避免采用此反模式的结果，应该考虑将智能连接器(如服务总线)作为正式集成方法使用。使用服务总线，应用程序可以简单有效地一起工作，以支持业务需求，并同时保持协作系统和应用程序间的松散耦合。