☆─────────────────────────────────────☆
tellmewhy (tellmewhy) 于 (Tue Oct 14 11:37:46 2003) 提到:
最近几天才具体接触UDDI这个东西,感觉UDDI侧重于商业应用的,不知我的理解对否.
我们的项目属于政府部门项目(关键是客户提出使用UDDI),感觉UDDI一些特性没什么用,
如果只为了简单发布WebService供其他部门调用,使用UDDI作为发布中心是不是有点多余??
如果是这样,也许应该引导一下客户,让他们放弃幻想
☆─────────────────────────────────────☆
tellmewhy (tellmewhy) 于 (Tue Oct 14 11:52:46 2003) 提到:
关键我感觉政府部门间服务的互相调用基本都是互相已知的,而不会去自动"发现",
所以UDDI的Discovery特性没什么用了,那么使用UDDI是不是会有点画蛇添足.
当然,如果能因此挣到客户的￥另说了:)
【 在 tellmewhy (tellmewhy) 的大作中提到: 】
: 最近几天才具体接触UDDI这个东西,感觉UDDI侧重于商业应用的,不知我的理解对否.
: 我们的项目属于政府部门项目(关键是客户提出使用UDDI),感觉UDDI一些特性没什么用,
: 如果只为了简单发布WebService供其他部门调用,使用UDDI作为发布中心是不是有点多余??
: 如果是这样,也许应该引导一下客户,让他们放弃幻想
☆─────────────────────────────────────☆
ldlc (考试) 于 (Tue Oct 14 13:53:16 2003) 提到:
其实在一个局部范围内用数据库来管理web服务已经可以了
但uddi作为业界标准,其扩展性显然要高于数据库.
【 在 tellmewhy (tellmewhy) 的大作中提到: 】
: 关键我感觉政府部门间服务的互相调用基本都是互相已知的,而不会去自动"发现",
: 所以UDDI的Discovery特性没什么用了,那么使用UDDI是不是会有点画蛇添足.
: 当然,如果能因此挣到客户的￥另说了:)
☆─────────────────────────────────────☆
tellmewhy (tellmewhy) 于 (Tue Oct 14 15:47:44 2003) 提到:
同意
【 在 ldlc (考试) 的大作中提到: 】
: 其实在一个局部范围内用数据库来管理web服务已经可以了
: 但uddi作为业界标准,其扩展性显然要高于数据库.
☆─────────────────────────────────────☆
nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 于 (Wed Oct 15 15:35:49 2003) 提到:
UDDI技术的产生本来就是靠B2B驱动的
Web Service不过是借用了而已（可以这么说吧：P）
它相当于一个黄页级的轻量级目录服务
我个人觉得在电子商务和电子政务中使用UDDI
是个不错的选择。因为具有一定的可扩展性
比如：accesspoint 可以是一个web服务的url
也可以是一个人工热线服务的电话号码
【 在 tellmewhy (tellmewhy) 的大作中提到: 】
: 最近几天才具体接触UDDI这个东西,感觉UDDI侧重于商业应用的,不知我的理解对否.
: 我们的项目属于政府部门项目(关键是客户提出使用UDDI),感觉UDDI一些特性没什么用,
: 如果只为了简单发布WebService供其他部门调用,使用UDDI作为发布中心是不是有点多余??
: 如果是这样,也许应该引导一下客户,让他们放弃幻想
☆─────────────────────────────────────☆
ldlc (考试) 于 (Wed Oct 15 15:52:22 2003) 提到:
问个问题,uddi如何和语义结合起来? 现在的uddi无法描述服务的语义信息
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: UDDI技术的产生本来就是靠B2B驱动的
: Web Service不过是借用了而已（可以这么说吧：P）
: 它相当于一个黄页级的轻量级目录服务
: 我个人觉得在电子商务和电子政务中使用UDDI
: 是个不错的选择。因为具有一定的可扩展性
: 比如：accesspoint 可以是一个web服务的url
: 也可以是一个人工热线服务的电话号码
☆─────────────────────────────────────☆
nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 于 (Wed Oct 15 15:55:33 2003) 提到:
现在流行的做法是使用语义web来对一个服务的功能进行描述
使用DAML-S，从而可以对web service实行动态发现。
这是我们最近正在研究的课题
【 在 ldlc (考试) 的大作中提到: 】
: 问个问题,uddi如何和语义结合起来? 现在的uddi无法描述服务的语义信息
☆─────────────────────────────────────☆
ldlc (考试) 于 (Wed Oct 15 20:48:49 2003) 提到:
那uddi还起什么作用?
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 现在流行的做法是使用语义web来对一个服务的功能进行描述
: 使用DAML-S，从而可以对web service实行动态发现。
: 这是我们最近正在研究的课题
☆─────────────────────────────────────☆
nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 于 (Wed Oct 15 20:51:39 2003) 提到:
还是起到目录服务的功能啊
只是它里面的信息是机器可理解的啊
【 在 ldlc (考试) 的大作中提到: 】
: 那uddi还起什么作用?
☆─────────────────────────────────────☆
ldlc (考试) 于 (Wed Oct 15 20:53:05 2003) 提到:
uddi 里面不是绑定到wsdl上面吗?wsdl时没有办法描述语义的啊?
如何绑定到daml-s?
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 还是起到目录服务的功能啊
: 只是它里面的信息是机器可理解的啊
☆─────────────────────────────────────☆
nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 于 (Wed Oct 15 21:03:33 2003) 提到:
目前WSDL只是提供接口绑定信息的定义
有点象CORBA里面的IDL
关于功能的定义可放在UDDI中某个Service的description里面
所以，必须是人工查找
因为机器不能理解这些信息
【 在 ldlc (考试) 的大作中提到: 】
: uddi 里面不是绑定到wsdl上面吗?wsdl时没有办法描述语义的啊?
: 如何绑定到daml-s?
☆─────────────────────────────────────☆
ldlc (考试) 于 (Wed Oct 15 21:16:26 2003) 提到:
你前面不是说uddi的信息是机器可理解的吗?
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 目前WSDL只是提供接口绑定信息的定义
: 有点象CORBA里面的IDL
: 关于功能的定义可放在UDDI中某个Service的description里面
: 所以，必须是人工查找
: 因为机器不能理解这些信息
☆─────────────────────────────────────☆
nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 于 (Wed Oct 15 21:23:08 2003) 提到:
我是说采用语义web的web service的描述
呵呵，目前的UDDI没有这个功能
【 在 ldlc (考试) 的大作中提到: 】
: 你前面不是说uddi的信息是机器可理解的吗?
☆─────────────────────────────────────☆
ldlc (考试) 于 (Wed Oct 15 21:26:18 2003) 提到:
那就是说用了daml,就要抛弃uddi了?我一直想还是能利用uddi
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 我是说采用语义web的web service的描述
: 呵呵，目前的UDDI没有这个功能
☆─────────────────────────────────────☆
nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 于 (Wed Oct 15 21:35:01 2003) 提到:
不是这个意思
目前UDDI中关于服务的功能性描述是直接通过文字描述的
所以只有人可以理解，机器很难理解
以后可能的描述方式是：用DAML+S来描述一个服务的功能性信息
同样这些信息还是保留在UDDI中，但是这种描述机器可理解
【 在 ldlc (考试) 的大作中提到: 】
: 那就是说用了daml,就要抛弃uddi了?我一直想还是能利用uddi
☆─────────────────────────────────────☆
ldlc (考试) 于 (Wed Oct 15 21:37:22 2003) 提到:
越来越接近我的目标了,呵呵, 关键是uddi如何保留功能性信息, 而且接口信息也是
需要语义描述的,你怎么保留, 本体如何在uddi查找时起作用?
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
不是这个意思
目前UDDI中关于服务的功能性描述是直接通过文字描述的
所以只有人可以理解，机器很难理解
以后可能的描述方式是：用DAML+S来描述一个服务的功能性信息
同样这些信息还是保留在UDDI中，但是这种描述机器可理解
【 在 ldlc (考试) 的大作中提到: 】
: 那就是说用了daml,就要抛弃uddi了?我一直想还是能利用uddi
☆─────────────────────────────────────☆
nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 于 (Wed Oct 15 21:42:43 2003) 提到:
接口信息相对比较固定
有WSDL足够了
为什么需要语义描述呢
拿到一个WSDL文件，就可以实现对一个服务的动态调用啊
【 在 ldlc (考试) 的大作中提到: 】
: 越来越接近我的目标了,呵呵, 关键是uddi如何保留功能性信息, 而且接口信息也是
: 需要语义描述的,你怎么保留, 本体如何在uddi查找时起作用?
: 不是这个意思
: 目前UDDI中关于服务的功能性描述是直接通过文字描述的
: 所以只有人可以理解，机器很难理解
: 以后可能的描述方式是：用DAML+S来描述一个服务的功能性信息
: 同样这些信息还是保留在UDDI中，但是这种描述机器可理解
☆─────────────────────────────────────☆
ldlc (考试) 于 (Wed Oct 15 22:03:38 2003) 提到:
接口也涉及到语义的问题,假设我一个服务的输入参数叫notebookID,服务匹配时如果没有
语义会出错的.
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 接口信息相对比较固定
: 有WSDL足够了
: 为什么需要语义描述呢
: 拿到一个WSDL文件，就可以实现对一个服务的动态调用啊
☆─────────────────────────────────────☆
nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 于 (Wed Oct 15 22:06:37 2003) 提到:
建议看看IBM的WSIF
你说的应该不成为问题的
【 在 ldlc (考试) 的大作中提到: 】
: 接口也涉及到语义的问题,假设我一个服务的输入参数叫notebookID,服务匹配时如果没有
: 语义会出错的.
☆─────────────────────────────────────☆
hawker (Hooofer) 于 (Wed Oct 15 23:53:40 2003) 提到:
其实不管在企业内部还是企业之间，企业应用的集成不可能是一成不变的。
企业的业务需求需要满足客户的需要，所以需要不断有新的服务推出适应
业务的变化。
如何将现有的服务和新的服务只能的集合在一起，不管是新的服务，开始已经存在的服务
都可以使用统一的方式访问企业应用系统的统一服务框架应该是企业首先考虑的问题。
应用集成不是逸劳永逸的事情，但是我们可以使用我们的智慧帮助企业将服务变得更智能。
【 在 ldlc (考试) 的大作中提到: 】
: 其实在一个局部范围内用数据库来管理web服务已经可以了
: 但uddi作为业界标准,其扩展性显然要高于数据库.
☆─────────────────────────────────────☆
yanzhang (swallow) 于 (Fri Dec 5 13:11:56 2003) 提到:
/UDDI有本地和公用之分
【 在 tellmewhy (tellmewhy) 的大作中提到: 】
: 最近几天才具体接触UDDI这个东西,感觉UDDI侧重于商业应用的,不知我的理解对否.
: 我们的项目属于政府部门项目(关键是客户提出使用UDDI),感觉UDDI一些特性没什么用,
: 如果只为了简单发布WebService供其他部门调用,使用UDDI作为发布中心是不是有点多余??
: 如果是这样,也许应该引导一下客户,让他们放弃幻想