Web services SOA中的服务可发现性

我在看一张关于SOA的幻灯片。并且在这一点上有疑问：

Discoverability is beyond the scope of a Web Service

这是否意味着Web服务不负责发现部分？我的意思是服务提供商将他们的Web服务提交到服务注册中心，以便客户端可以发现它，不是吗？这就是那一点的意思吗

---

如果他们在谈论在服务注册中心（即UDDI）之间发现服务的可能性，那是对的，服务不需要知道任何关于可发现性部分的信息。但是请记住，该服务有一个公开其元数据的契约，这是发布到服务注册中心的数据。 图形说明：

看看这张摘自迈克尔·普林（MichaelPoulin）的帖子的便条，这是我一开始试图解释的

现在谈到服务可发现性原则，我可以作证 这是唯一一个幸存下来的原则，但没有 发生了重大变化。托马斯·厄尔（Thomas Erl）谈到这一原则：“这 服务导向原则与， 在体系结构级别上的可发现性。。。在服务级别上 可发现性原则是指个体的设计 服务，使其变得尽可能可发现，而不考虑 可发现性产品或扩展是否实际存在于其 “周边实施环境”

原则定义很好地指出了两件非常重要的事情 对服务发现很重要：补充元数据和 可以有效解释服务的元数据。我是 重新表述原则以指向元数据文档 补充服务并添加到此类服务的注册表/存储库 文件。而注册表/存储库是基础架构的一个元素 并且可能缺席，补充元数据文件到期。绿洲 SOA RM标准将此类文档标识为“服务描述”。

---

这是完全正确的，除了几乎没有人使用UDDI，当然也没有公共UDDI注册中心。“这是一个好主意，但它的时机永远不会到来。”约翰萨默斯完全同意。服务发现机制的想法仍然是完全有效的，即：Netflix Curator（现在搬到Apache）我从事SOA已有一段时间了，从未需要“发现”服务。如果我不知道这项服务，那我为什么要打电话给它？为什么我们还不知道它在哪里？如果我们移动服务，那么我们只需要一种机制来管理服务URL中的更改。这不需要发现机制。嗯，我认为这取决于您的体系结构的大小和性质，在某些情况下，如果没有服务发现机制，就不可能继续下去，这是对真实案例的一个极好的描述：抱歉，还没有看到负载平衡不起作用的情况。我知道有一些案例使用了一种简单的服务定位机制，客户机根据某些标准查找要使用的端点，但是使用了一种完整的“服务发现”机制——不是。那篇文章似乎预先假定了发现的需要。