我在一个大型组织SOA原型组织中担任实习生应用程序开发人员.我是Web服务和技术的新手,如WSDL,SOAP,UDDI等.
在过去的一周里,我在理解UDDI以及如何有效地使用UDDI方面遇到了很多困难.互联网上普遍的共识是,UDDI已经死了,要么太复杂,要么不需要,要么就是大多数用例的障碍.一些网站暗示UDDI仅作为组织内部的注册表使用,而且它是密切的业务合作伙伴,而不是它所设计的通用业务注册中心.您可以通过阅读以下问题的一些答案和评论来了解StackOverflow对UDDI的态度:
UDDI有哪些替代方案？Web服务可以发布的其他方式是什么,以便开发人员可以找到描述和技术细节,而不具备UDDI似乎具有的任何复杂性？实际使用UDDI注册中心有什么好的商业案例吗？
我目前正在尝试掌握UDDI,并希望使用查询API运行一些示例,但我找不到可以使用SOAP消息查询的公共注册表.
几年前,IBM,Microsoft和SAP用于托管公共UDDI服务器,但已经停止使用.
我知道xmethods包含一个公开可用的Web服务列表,但我想只关注使用UDDI发现Web服务(之后并不真正调用服务).
有没有人知道任何可用的公共UDDI注册管理机构？
我听说人们在Web服务的上下文中使用首字母缩略词UDDI,但我不清楚它在Web服务中扮演什么角色.我已经阅读了由Martin Kalin 撰写的Java Web Services Up and Running一书,它几乎没有在任何地方提及UDDI.
根据我对网的理解:
UDDI(通用描述,发现和集成)是一种基于XML的注册表,适用于全球企业在Internet上列出自己的内容.它可以帮助公司在网上找到彼此,并呼叫他们的服务.基本上,通过UDDI,公司可以在Internet上注册/描述他们的Web服务,以便其他公司可以找到他们的WSDL并从中生成存根.
那是对的吗？假设我是一个Web服务的生产者,该服务适用于一组有限的用户.我没有注册UDDI,因为我可以手动给他们一个WSDL URL.正确？
UDDI本质上是一种类似于谷歌搜索的服务,消费者可以根据某些关键字搜索网络服务吗？