- 主题:问一个UDDI的问题
UDDI技术的产生本来就是靠B2B驱动的
Web Service不过是借用了而已（可以这么说吧：P）
它相当于一个黄页级的轻量级目录服务
我个人觉得在电子商务和电子政务中使用UDDI
是个不错的选择。因为具有一定的可扩展性
比如：accesspoint 可以是一个web服务的url
也可以是一个人工热线服务的电话号码
【 在 tellmewhy (tellmewhy) 的大作中提到: 】
: 最近几天才具体接触UDDI这个东西,感觉UDDI侧重于商业应用的,不知我的理解对否.
: 我们的项目属于政府部门项目(关键是客户提出使用UDDI),感觉UDDI一些特性没什么用,
: 如果只为了简单发布WebService供其他部门调用,使用UDDI作为发布中心是不是有点多余??
: 如果是这样,也许应该引导一下客户,让他们放弃幻想
--
FROM 202.197.125.175
现在流行的做法是使用语义web来对一个服务的功能进行描述
使用DAML-S，从而可以对web service实行动态发现。
这是我们最近正在研究的课题
【 在 ldlc (考试) 的大作中提到: 】
: 问个问题,uddi如何和语义结合起来? 现在的uddi无法描述服务的语义信息
--
FROM 202.197.125.175
还是起到目录服务的功能啊
只是它里面的信息是机器可理解的啊
【 在 ldlc (考试) 的大作中提到: 】
: 那uddi还起什么作用?
--
FROM 202.197.125.175
目前WSDL只是提供接口绑定信息的定义
有点象CORBA里面的IDL
关于功能的定义可放在UDDI中某个Service的description里面
所以，必须是人工查找
因为机器不能理解这些信息
【 在 ldlc (考试) 的大作中提到: 】
: uddi 里面不是绑定到wsdl上面吗?wsdl时没有办法描述语义的啊?
: 如何绑定到daml-s?
--
FROM 202.197.125.175
我是说采用语义web的web service的描述
呵呵，目前的UDDI没有这个功能
【 在 ldlc (考试) 的大作中提到: 】
: 你前面不是说uddi的信息是机器可理解的吗?
--
FROM 202.197.125.175
不是这个意思
目前UDDI中关于服务的功能性描述是直接通过文字描述的
所以只有人可以理解，机器很难理解
以后可能的描述方式是：用DAML+S来描述一个服务的功能性信息
同样这些信息还是保留在UDDI中，但是这种描述机器可理解
【 在 ldlc (考试) 的大作中提到: 】
: 那就是说用了daml,就要抛弃uddi了?我一直想还是能利用uddi
--
FROM 202.197.125.175
接口信息相对比较固定
有WSDL足够了
为什么需要语义描述呢
拿到一个WSDL文件，就可以实现对一个服务的动态调用啊
【 在 ldlc (考试) 的大作中提到: 】
: 越来越接近我的目标了,呵呵, 关键是uddi如何保留功能性信息, 而且接口信息也是
: 需要语义描述的,你怎么保留, 本体如何在uddi查找时起作用?
: 不是这个意思
: 目前UDDI中关于服务的功能性描述是直接通过文字描述的
: 所以只有人可以理解，机器很难理解
: 以后可能的描述方式是：用DAML+S来描述一个服务的功能性信息
: 同样这些信息还是保留在UDDI中，但是这种描述机器可理解
--
FROM 202.197.125.175
建议看看IBM的WSIF
你说的应该不成为问题的
【 在 ldlc (考试) 的大作中提到: 】
: 接口也涉及到语义的问题,假设我一个服务的输入参数叫notebookID,服务匹配时如果没有
: 语义会出错的.
--
FROM 202.197.125.175