- 主题:web服务到底是啥?
其实webservice不仅仅是数据描述方式。
还支持服务发现等功能。
其实就是一个通用的协议,如果用二进制的方式来描述
xml一样可以达到目的。无非是易读性不好
不过业界标准就是这样的。既然制定了。自然就约束大家的行为了。如果发现使用的时候不贴切
应用的要求,就撇开罢了。。。
【 在 zixia (me.. me... me...) 的大作中提到: 】
: 没看我前面的说明,呵呵,自描述能力不是通过schema实现的吗?
: c struct 本身就是个 schema ?
--
FROM 61.48.32.145
嗯,服务发现是如何实现的?跟UPnP和JINI的服务发现有何区别?
俺对WebService一窍不通的说。
【 在 FrankCH (终有绿叶衬) 的大作中提到: 】
: 其实webservice不仅仅是数据描述方式。
: 还支持服务发现等功能。
: 其实就是一个通用的协议,如果用二进制的方式来描述
: xml一样可以达到目的。无非是易读性不好
: 不过业界标准就是这样的。既然制定了。自然就约束大家的行为了。如果发现使用的时候不贴切
: 应用的要求,就撇开罢了。。。
--
FROM 166.111.146.248
嗬嗬,这里就是适用范围的问题了
QQ使用的UDP针对其特性来的,报文小。。
如果一个企业应用,走大数据和安全通道。
又有多种服务器系统和软件系统要继承。。
又有一些Agent需要继承。用QQ协议死得更惨哦。
【 在 zixia (me.. me... me...) 的大作中提到: 】
: 按照thinboy的解释,那么XML唯一的优势就是 human readable 了。
: 呵呵,那就和我的想法一样了。
: 试想,如果QQ用的协议是SOAP+XML->WS的话,一定会死得很惨... :P
--
FROM 61.48.32.145
俺也是新手的说。嗬嗬。只是前一阵子做过一些方案。
摘一段文字吧。关于UDDI
Web服务基于开放的因特网标准,它的结构单元是SOAP、WSDL和UDDI。
UDDI(统一描述、发现和整合)建了一个平台独立、开放的框架,通过因特网来描述服务,发现业务,并且整合业务服务。它是一套基于Web的、分布式的、为Web服务提供的信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的Web服务注册以使得别的企业能够发现的
访问协议的实现标准。
通过使用UDDI的发现服务,企业可以单独注册那些希望被别的企业发现的自身提供的Web服务。企业可以通过UDDI商业注册中心的Web界面,或是使用实现了"UDDI Programmer's
API标准"所描述的编程接口的工具,来将信息加入到UDDI的商业注册中心。UDDI商业注册中心在逻辑上是集中的,在物理上是分布式的,由多个根节点组成,相互之间按一定规则进行数据同步。当一个企业在UDDI商业注册中心的一个实例中实施注册后,其注册信息会被自动复制到其它UDDI
根节点,于是就能被任何希望发现这些Web服务的人所发现。
【 在 qyjohn (Sweet Potato -- 清扬婉兮,适我愿兮) 的大作中提到: 】
: 嗯,服务发现是如何实现的?跟UPnP和JINI的服务发现有何区别?
: 俺对WebService一窍不通的说。
--
FROM 61.48.32.145
这个发现服务,在注册的时候是否要有一个目录规范?
比如用药品为例,有一个国家标准的药品目录,
这个目录,是国际组织制定吗?
UDDI商业注册中心,是什么性质?
【 在 FrankCH (终有绿叶衬) 的大作中提到: 】
: 俺也是新手的说。嗬嗬。只是前一阵子做过一些方案。
: 摘一段文字吧。关于UDDI
: Web服务基于开放的因特网标准,它的结构单元是SOAP、WSDL和UDDI。
: UDDI(统一描述、发现和整合)建了一个平台独立、开放的框架,通过因特网来描述服务,发现业务,并且整合业务服务。它是一套基于Web的、分布式的、为Web服务提供的信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的Web服务注册以使得别的企业能够发
: 访问协议的实现标准。
: 通过使用UDDI的发现服务,企业可以单独注册那些希望被别的企业发现的自身提供的Web服务。企业可以通过UDDI商业注册中心的Web界面,或是使用实现了"UDDI Programmer's
: API标准"所描述的编程接口的工具,来将信息加入到UDDI的商业注册中心。UDDI商业注册中心在逻辑上是集中的,在物理上是分布式的,由多个根节点组成,相互之间按一定规则进行数据同步。当一个企业在UDDI商业注册中心的一个实例中实施注册后,其注册信息会被自动复制到其它
: 根节点,于是就能被任何希望发现这些Web服务的人所发现。
--
FROM 211.151.90.129
介绍UDDI的文章很多,有空的时候转一些上来就是了。。
嗬嗬,既然是规范,东西还是很全的。
商业中心,自然是商业性质了。:P
【 在 zixia (me.. me... me...) 的大作中提到: 】
: 这个发现服务,在注册的时候是否要有一个目录规范?
: 比如用药品为例,有一个国家标准的药品目录,
: 这个目录,是国际组织制定吗?
: UDDI商业注册中心,是什么性质?
--
FROM 61.48.32.145
我更关心的是有了这个目录之后的问题,例如说Service Availability
的问题。例如说北京天文台注册了个天气预报服务,结果今天他刚好服
务器坏了呢?根据前面的描述UDDI依赖于一个及其庞大的分布式数据库
来管理注册的服务,可以想像这个分布式数据库到了适当的时候会象目
前的域名数据库一样要24到48小时来更新和同步。
【 在 zixia (me.. me... me...) 的大作中提到: 】
: 这个发现服务,在注册的时候是否要有一个目录规范?
: 比如用药品为例,有一个国家标准的药品目录,
: 这个目录,是国际组织制定吗?
: UDDI商业注册中心,是什么性质?
--
FROM 166.111.146.248
UDDI 怎样定义天气预报服务?
一个接口,
p = UDDI->SearchService("天气预报","中国") 么?
然后 p->getWeather("北京", "2003-09-23")?
【 在 qyjohn (Sweet Potato -- 清扬婉兮,适我愿兮) 的大作中提到: 】
: 我更关心的是有了这个目录之后的问题,例如说Service Availability
: 的问题。例如说北京天文台注册了个天气预报服务,结果今天他刚好服
: 务器坏了呢?根据前面的描述UDDI依赖于一个及其庞大的分布式数据库
: 来管理注册的服务,可以想像这个分布式数据库到了适当的时候会象目
: 前的域名数据库一样要24到48小时来更新和同步。
--
FROM 211.151.90.129
UDDI注册使用的核心信息模型由XML Schema定义的
定义了四种信息类型:
商业实体信息,服务信息,绑定信息,服务调用规范信息
四种实体又有相对应的元素
这样可以操纵这些模型
在UDDI_Technical_White_Paper_CN
UDDI_Executive_White_Paper_CN
上有讲到运作过程
【 在 zixia (me.. me... me...) 的大作中提到: 】
: UDDI 怎样定义天气预报服务?
: 一个接口,
: p = UDDI->SearchService("天气预报","中国") 么?
: 然后 p->getWeather("北京", "2003-09-23")?
--
FROM 202.192.157.41
post 上来吧,呵呵,pdf?
【 在 dancewing (黑色郁金香) 的大作中提到: 】
: UDDI注册使用的核心信息模型由XML Schema定义的
: 定义了四种信息类型:
: 商业实体信息,服务信息,绑定信息,服务调用规范信息
: 四种实体又有相对应的元素
: 这样可以操纵这些模型
: 在UDDI_Technical_White_Paper_CN
: UDDI_Executive_White_Paper_CN
: 上有讲到运作过程
--
FROM 211.151.90.129