- 主题:问一个UDDI的问题
其实在一个局部范围内用数据库来管理web服务已经可以了
但uddi作为业界标准,其扩展性显然要高于数据库.
【 在 tellmewhy (tellmewhy) 的大作中提到: 】
: 关键我感觉政府部门间服务的互相调用基本都是互相已知的,而不会去自动"发现",
: 所以UDDI的Discovery特性没什么用了,那么使用UDDI是不是会有点画蛇添足.
: 当然,如果能因此挣到客户的￥另说了:)
--
FROM 159.226.40.3
问个问题,uddi如何和语义结合起来? 现在的uddi无法描述服务的语义信息
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: UDDI技术的产生本来就是靠B2B驱动的
: Web Service不过是借用了而已（可以这么说吧：P）
: 它相当于一个黄页级的轻量级目录服务
: 我个人觉得在电子商务和电子政务中使用UDDI
: 是个不错的选择。因为具有一定的可扩展性
: 比如：accesspoint 可以是一个web服务的url
: 也可以是一个人工热线服务的电话号码
--
FROM 159.226.40.3
那uddi还起什么作用?
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 现在流行的做法是使用语义web来对一个服务的功能进行描述
: 使用DAML-S，从而可以对web service实行动态发现。
: 这是我们最近正在研究的课题
--
FROM 159.226.40.3
uddi 里面不是绑定到wsdl上面吗?wsdl时没有办法描述语义的啊?
如何绑定到daml-s?
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 还是起到目录服务的功能啊
: 只是它里面的信息是机器可理解的啊
--
FROM 159.226.40.3
你前面不是说uddi的信息是机器可理解的吗?
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 目前WSDL只是提供接口绑定信息的定义
: 有点象CORBA里面的IDL
: 关于功能的定义可放在UDDI中某个Service的description里面
: 所以，必须是人工查找
: 因为机器不能理解这些信息
--
FROM 159.226.40.3
那就是说用了daml,就要抛弃uddi了?我一直想还是能利用uddi
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 我是说采用语义web的web service的描述
: 呵呵，目前的UDDI没有这个功能
--
FROM 159.226.40.3
越来越接近我的目标了,呵呵, 关键是uddi如何保留功能性信息, 而且接口信息也是
需要语义描述的,你怎么保留, 本体如何在uddi查找时起作用?
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
不是这个意思
目前UDDI中关于服务的功能性描述是直接通过文字描述的
所以只有人可以理解，机器很难理解
以后可能的描述方式是：用DAML+S来描述一个服务的功能性信息
同样这些信息还是保留在UDDI中，但是这种描述机器可理解
【 在 ldlc (考试) 的大作中提到: 】
: 那就是说用了daml,就要抛弃uddi了?我一直想还是能利用uddi
--
FROM 159.226.40.3
接口也涉及到语义的问题,假设我一个服务的输入参数叫notebookID,服务匹配时如果没有
语义会出错的.
【 在 nobodyelse (空无一人||为什么我一玩杀人游戏就断网) 的大作中提到: 】
: 接口信息相对比较固定
: 有WSDL足够了
: 为什么需要语义描述呢
: 拿到一个WSDL文件，就可以实现对一个服务的动态调用啊
--
FROM 159.226.40.3