我最近一直在做很多关于 SOA 和 ESB 等的研究。
我现在正在重新设计一些工作中的遗留系统，并希望使用比目前更多的 SOA 架构来构建它。我们在大约 5 个网站中使用这些服务，而我们目前在遗留系统中遇到的最大问题之一是，几乎在我们进行错误修复或更新时，我们需要重新部署我们的 5 个网站，这可能是相当耗时的过程。
我的目标是使服务之间的接口松散耦合，以便进行更改而无需重新部署所有依赖的服务和网站。
我需要能够在不破坏或更新任何依赖项的情况下扩展现有服务接口。你们中有人遇到过这个问题吗？你是怎么解决的？
【问题讨论】：
标签： c# soa esb loose-coupling
我建议您寻找一种不同于您迄今为止所做的服务风格的服务。考虑使用事件而不是请求/响应来相互协作的服务。多年来，我一直在与各个垂直领域的客户一起使用这种方法，并取得了巨大的成功。在过去的 4 年里，我写了很多关于这些主题的文章。您可以从这里开始：
http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/
希望对您有所帮助。
【讨论】：
您可以采取几种方法。我们的 SOA 架构涉及到服务发送和接收的 XML 消息。我们实现您所描述的一种方法是避免对我们的 XML 模式使用数据绑定库，并使用通用 XML 解析器来获取您想要忽略那些您不感兴趣的数据节点。这样服务可以添加消息的附加新节点，而不会破坏当前使用它的任何人。我们通常只在需要来自较大模式结构的一两条信息时才这样做。
另外，我们使用的另一个（首选）解决方案是版本控制。服务的版本遵循特定的模式/接口。当模式改变时（例如接口被扩展或修改），我们创建一个新版本的服务。在任何时候，我们都可能随时有 2 或 3 个版本。随着时间的推移，我们弃用并删除旧版本，同时最终将相关代码迁移到新版本。这样，那些依赖于服务的人可以继续使用现有版本的服务，而某些特定的依赖可以“升级”到新版本。调用哪个版本的服务在依赖代码的配置文件中定义。请注意，不仅是模式会被版本化，所有底层实现代码也是如此。
希望这会有所帮助。
【讨论】：
你问的不是一个简单的话题。有很多方法可以让您的面向服务的架构松散耦合。
我建议查看 Thomas Erl 的 SOA book series。它非常清楚和深入地解释了一切。
【讨论】：
实现服务的松散耦合有一些常见的做法。
使用 Web 服务的 doc/literal 样式，考虑数据（有线格式）而不是 RPC，避免基于模式的数据绑定。
在发送数据时严格遵守合同，但在处理传入数据时保持少量假设，xpath 是一个很好的工具（松入，紧缩）
使用 ESB 并避免服务之间的任何直接点对点通信。
【讨论】：
这是一个粗略的清单，用于评估您的 SOA 是否实施松散耦合：
被调用系统的位置（其物理地址）： 应用程序使用直接 URL 来访问系统，或者是 应用程序通过负责的抽象层解耦 用于维护系统之间的连接？服务登记处 并且 SAP NetWeaver CE 中使用的服务组范式很好 这种抽象可能是什么样子的例子。使用 企业服务总线 (ESB) 是另一个例子。重点是 应用程序不应硬编码的物理地址 称为系统，以便真正被视为松散耦合。
接收器数量： 应用程序是否指定了哪些系统 服务呼叫的接收者？松散耦合的组合不会 指定特定的系统，但将离开其交付 消息到服务合同实现层。一个紧紧的 耦合的应用程序将显式调用接收系统 命令;松散耦合的应用程序只需调用 服务接口并允许服务契约实现 层负责将消息传递到右侧的细节 系统。
系统的可用性：您的应用程序是否要求所有 您连接的系统一直处于启动和运行状态？ 显然，这是一个非常困难的要求，尤其是如果您 想要连接到不受您控制的外部系统。 如果答案是所有系统都必须一直在运行，那么 应用程序在这方面是紧密耦合的。
数据格式：应用程序是否重用了由 后端系统，或者您使用的是规范数据类型系统 这与被调用的类型系统无关 应用程序？如果您正在重用后端的数据类型 系统，您可能不得不在 您的应用程序，这不是一种非常松散耦合的方法。
响应时间：应用程序是否需要被调用系统来响应 在一定的时间范围内，或者申请是否可以接受 几分钟、几小时甚至几天后收到答复？
【讨论】：