也许我不完全理解UDDI的全部内容,但我正在考虑一种在一个服务器上发布所有提供的服务的技术?
通过“服务器”,我应该理解物理地址(如www.example.com
)还是只是编程工具(例如谈论 NuSOAP 一个 PHP 文件,包括nusoap.php
)?
因此,如果服务器只是 PHP 文件,则附加?wsdl
到该文件将为我提供所有已注册函数的列表。这已经是所谓的 UDDI 了吗?
最后,NuSOAP 是否支持 UDDI?
看来您有些事情混淆了,所以让我们尝试消除一些混乱。首先是一些定义!
Web 服务是一种允许机器对机器通信的方式。当您通过网络公开一些操作时,您就创建了一个 Web 服务。其他机器使用这些操作与您的机器“对话”,它们成为您的 Web 服务的客户端。客户端从您的 Web 服务请求信息,据说他们“使用”您的 Web 服务。当然,没有提供者就不能拥有消费者,所以你有一个网络服务“提供者”。
但是机器怎么知道如何相互交谈呢?
SOAP是一种用于交换信息的协议。它通过将消息包装在标准信封 + 标题 + 正文请求中来定义讨论的共同基础(机器使用相同的语言)。
但是消息本身呢?那是怎么定义的?当您公开 Web 服务时,您必须告诉其他人如何实现客户端(即记录您的操作,以及要发送或期望返回的消息)。您可以使用 PDF 来执行此操作,例如详细说明操作、消息格式、参数类型等。但是有一种更好的方法,允许您动态生成客户端:WSDL(按照约定可从添加?wsdl
Web 服务端点地址)。
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 来简化对它的访问,如果您需要的话。