1

也许我不完全理解UDDI的全部内容，但我正在考虑一种在一个服务器上发布所有提供的服务的技术？

通过“服务器”，我应该理解物理地址（如www.example.com）还是只是编程工具（例如谈论 NuSOAP 一个 PHP 文件，包括nusoap.php）？

因此，如果服务器只是 PHP 文件，则附加?wsdl到该文件将为我提供所有已注册函数的列表。这已经是所谓的 UDDI 了吗？

最后，NuSOAP 是否支持 UDDI？

4

1 回答 1

2

看来您有些事情混淆了，所以让我们尝试消除一些混乱。首先是一些定义！

Web 服务是一种允许机器对机器通信的方式。当您通过网络公开一些操作时，您就创建了一个 Web 服务。其他机器使用这些操作与您的机器“对话”，它们成为您的 Web 服务的客户端。客户端从您的 Web 服务请求信息，据说他们“使用”您的 Web 服务。当然，没有提供者就不能拥有消费者，所以你有一个网络服务“提供者”。

但是机器怎么知道如何相互交谈呢？

SOAP是一种用于交换信息的协议。它通过将消息包装在标准信封 + 标题 + 正文请求中来定义讨论的共同基础（机器使用相同的语言）。

但是消息本身呢？那是怎么定义的？当您公开 Web 服务时，您必须告诉其他人如何实现客户端（即记录您的操作，以及要发送或期望返回的消息）。您可以使用 PDF 来执行此操作，例如详细说明操作、消息格式、参数类型等。但是有一种更好的方法，允许您动态生成客户端：WSDL（按照约定可从添加?wsdlWeb 服务端点地址）。

WSDL提供了一个机器可读的描述，描述了如何调用服务、它期望什么参数以及它返回什么（基本上你必须遵守什么契约才能调用它）。有一些工具可以读取 WSDL 并为您的 Web 服务客户端创建代码或提供实用功能，使您可以更轻松地调用 Web 服务，而无需对消息进行低级操作。

NuSOAP就是这样一个工具。它是一组允许您使用 SOAP Web 服务的 PHP 类。

但是，在您拥有执行呼叫所需的一切之后，您如何知道您可以拨打该呼叫的 Web 服务地址在哪里？

作为提示，您可以在 WSDL 中找到它，但这并不总是可靠的，因此您必须从 Web 服务提供商处获取它。然后，您使用该地址一次又一次地调用 Web 服务。

但是，如果提供商对其基础设施进行了一些更改，而现在 Web 服务暴露在另一个地址上怎么办？您的客户端不再工作，因为它连接到旧地址。您必须再次从提供商处获取地址。如果您可以在运行时以某种方式发现此地址然后连接到 Web 服务，那不是更容易吗？

如果提供商在不同地址多次公开相同的服务（作为备份）怎么办？您可以连接到其中一个，如果出现问题，您可以搜索另一个公开相同合同的 Web 服务。

但是，如果我们谈论的是合同，为什么要将自己限制在一个供应商上呢？无论提供者如何，为什么不搜索公开特定合同的服务？.... 在这一点上，事情有点失控，因为人们想象一个世界，通过使用一个充当黄色（实际上是三种颜色）Web 服务页面的注册表，服务将自发地相互连接。

UDDI是一个注册中心，生产者注册他们的 Web 服务，而消费者查询注册中心以查找具有特定合同的 Web 服务，然后连接到他们找到的内容。交互是这样的：

在此处输入图像描述
http://juddi.apache.org/docs/3.x/userguide/html/chap-UDDI_Registry.html

这个想法在定义合同并创建实现的企业内部很有效，并且所有 Web 服务都具有已知的质量和功能。但是在网上是不行的。

如果没有适当的先验测试和验证，以及保证 Web 服务不会向不希望的方向发展或完全停止发展的东西，就没有适当的方法来验证服务是否真的在做它所宣传的事情.

因此，（公共）UDDI 实际上并没有在野外使用，而是在企业中有所使用，因为企业签署了定义规则的合同，以保证您从（私有）UDDI 得到的东西是真实的.

总之（以确保我完全解决了您的问题）UDDI 是提供者发布有关其 Web 服务的信息的地方。这包括规范、接口等，还有端点地址。它只是有关 Web 服务的信息，而不是 Web 服务本身，因此nusoap.php不会发布到注册表。

至于支持 UDDI 的 NuSOAP，不清楚您对此有何理解。UDDI 可通过 SOAP API 访问，因此您可以使用 NuSOAP 来简化对它的访问，如果您需要的话。

于 2013-02-08T22:02:22.753 回答