不能单独依靠UDDI，思路还是纠缠在Session Layer层的LDAP，看来有点悬！

对比微软.net实现的着力点在Application Layer的ARPA Services协议族，兼顾了实现，


所以才做出了实际的诸如MSN之Passport等典范Web Service应用实体。
--
FROM 61.48.32.*

XML是UDDI的基础，对XML的实现.net家是应用在Application Laye。

其他方案的集中在Session Layer。

【 在 edithwy (风烛) 的大作中提到: 】
: 没太明白第一句话的意思
: 是说可以用LDAP来实现类似UDDI的机制吗？
:
: 【 在 AdamGet (Adam) 的大作中提到: 】
: :
: : 不能单独依靠UDDI，思路还是纠缠在Session Layer层的LDAP，看来有点悬！
: :
: : 对比微软.net实现的着力点在Application Layer的ARPA Services协议族，兼顾了..
: :
: :
: ...................
--
FROM 61.48.32.*

我也很疑惑，觉得LDAP和UDDI不是一回事，UDDI只是
关于服务信息的，而且走得是SOAP协议。
LDAP是直接在TCP上面的，效率比较高，它一般是关于
网络资源信息的，
二者在效率上，在查询功能方面，是否LDAP具有绝对优势呢？
是否存在一种可能，把二者统一起来，包含应用所需的所有信息呢？

资料上UDDI支持调用Web Services，说bindingTemplate里面包含的
URL可以指向一个调用规范文本，是否可以在这个文本里面说明
服务参数信息呢？
另外，好像w3c有个(OWL-S)DAML-S，里面的ServiceProfile定义文件，包括
对服务输入、输出等参数的名字、相关信息，在发布服务时，就需要
对wsdl中的操作和这些参数信息进行关联，这样调用服务时可以
生成ServiceProfile文件。利用这个文件提供参数匹配信息。

我也只是看了一点资料，说的不对之处，请多商榷
【 在 edithwy (风烛) 的大作中提到: 】
: 刚开始接触UDDI，看了些资料，可是一直觉得它就是一个服务信息的注册和查找，那么是
: 否可以用LDAP来定义一个结构描述它呢？
: 看资料上写的是它可以支持调用Web Service，可是看了半天，也就发现能通过查找绑定信
: 息来获取WSDL，这样的话我的程序将WSDL转为类以后，需要输入参数，可是如果没有人工
: 来参与的话，又怎么知道该输入什么参数呢，这样怎么能够让程序自动去调用返回需要的
: 结果呢，我不知道怎么才能事先开发好程序，自动的查找UDDI找到需要的服务并返回结果
: 呢？怎么才能使程序知道这些WSDL里定义的操作需要什么输入参数，如何来和用户的事先
: 输入进行匹配呢？我觉得UDDI好象做不到
: 请熟悉的人指教！多谢！
--
修改:rosydusk FROM 166.111.68.*
FROM 166.111.68.*

UDDI不管服务调用的具体事情，你可以自己编写程序，解析UDDI获取的WSDL文件，得到
输入输出参数什么的，不知道我说的对不对，呵呵

【 在 edithwy (风烛) 的大作中提到: 】
: 刚开始接触UDDI，看了些资料，可是一直觉得它就是一个服务信息的注册和查找，那么是
: 否可以用LDAP来定义一个结构描述它呢？
: 看资料上写的是它可以支持调用Web Service，可是看了半天，也就发现能通过查找绑定信
: 息来获取WSDL，这样的话我的程序将WSDL转为类以后，需要输入参数，可是如果没有人工
: 来参与的话，又怎么知道该输入什么参数呢，这样怎么能够让程序自动去调用返回需要的
: 结果呢，我不知道怎么才能事先开发好程序，自动的查找UDDI找到需要的服务并返回结果
: 呢？怎么才能使程序知道这些WSDL里定义的操作需要什么输入参数，如何来和用户的事先
: 输入进行匹配呢？我觉得UDDI好象做不到
: 请熟悉的人指教！多谢！
--
FROM 159.226.40.*

LDAP目录服务器的目录结构主要面向物理资源，
UDDI直接面向上层电子商务的，
但是我觉得有些大的应用对这些信息都是有需求的。
对不对？
【 在 nobodyelse (空无一人|水木第二错别字大王) 的大作中提到: 】
: 其实UDDI和LDAP都是目录服务器
: 只是应用的领域不同才造就了他们的差异
: 也是就是说，各自的特点都是为了适用于其本身的应用领域
: ：）
--
FROM 166.111.68.*