你前面不是说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

其实不管在企业内部还是企业之间，企业应用的集成不可能是一成不变的。
企业的业务需求需要满足客户的需要，所以需要不断有新的服务推出适应
业务的变化。
如何将现有的服务和新的服务只能的集合在一起，不管是新的服务，开始已经存在的服务
都可以使用统一的方式访问企业应用系统的统一服务框架应该是企业首先考虑的问题。
应用集成不是逸劳永逸的事情，但是我们可以使用我们的智慧帮助企业将服务变得更智能。
【 在 ldlc (考试) 的大作中提到: 】
: 其实在一个局部范围内用数据库来管理web服务已经可以了
: 但uddi作为业界标准,其扩展性显然要高于数据库.
--
FROM 61.149.192.19