- 主题:对web service三角模型的一点疑问
在web services的三角模型中，包括provider,requester,broker。一个用户如果想让外界访问自己提供的web服务，必须到broker的uddi注册中心进行注册，否则用户提供的服务也只能够自己使用。我觉得这种方式有以下不足：
1。注册过程的繁琐
一个用户或者企业开发出自己的web服务以后必须到uddi注册中心（即broker)进行注册，并且用户在注册的时候必须填写大量信息，包括基本信息、提供的服务信息。。。对于一个企业来说可能更乐意去填写这些信息，这是对公司的一次宣传机会，但对于想提供一定web服务的个人来说，是否很乐意填写这些信息呢？
2。海量的数据存储（uddi注册中心）
目前的uddi注册中心分了好几个入口，用户可以在任何一个入口进行注册，各个uddi中心采用p2p的方式，访问其中任何一个就相当于访问了所有的uddi这册中心。如果考虑到将来普通的用户也有可能提供web服务，那么web服务的数量级别将会是很大的。如何维护这么大量的数据和在大量数据中查找的反应速度也将会是一个大问题。
3。更新的不灵活性
在三角模型中，用户如果新增加服务或者服务的描述文件发生改变，那么用户必须到uddi注册中心更新相应的资料才能反映这种变化，那么如果用户没有即时更新或者忘记了更新将会出现怎样的情况呢？
以上是个人观点，欢迎大家讨论！
--
FROM 159.226.40.3
我觉得
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
现在大家采用web服务的目的就是为了共享，如果只是说企业内部使用那么是否采用web服务还是一个值得考虑的问题。并且一个coder并不一定就是web服务的发布者。我觉得web的使用方式就非常灵活，一个用户可以自己制作网页，如果外界访问（直接或者通过搜索引擎），但至少网站本身是一个完整的对象。
【 在 nobodyelse (空无一人|水木第二错别字大王) 的大作中提到: 】
: 我觉得
: 1。其实UDDI注册的时候必填的字段还是不多的。
: 而且最核心的内容都在WSDL里面，在UDDI中只要
: 给出了一WSDL的URL就可以了。而WSDL有不少自动
: 生成的工具。
: 2。首先，UDDI只能算是一个轻量级的目录服务。
: 其次，根据不同的业务需求可以选择不同的UDDI
: 一般来说，企业内部或者某一局域范围内，Private
: UDDI就足够用了。PUBLIC UDDI全球也就MS，IBM
: HP等大公司提供。而且还是免费的，干嘛不直接用呢：）
: 3。如果是新添一个服务。一个熟悉WS架构的CODER，部署
: ...................
--
FROM 159.226.40.3
企业内部应用可以是为了异构系统或平台的松散互操作
【 在 bbhs (The_Blue_Sea) 的大作中提到: 】
: 现在大家采用web服务的目的就是为了共享，如果只是说企业内部使用那么是否采用web服务还是一个值得考虑的问题。并且一个coder并不一定就是web服务的发布者。我觉得web的使用方式就非常灵活，一个用户可以自己制作网页，如果外界访问（直接或者通过搜索引擎），但至少网
--
FROM 202.197.125.175
另外
我说的那个CODER其实就是指服务的发布者：）
【 在 bbhs (The_Blue_Sea) 的大作中提到: 】
: 现在大家采用web服务的目的就是为了共享，如果只是说企业内部使用那么是否采用web服务还是一个值得考虑的问题。并且一个coder并不一定就是web服务的发布者。我觉得web的使用方式就非常灵活，一个用户可以自己制作网页，如果外界访问（直接或者通过搜索引擎），但至少网
--
FROM 202.197.125.175
按照这样理解也就是增加了一种企业应用集成的方案。但我觉得web服务更大的好处应该是企业间的，大家也许可以以web服务的方式接入虚拟组织，共同创造利益！
【 在 nobodyelse (空无一人|水木第二错别字大王) 的大作中提到: 】
: 企业内部应用可以是为了异构系统或平台的松散互操作
--
FROM 159.226.40.3
web service的本来目的就是是跨机器，跨平台，跨语言之间的过程调用
所以你说的这些肯定都是必须的
如果你觉得麻烦 何必要用web service 直接用程序里的API就行了
【 在 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 162.105.14.147
对企业间也可以
但是。。。没看出来哪有矛盾啊
【 在 bbhs (The_Blue_Sea) 的大作中提到: 】
: 按照这样理解也就是增加了一种企业应用集成的方案。但我觉得web服务更大的好处应该是企业间的，大家也许可以以web服务的方式接入虚拟组织，共同创造利益！
--
FROM 202.197.125.175
我觉得完全可以提供一个机制，在访问某个web服务的时候，到服务提供者自身的一个指定的地方去获取wsdl,比如新开一个确定的端口，如果访问此端口，则守护进程会把服务的描述文件发给请求者，而不用到uddi注册中心先进行查找。
【 在 nobodyelse (空无一人|水木第二错别字大王) 的大作中提到: 】
: 对企业间也可以
: 但是。。。没看出来哪有矛盾啊
--
FROM 159.226.40.3
那你开始是如何知道那个WEB服务提供者的？
【 在 bbhs (The_Blue_Sea) 的大作中提到: 】
: 我觉得完全可以提供一个机制，在访问某个web服务的时候，到服务提供者自身的一个指定的地方去获取wsdl,比如新开一个确定的端口，如果访问此端口，则守护进程会把服务的描述文件发给请求者，而不用到uddi注册中心先进行查找。
--
FROM 202.197.125.175