最近几天才具体接触UDDI这个东西,感觉UDDI侧重于商业应用的,不知我的理解对否.

我们的项目属于政府部门项目(关键是客户提出使用UDDI),感觉UDDI一些特性没什么用,
如果只为了简单发布WebService供其他部门调用,使用UDDI作为发布中心是不是有点多余??

如果是这样,也许应该引导一下客户,让他们放弃幻想
--
修改:tellmewhy FROM 166.111.218.67
FROM 166.111.218.67

其实在一个局部范围内用数据库来管理web服务已经可以了

但uddi作为业界标准,其扩展性显然要高于数据库.

【 在 tellmewhy (tellmewhy) 的大作中提到: 】
: 关键我感觉政府部门间服务的互相调用基本都是互相已知的,而不会去自动"发现",
: 所以UDDI的Discovery特性没什么用了,那么使用UDDI是不是会有点画蛇添足.
: 当然,如果能因此挣到客户的￥另说了:)
--
FROM 159.226.40.3

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