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