如何使用 SOA 架构实现松耦合
我最近对 SOA 和 ESB 等进行了大量研究。
我现在正在工作中重新设计一些遗留系统，并且希望使用比目前更多的 SOA 架构来构建它。我们在大约 5 个网站中使用这些服务，而我们的遗留系统目前面临的最大问题之一是，几乎每次我们进行错误修复或更新时，我们都需要重新部署我们的 5 个网站，这可能是一个相当耗时的过程。
我的目标是使服务之间的接口松散耦合，以便无需重新部署所有依赖的服务和网站即可进行更改。
我需要能够扩展现有的服务接口，而不破坏或更新其任何依赖项。你们中有人以前遇到过这个问题吗？你是怎么解决的？
I've been doing a lot of research lately about SOA and ESB's etc.
I'm working on redesigning some legacy systems at work now and would like to build it with more of a SOA architecture than it currently has. We use these services in about 5 of our websites and one of the biggest problems we have right now with our legacy system is that almost all the time when we make bug fixes or updates we need to re-deploy our 5 websites which can be a quite time consuming process.
My goal is to make the interfaces between services loosely coupled so that changes can be made without having to re-deploy all the dependent services and websites.
I need the ability to extend an already existing service interface without breaking or updating any of its dependencies. Have any of you encountered this problem before? How did you solve it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我建议您考虑一下与您迄今为止所做的不同风格的服务。考虑使用事件而不是请求/响应相互协作的服务。多年来，我一直在为各个垂直领域的客户使用这种方法，并取得了巨大的成功。在过去的四年里，我写了很多关于这些主题的文章。您可以从这里开始：
http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/
希望有所帮助。
I suggest looking at a different style of services than maybe you've been doing so far. Consider services that collaborate with each other using events, rather than request/response. I've been using this approach for many years with clients in various verticals with a great deal of success. I've written up quite a bit about these topics in the past 4 years. Here's one place where you can get started:
http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/
Hope that helps.
您可以采取几种方法。我们的 SOA 架构涉及发送到服务和从服务发送的 XML 消息。我们实现您所描述的目的的一种方法是避免对我们的 XML 模式使用数据绑定库，并使用通用 XML 解析器来仅获取您想要的数据节点，忽略您不感兴趣的数据节点。通过这种方式，服务可以添加向消息添加新节点，而不会破坏当前使用它的任何人。我们通常只在需要更大模式结构中的一两条信息时才这样做。
或者，我们使用的另一个（首选）解决方案是版本控制。服务的版本遵循特定的模式/接口。当模式发生变化（例如，接口被扩展或修改）时，我们创建新版本的服务。在任何时候，我们都可能同时拥有 2 或 3 个版本。随着时间的推移，我们弃用并删除旧版本，同时最终将依赖代码迁移到新版本。这样，那些依赖于该服务的人可以继续使用该服务的现有版本，而某些特定的依赖项可以“升级”到新版本。调用哪个服务版本是在依赖代码的配置文件中定义的。请注意，不仅模式受到版本控制，而且所有底层实现代码也受到版本控制。
希望这有帮助。
There are a couple of approaches you can take. Our SOA architecture involves XML messages sent to and from the services. One way we achieve what you describe is by avoiding the use of a data binding library to our XML schema and use a generic XML parser to get just the data nodes you want ignoring those you aren't interested in. This way the service can add additional new nodes to the message without breaking anyone currently using it. We typically only do this when we need just one or two pieces of information from a larger schema structure.
Alternatively, the other (preferred) solution we use is versioning. A version of a service adheres to a particular schema/interface. When the schema changes (e.g the interface is extended or modified), we create a new version of the service. At any time we may have 2 or 3 versions on the go at any one time. In time, we deprecate and then remove older versions, while eventually migrating dependent code onto newer versions. This way those dependent on the service can continue using the existing version of the service while some particular dependency can 'upgrade' to the new version. Which versions of a service are called are defined in a configuration file for the dependent code. Note that it is not only the schema which gets versioned, but all of the underlying implementation code as well.
Hope this helps.
你问的不是一个简单的话题。有很多方法可以使面向服务的架构松散耦合。
我建议查看 Thomas Erl 的 SOA 图书系列。它非常清楚和深入地解释了一切。
What you're asking isn't an easy topic. There are many ways you can go about making your Service Oriented Architecture loosely coupled.
I suggest checking out Thomas Erl's SOA book series. It explains everything pretty clearly and in-depth.
有一些常见的做法可以实现服务的松耦合。
使用文档/文字风格的 Web 服务，以数据（有线格式）而不是 RPC 来思考，避免基于模式的数据绑定。
发送数据时严格遵守契约，但在处理传入数据时保留很少的假设，xpath 是一个很好的工具（宽松，严格）
使用 ESB 并避免服务之间任何直接的点对点通信。
There are a few common pratices to achieve loose coupling for services.
Use doc/literal style of web services, think in data (the wire format) instead of RPC, avoid schema-based data binding.
Abide strictly by the contract when sending out data, but keep few assumptions processing incoming data, xpath is a good tool for that (loose in, tight out)
Use ESB and avoid any directly point to point communication between services.
以下是评估您的 SOA 是否实现松散耦合的粗略清单：
被调用系统的位置（其物理地址）：您的 SOA 是否 实现了松散耦合？
应用程序使用直接 URL 来访问系统，或者是
应用程序通过负责的抽象层解耦
用于维持系统之间的连接？服务注册处
SAP NetWeaver CE 中使用的服务组范例很好
这种抽象可能是什么样子的例子。使用
企业服务总线（ESB）是另一个例子。重点是
应用程序不应硬编码物理地址
被调用系统才能真正被视为松散耦合。
接收器数量：应用程序是否指定哪些系统是
服务呼叫的接收者？松散耦合的复合材料不会
指定特定系统，但将保留其交付
到服务契约实现层的消息。紧紧地
耦合应用程序将显式调用接收系统
命令;松散耦合的应用程序只需调用
服务接口并允许服务契约的实现
层负责将消息传递到右侧的细节
系统。
系统的可用性：您的应用程序是否要求所有
您正在连接的系统是否始终启动并运行？
显然，这是一个非常困难的要求，尤其是如果您
想要连接到不受您控制的外部系统。
如果答案是所有系统必须一直运行，那么
应用程序在这方面是紧密耦合的。
数据格式：应用程序是否重复使用由
后端系统或者您是否使用规范数据类型系统
独立于被调用中使用的类型系统
应用程序？如果你要复用后端的数据类型
系统中，您可能不得不努力处理数据类型转换
您的应用程序，这不是一种非常松散耦合的方法。
响应时间：应用程序是否需要被调用的系统响应
在一定的时间范围内或者应用程序是否可以接受
在几分钟、几小时甚至几天后收到答复？
Here is a rough checklist for evaluating whether your SOA implements Loose Coupling:
Location of the called system (its physical address): Does your
application use direct URLs for accessing systems or is the
application decoupled via an abstraction layer that is responsible
for maintaining connections between systems? The Services Registry
and the service group paradigm used in SAP NetWeaver CE are good
examples of what such an abstraction might look like. Using an
enterprise service bus (ESB) is another example. The point is that
the application should not hard code the physical address of the
called system in order to truly be considered loosely coupled.
Number of receivers: Does the application specify which systems are
the receivers of a service call? A loosely coupled composite will not
specify particular systems but will leave the delivery of its
messages to a service contract implementation layer. A tightly
coupled application will explicitly call the receiving systems in
order; a loosely coupled application simply makes calls to the
service interface and allows the service contract implementation
layer to take care of the details of delivering messages to the right
systems.
Availability of systems: Does your application require that all the
systems that you are connecting to be up and running all the time?
Obviously, this is a very difficult requirement especially if you
want to connect to external systems that are not under your control.
If the answer is that all systems must be running all the time, the
application is tightly coupled in this regard.
Data format: Does the application reuse the data formats provided by
the backend systems or are you using a canonical data type system
that is independent of the type systems used in the called
applications? If you are reusing the data types of the backend
systems, you probably have to struggle with data type conversions in
your application, and this is not a very loosely coupled approach.
Response time: Does the application require called systems to respond
within a certain timeframe or is it acceptable for the application to
receive an answer minutes, hours, or even days later?