如何使用SOA体系结构实现松散耦合

Question

我最近一直在做关于SOA和ESB等的大量研究。

我正在努力重新设计一些现有的遗留系统，并且希望使用比现有更多的SOA架构来构建它。我们在大约5个网站中使用这些服务，我们现在使用我们的遗留系统遇到的最大问题之一就是我们几乎所有时间都在进行错误修复或更新时需要重新部署我们的5个网站，这些网站可能是非常耗时的过程。

我的目标是使服务之间的接口松散耦合，以便无需重新部署所有相关服务和网站即可进行更改。

我需要能够扩展现有的服务接口，而不会破坏或更新任何依赖项。有没有人遇到过这个问题？你是怎么解决的？

Answer 1

我建议你看一下与你迄今为止所做的不同的服务风格。考虑使用事件而不是请求/响应彼此协作的服务。多年来，我一直在使用这种方法与各种垂直行业的客户取得了很大的成功。在过去的4年里，我已经写了很多关于这些主题的文章。这是您可以入门的地方：

http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/

希望有所帮助。

Answer 2

您可以采取几种方法。我们的SOA架构涉及发送到服务和从服务发送的XML消息。我们实现您所描述的内容的一种方法是避免使用数据绑定库到我们的XML模式，并使用通用的XML解析器来获取您想要忽略那些您不感兴趣的数据节点。这样服务可以添加消息的其他新节点，而不会破坏当前使用它的任何人。我们通常只在需要来自更大模式结构的一两条信息时才这样做。

或者，我们使用的其他（首选）解决方案是版本控制。服务版本遵循特定架构/接口。当架构发生变化时（例如扩展或修改接口），我们会创建新版本的服务。在任何时候我们可能随时都有2或3个版本。最后，我们弃用然后删除旧版本，同时最终将相关代码迁移到更新版本。这样，依赖于服务的人可以继续使用现有版本的服务，而某些特定的依赖可以“升级”到新版本。调用哪个服务版本在依赖代码的配置文件中定义。请注意，不仅是版本化的模式，还有所有底层实现代码。

希望这有帮助。

Answer 3

你要问的不是一个简单的话题。有许多方法可以使您的面向服务的体系结构松散耦合。

我建议查看Thomas Erl的SOA book series。它清楚而深入地解释了所有内容。

Answer 4

实现松散耦合服务有一些共同的实践。

1. 使用doc / literal样式的Web服务，考虑数据（有线格式）而不是RPC，避免基于模式的数据绑定。

2. 在发送数据时严格遵守合同，但保留处理传入数据的假设很少，xpath是一个很好的工具（松散，紧缩）

3. 使用ESB并避免服务之间的任何直接点对点通信。

Answer 5

以下是评估您的SOA是否实现松散耦合的粗略清单：

• 被叫系统的位置（物理地址）：你的 应用程序使用直接URL访问系统或是 应用程序通过负责的抽象层解耦 用于维护系统之间的连接？服务登记处 SAP NetWeaver CE中使用的服务组范例很好 这种抽象可能是什么样子的例子。用一个 企业服务总线（ESB）是另一个例子。关键在于 应用程序不应硬编码的物理地址 称为系统，以便真正被认为是松耦合的。

• 接收方数量：应用程序是否指定了哪些系统 服务电话的接收者？松散耦合的复合材料不会 指定特定系统，但将保留其交付 消息到服务合同实现层。紧紧的 耦合应用程序将明确调用接收系统 订购;一个松散耦合的应用程序只是调用 服务接口并允许服务合同实现 层来处理向右传递消息的细节 系统

• 系统的可用性：您的应用程序是否需要全部 您正在连接的系统是否一直在运行？ 显然，这是一个非常困难的要求，特别是如果你 想要连接到不受您控制的外部系统。 如果答案是所有系统必须一直在运行，那么 应用程序在这方面紧密结合。

• 数据格式：应用程序是否重用了提供的数据格式 后端系统或您使用的是规范数据类型系统 这与被调用的类型系统无关 应用程序？如果您正在重用后端的数据类型 系统，您可能不得不在数据类型转换中挣扎 你的应用程序，这不是一个非常松散耦合的方法。

• 响应时间：应用程序是否需要被叫系统进行响应 在一定的时间范围内或者申请是否可以接受 几分钟，几小时甚至几天后得到答案？