在"对目前从事 SOA 的组织的几点建议"这篇博客中，Ganesh Prasad 基于他多年的经验，对于如何开展一个大型的 SOA 项目作出了建议：
…不要因为这一方式不是那么宏大而感到担心。复杂性让新手感受深刻，但结果才是最终能让所有人留下印象。
Ganesh 的方法包括了以下几个要点：
- 眼观全局。SOA 不是关于集成或者是引入一种新技术来简化现有系统的连接。而是关于： > …精简企业的部件并且使它们易于理解和连接…所以始终应当谨记简洁性，并且不要把它与权宜之计搞混了，那是指的阻力最少的道路和。而精简可能需要付出努力。
- 理解数据。服务互操作性需要用于交互的“语义”数据模型。Ganesh 指出所谓规范的数据模型通常层次较高且对于实践应用来说过于抽象。作为代替，他建议将企业数据划分为几个逻辑域并为各个域定义字典。 > 所有暴露它们的逻辑域的服务都应该当使用这些定义，而来自其它域的服务消费者有责任理解这些定义。由跨这些域的服务组合起来的流程应当在类似的数据元素之间执行它们自己的映射。这不象听起来这么恐怖，因为只有一个域所管理的数据元素只有一部分子集会通过服务接口暴露出去…不要尝试 [构建] 一个单一的规范数据模型。那只是徒劳之举，根本不要启动。
- 选择正确的中间件。在 Ganesh 看来，大部分情况下，HTTP 是 SOA 实现最合适的中间件。他建议，除了必须需要的情况下，避免使用消息队列并指出基于 HTTP 的数据库备份的通信模型通常能提供更简单的解决方案。 > HTTP 是一个十分通用的协议，可用作你的 SOA 项目的逻辑基础设施的元素。ESB，服务目录以及其它的“治理”组件通常只在管理它们自身所引入的复杂性时才需要。用简单的 web 服务器群和数据库群所能做到的会让你惊叹，同时还能始终保持简单和明了。
- 选择正确的服务实现手段。Ganesh 认为基于 SOAP 的 web 服务很大程度上是“供应商提供”的宣传，并推荐尽量予以避免。他建议使用 REST 来代替： > REST 实际上是实现 SOA 的有效方式，它通常可以以极低的成本和复杂性来交付解决方案。采用 REST 的困难所在是找到用这种方式思考的优秀人员。
- 选择正确的数据合约定义。 谈到领域模型的正式定义时，Ganesh 建议道“标准”的 XML 方式是重量级的比较笨拙。相反，他建议好好看一下 JSON 模式提案> 在许多高级语言比如 Java 当中，已经有现成的 JSON 模式的库可用。应该能够可以以极低的复杂性，如 XML 一样严格的定义数据合约…避免 XML 的那些繁文缛节，由 JSON 开始，并且融合日趋成熟的 JSON 模式。你会发现这些与 REST 结合起来会工作得非常棒。
解决 SOA 简洁性的悖论。 尽管 SOA 背后的主要驱动因素是精简企业架构，按照 Ganesh 的说法，典型的 SOA 实现的现实是，因使用重量级方案而导致集成了复杂性，又通过引入工具来管理这一复杂性。 > 当然，如果你有官僚的倾向，你可以沐浴在高预算与大团队的声望中，并且可以基于你所交付的服务和流程和数量发表胜利的宣言。但如果你真的想成功交付 SOA(例如，让你的业务更加灵活并且以一种可持续的低成本来运营)，而这一路上不用烧钱的话，你得务必看看我上面列的这些烦人的，没什么印象的，甚至是不合潮流的方案和技术。让那些大卖主好好歇歇吧。你不需要买技术 (除了你所拥有的 web 服务器和数据库)。你也当然不需要买任何复杂的技术，而这正是那些供应商要倾售给你的。
Prasad 的文章讨论了一个典型的 SOA 实现会遇到的许多问题。它同样通过新的途径，摒除了现有的经常使用的解决方案遇到的问题。这引出一个话题：什么时候更适宜去理解和改进一个现有解决方案要，而什么时候又适宜摒弃现有方案而尝试新的途径呢？新事物是否总是最好？
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
复杂业务场景下的 Flutter 混合开发技术实践
MFTcoder：大模型多任务微调框架
手淘新一代自绘渲染引擎的设计和业务实践
评论