我觉得
1。其实UDDI注册的时候必填的字段还是不多的。
而且最核心的内容都在WSDL里面，在UDDI中只要
给出了一WSDL的URL就可以了。而WSDL有不少自动
生成的工具。
2。首先，UDDI只能算是一个轻量级的目录服务。
其次，根据不同的业务需求可以选择不同的UDDI
一般来说，企业内部或者某一局域范围内，Private
UDDI就足够用了。PUBLIC UDDI全球也就MS，IBM
HP等大公司提供。而且还是免费的，干嘛不直接用呢：）
3。如果是新添一个服务。一个熟悉WS架构的CODER，部署
了服务却忘记发布在UDDI，老大，这有点说不过去吧。：）
如果是更新一个服务。按照一般的软件规范来说，不论
业务逻辑怎么改变，暴露给外面的接口应该是不变的。
也就是说对客户端是透明的。这个就不存在你刚刚说的问题。
呵呵，说了这么多。并不是说现在的架构就是完美无缺的了
只是没有想出更好的来之前，只能用这个了
欢迎大家集思广益：D

【 在 bbhs (The_Blue_Sea) 的大作中提到: 】
: 在web services的三角模型中，包括provider,requester,broker。一个用户如果想让外界访问自己提供的web服务，必须到broker的uddi注册中心进行注册，否则用户提供的服务也只能够自己使用。我觉得这种方式有以下不足：
: 1。注册过程的繁琐
: 一个用户或者企业开发出自己的web服务以后必须到uddi注册中心（即broker)进行注册，并且用户在注册的时候必须填写大量信息，包括基本信息、提供的服务信息。。。对于一个企业来说可能更乐意去填写这些信息，这是对公司的一次宣传机会，但对于想提供一定web服务的个人来
: 2。海量的数据存储（uddi注册中心）
: 目前的uddi注册中心分了好几个入口，用户可以在任何一个入口进行注册，各个uddi中心采用p2p的方式，访问其中任何一个就相当于访问了所有的uddi这册中心。如果考虑到将来普通的用户也有可能提供web服务，那么web服务的数量级别将会是很大的。如何维护这么大量的数据和在
: 3。更新的不灵活性
: 在三角模型中，用户如果新增加服务或者服务的描述文件发生改变，那么用户必须到uddi注册中心更新相应的资料才能反映这种变化，那么如果用户没有即时更新或者忘记了更新将会出现怎样的情况呢？
: 以上是个人观点，欢迎大家讨论！
--
FROM 202.197.125.175