为解决方案架构师打造的实用SOA
openkk 13年前
<p>WSO2出的新白皮书<a href="/misc/goto?guid=4958197911021200658">《为解决方案架构师打造的实用SOA》</a>将SOA定位成：</p> <blockquote> ……一个常识性准则，不仅在今天，即便在信息时代出现伊始，都很有价值。 </blockquote> <p>怀揣这一理念，白皮书试图：</p> <blockquote> ……提供一套使用SOA的实用的方法，而且是容易掌握，立即可用的方法。并且它对产商是中立的，因为它谈的是通用概念和逻辑组件，它们几乎出现在每个产商的产品线中。 </blockquote> <p>白皮书将重点放在解决方案架构师最关心的两个问题之上：</p> <blockquote> <ul> <li>在技术层，解决方案架构师需要为问题找到正确的工具。</li> <li>在数据层，他们需要知道如何降低或消除系统间的不必要的依赖关系。</li> </ul> </blockquote> <p>就技术（工具）而言，白皮书指出，最常用的核心SOA技术组件有三个：</p> <blockquote> <ul> <li>服务容器</li> <li>服务代理</li> <li>流程协同器</li> </ul> </blockquote> <p>解决方案架构师需要使用以上组件将现有及未来的功能组件组织起来，从而创建新的端到端业务解决方案。如何使用它们，应该遵循以下规则：</p> <ul> <li>服务容器是平台，新实现的服务作为解决方案的一部分，托管在该平台上。</li> <li>服务代理是工具，它可将现有企业应用封装成服务暴露出来。它提供现有功能的适配/转换/仲裁等功能。</li> <li>流程协同器用于实现业务流程，将服务的执行串接起来。</li> </ul> <p>据白皮书，除以上三个组件之外，SOA实施中常用的其他组件有：规则引擎、数据访问工具、注册/存储工具、管理和监控工具、治理工具、定制事件处理、展现支持等。</p> <p>白皮书又进一步说明，仅仅选择了正确的技术组件还不足以保证SOA的成功：</p> <blockquote> 我们还应该保证，通过合适的SOA技术所获得的成功不能被紧耦合的数据设计所抵消。 </blockquote> <p>它还提出4条法则，以便实现低数据耦合的SOA设计。</p> <ul> <li><b>找出隐性依赖，使之变成显式的服务契约</b>——这样，简单地确保持续符合服务契约，就能隐藏系统内的变化，从而保护系统的其他部分。</li> <li><b>消除无用的系统间依赖</b>——应该找出并消除(系统间)无意义的依赖关系。</li> <li><b>保证领域数据和消息数据松耦合</b>——二者之间使用数据映射，而不要使用数据生成或数据继承。</li> <li><b>标准化词汇要在逻辑域中，而不要在整个组织中实施</b>——把整个组织的词汇标准化无异于“煮沸整个大海”。</li> </ul> <p>白皮书还通过几个银行和保险业的示例来阐述上述概念的应用。</p> <p>它的结尾说：</p> <blockquote> 这些简单但强力的概念是有效的SOA设计的关键，现在你的技能库中已经有了这些概念工具……[它们]可帮助你下一个项目的落地。所以，你会本能地设计出符合SOA原则的解决方案。 </blockquote> <p>尽管很难驳斥白皮书的结尾，以及其中所给出原则的重要性，但是它却没有给现有的SOA文献带来任何新东西。在技术层面上，它基本上说，服务的执行既可以从服务容器中从头开发，也可以通过失配/转换/仲裁等模式封装遗留应用的方式得到，业务流程编排了这些服务。而这些技术解决方案是当代ESB的基础。在数据层面上，“典范”企业数据模型是EAI在15年前就提出了，而且得到很多SOA实施的吸纳。至于隐式和显式的服务接口以及消除不必要的依赖，这些概念直接来自现有服务设计模式之中，即服务的松耦合以及将服务实现隐藏在良定义接口的背后。</p> <p>话说回来，提醒一下这些SOA实施的原则任何时候都有意义的。</p> <hr /> <p><b>查看英文原文：</b><a href="/misc/goto?guid=4958197911774679492">Practical SOA for Solution Architects</a></p> 来自： <a href="/misc/goto?guid=4958197912500764880" target="_blank">InfoQ</a>