让自己的QQ名字在好友名单上排名靠前:
大家也许很希望自己的QQ在朋友里面是靠在最前面的,让他(她)能一眼就看见你的QQ了。
也要用通过特殊字符来搞定,就是: 把这个字符加在你名字的前面就会使你的名字排在好友列表的前面咯。(不能排在会员前面,也不能排在无昵称QQ前面)
无昵称QQ:
让你的QQ完全没有昵称,不是打空格, 方法很简单, 只要将你QQ中昵称去掉改为空白 , 然后换一个头像, 确定就可以了,哈哈! 简单吧!!!
创想工场随机推荐
2008年11月5日星期三
云计算与90's NetPC的渊源
云计算,其实并非新事物;新瓶子里面装的是改良的‘旧酒’-NetPC.
在90‘s年代,Oracle提出的是Network Computer架构是由Oracle旗下的Network Computer Inc.提出,获得Apple、Sun、IBM、Netscpae的支持。
NetPC则是由微软和Intel在1997年4月之後提出获得Intel、HP、Dell、Compaq的支持。不管是NC架构或是NetPC架构, 其实都是一样的东西;也可以说NetPC其实就是微软版的NC Architecture(Sun和Oracle也都有各自的NCA);只是微软不愿意将自己提出的架构置於NC架构之下, 所以另外取了个名字叫做NetPC。
基本上, NC是主张个人电脑功能不用太强,藉由连到主机获得主机在硬碟空间和运算能力的支援程式在主机执行完毕之後再将结果送回个人电脑。
不过云计算与NetPC,二者所站的理论高度不同。从思维模式来看,NetPC侧重的是计算的实体;而云计算则侧重的是服务。从商业运作模式来看,当时90’s环境下主要是卖计算机与操作系统;现在云计算机则主要是为了卖软件与服务。
关于云计算所提供服务的度量
建议采用"MIPS币"来作为在虚拟世界中对某个功能真正价值的衡量,以避免‘在现实世界中的货币,因为无法统一采用基于真实物理含义的单位来衡量商品真实价值,而导致通货膨胀与剥削’等现象。
在90‘s年代,Oracle提出的是Network Computer架构是由Oracle旗下的Network Computer Inc.提出,获得Apple、Sun、IBM、Netscpae的支持。
NetPC则是由微软和Intel在1997年4月之後提出获得Intel、HP、Dell、Compaq的支持。不管是NC架构或是NetPC架构, 其实都是一样的东西;也可以说NetPC其实就是微软版的NC Architecture(Sun和Oracle也都有各自的NCA);只是微软不愿意将自己提出的架构置於NC架构之下, 所以另外取了个名字叫做NetPC。
基本上, NC是主张个人电脑功能不用太强,藉由连到主机获得主机在硬碟空间和运算能力的支援程式在主机执行完毕之後再将结果送回个人电脑。
不过云计算与NetPC,二者所站的理论高度不同。从思维模式来看,NetPC侧重的是计算的实体;而云计算则侧重的是服务。从商业运作模式来看,当时90’s环境下主要是卖计算机与操作系统;现在云计算机则主要是为了卖软件与服务。
关于云计算所提供服务的度量
建议采用"MIPS币"来作为在虚拟世界中对某个功能真正价值的衡量,以避免‘在现实世界中的货币,因为无法统一采用基于真实物理含义的单位来衡量商品真实价值,而导致通货膨胀与剥削’等现象。
webservice
当前,WebService是一个热门话题。但是,WebService究竟是什么?什么情况下应该用WebService?什么情况下不应该用WebService?是需要我们正确认识的。
Web Service 是一种新的web应用程序分支,他们是自包含、自描述、模块化的应用,可以发布、定位、通过web调用。Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后,其他Web Service应用程序可以发现并调用它部署的服务。
实际上,WebService的主要目标是跨平台的可互操作性。为了达到这一目标,WebService完全基于XML(可扩展标记语言)、XSD(XMLSchema)等独立于平台、独立于软件供应商的标准,是创建可互操作的、分布式应用程序的新平台。由此可以看出,在以下三种情况下,使用WebService会带来极大的好处。
长项一:跨防火墙的通信
如果应用程序有成千上万的用户,而且分布在世界各地,那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下,使用DCOM就不是那么简单,通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是,选择用浏览器作为客户端,写下一大堆ASP页面,把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大,程序很难维护。
图1通过WebService集成应用程序
举个例子,在应用程序里加入一个新页面,必须先建立好用户界面(Web页面),并在这个页面后面,包含相应商业逻辑的中间层组件,还要再建立至少一个ASP页面,用来接受用户输入的信息,调用中间层组件,把结果格式化为HTML形式,最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单,客户端的编程就简单多了。
如果中间层组件换成WebService的话,就可以从用户界面直接调用中间层组件,从而省掉建立ASP页面的那一步。要调用WebService,可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端,也可以使用自己开发的SOAP客户端,然后把它和应用程序连接起来。不仅缩短了开发周期,还减少了代码复杂度,并能够增强应用程序的可维护性。同时,应用程序也不再需要在每次调用中间层组件时,都跳转到相应的“结果页”。
从经验来看,在一个用户界面和中间层有较多交互的应用程序中,使用WebService这种结构,可以节省花在用户界面编程上20%的开发时间。另外,这样一个由WebService组成的中间层,完全可以在应用程序集成或其它场合下重用。最后,通过WebService把应用程序的逻辑和数据“暴露”出来,还可以让其它平台上的客户重用这些应用程序。
长项二:应用程序集成
企业级的应用程序开发者都知道,企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来,而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据;或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上,不同软件厂商生产的各种软件也常常需要集成起来。通过WebService,应用程序可以用标准的方法把功能和数据“暴露”出来,供其它应用程序使用。
例如,有一个订单登录程序,用于登录从客户来的新订单,包括客户信息、发货地址、数量、价格和付款方式等内容;还有一个订单执行程序,用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后,订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层WebService,订单执行程序可以把“AddOrder”函数“暴露”出来。这样,每当有新订单到来时,订单登录程序就可以调用这个函数来发送货物了。
长项三:B2B的集成
用WebService集成应用程序,可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界限时会怎么样呢?跨公司的商务交易集成通常叫做B2B集成。
WebService是B2B集成成功的关键。通过WebService,公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如,把电子下单系统和电子发票系统“暴露”出来,客户就可以以电子的方式发送订单,供应商则可以以电子的方式发送原料采购发票。当然,这并不是一个新的概念,EDI(电子文档交换)早就是这样了。但是,WebService的实现要比EDI简单得多,而且WebService运行在Internet上,在世界任何地方都可轻易实现,其运行成本就相对较低。不过,WebService并不像EDI那样,是文档交换或B2B集成的完整解决方案。WebService只是B2B集成的一个关键部分,还需要许多其它的部分才能实现集成。
用WebService来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“暴露”出来,成为WebService,就可以让任何指定的合作伙伴调用这些商务逻辑,而不管他们的系统在什么平台上运行,使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本,让许多原本无法承受EDI的中小企业也能实现B2B集成。
长项四:软件和数据重用
软件重用是一个很大的主题,重用的形式很多,重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用,另一种形式是二进制形式的组件重用。
图2用WebService集成各种应用中的功能,为用户提供一个统一的界面
当前,像表格控件或用户界面控件这样的可重用软件组件,在市场上都占有很大的份额。但这类软件的重用有一个很大的限制,就是重用仅限于代码,数据不能重用。原因在于,发布组件甚至源代码都比较容易,但要发布数据就没那么容易,除非是不会经常变化的静态数据。
WebService在允许重用代码的同时,可以重用代码背后的数据。使用WebService,再也不必像以前那样,要先从第三方购买、安装软件组件,再从应用程序中调用这些组件;只需要直接调用远端的WebService就可以了。举个例子,要在应用程序中确认用户输入的地址,只需把这个地址直接发送给相应的WebService,这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息,确认这个地址是否在相应的邮政编码区域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的,那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库,而且这个数据库还是不能实时更新的。
另一种软件重用的情况是,把好几个应用程序的功能集成起来。例如,要建立一个局域网上的门户站点应用,让用户既可以查询联邦快递包裹,查看股市行情,又可以管理自己的日程安排,还可以在线购买电影票。现在Web上有很多应用程序供应商,都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露”出来,就可以非常容易地把所有这些功能都集成到你的门户站点中,为用户提供一个统一的、友好的界面。
将来,许多应用程序都会利用WebService,把当前基于组件的应用程序结构扩展为组件/WebService的混合结构,可以在应用程序中使用第三方的WebService提供的功能,也可以把自己的应用程序功能通过WebService提供给别人。两种情况下,都可以重用代码和代码背后的数据。
从以上论述可以看出,WebService在通过Web进行互操作或远程调用的时候是最有用的。不过,也有一些情况,WebService根本不能带来任何好处。
短处一:单机应用程序
目前,企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下,最好就不要用WebService,只要用本地的API就可以了。COM非常适合于在这种情况下工作,因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用。当然WebService也能用在这些场合,但那样不仅消耗太大,而且不会带来任何好处。
短处二:局域网的同构应用程序
在许多应用中,所有的程序都是用VB或VC开发的,都在Windows平台下使用COM,都运行在同一个局域网上。例如,有两个服务器应用程序需要相互通信,或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。在这些程序里,使用DCOM会比SOAP/HTTP有效得多。与此相类似,如果一个.NET程序要连接到局域网上的另一个.NET程序,应该使用.NETremoting。有趣的是,在.NETremoting中,也可以指定使用SOAP/HTTP来进行WebService调用。不过最好还是直接通过TCP进行RPC调用,那样会有效得多。
总之,只要从应用程序结构的角度看,有别的方法比WebService更有效、更可行,那就不要用WebService
Web Service 是一种新的web应用程序分支,他们是自包含、自描述、模块化的应用,可以发布、定位、通过web调用。Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后,其他Web Service应用程序可以发现并调用它部署的服务。
实际上,WebService的主要目标是跨平台的可互操作性。为了达到这一目标,WebService完全基于XML(可扩展标记语言)、XSD(XMLSchema)等独立于平台、独立于软件供应商的标准,是创建可互操作的、分布式应用程序的新平台。由此可以看出,在以下三种情况下,使用WebService会带来极大的好处。
长项一:跨防火墙的通信
如果应用程序有成千上万的用户,而且分布在世界各地,那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下,使用DCOM就不是那么简单,通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是,选择用浏览器作为客户端,写下一大堆ASP页面,把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大,程序很难维护。
图1通过WebService集成应用程序
举个例子,在应用程序里加入一个新页面,必须先建立好用户界面(Web页面),并在这个页面后面,包含相应商业逻辑的中间层组件,还要再建立至少一个ASP页面,用来接受用户输入的信息,调用中间层组件,把结果格式化为HTML形式,最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单,客户端的编程就简单多了。
如果中间层组件换成WebService的话,就可以从用户界面直接调用中间层组件,从而省掉建立ASP页面的那一步。要调用WebService,可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端,也可以使用自己开发的SOAP客户端,然后把它和应用程序连接起来。不仅缩短了开发周期,还减少了代码复杂度,并能够增强应用程序的可维护性。同时,应用程序也不再需要在每次调用中间层组件时,都跳转到相应的“结果页”。
从经验来看,在一个用户界面和中间层有较多交互的应用程序中,使用WebService这种结构,可以节省花在用户界面编程上20%的开发时间。另外,这样一个由WebService组成的中间层,完全可以在应用程序集成或其它场合下重用。最后,通过WebService把应用程序的逻辑和数据“暴露”出来,还可以让其它平台上的客户重用这些应用程序。
长项二:应用程序集成
企业级的应用程序开发者都知道,企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来,而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据;或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上,不同软件厂商生产的各种软件也常常需要集成起来。通过WebService,应用程序可以用标准的方法把功能和数据“暴露”出来,供其它应用程序使用。
例如,有一个订单登录程序,用于登录从客户来的新订单,包括客户信息、发货地址、数量、价格和付款方式等内容;还有一个订单执行程序,用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后,订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层WebService,订单执行程序可以把“AddOrder”函数“暴露”出来。这样,每当有新订单到来时,订单登录程序就可以调用这个函数来发送货物了。
长项三:B2B的集成
用WebService集成应用程序,可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界限时会怎么样呢?跨公司的商务交易集成通常叫做B2B集成。
WebService是B2B集成成功的关键。通过WebService,公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如,把电子下单系统和电子发票系统“暴露”出来,客户就可以以电子的方式发送订单,供应商则可以以电子的方式发送原料采购发票。当然,这并不是一个新的概念,EDI(电子文档交换)早就是这样了。但是,WebService的实现要比EDI简单得多,而且WebService运行在Internet上,在世界任何地方都可轻易实现,其运行成本就相对较低。不过,WebService并不像EDI那样,是文档交换或B2B集成的完整解决方案。WebService只是B2B集成的一个关键部分,还需要许多其它的部分才能实现集成。
用WebService来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“暴露”出来,成为WebService,就可以让任何指定的合作伙伴调用这些商务逻辑,而不管他们的系统在什么平台上运行,使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本,让许多原本无法承受EDI的中小企业也能实现B2B集成。
长项四:软件和数据重用
软件重用是一个很大的主题,重用的形式很多,重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用,另一种形式是二进制形式的组件重用。
图2用WebService集成各种应用中的功能,为用户提供一个统一的界面
当前,像表格控件或用户界面控件这样的可重用软件组件,在市场上都占有很大的份额。但这类软件的重用有一个很大的限制,就是重用仅限于代码,数据不能重用。原因在于,发布组件甚至源代码都比较容易,但要发布数据就没那么容易,除非是不会经常变化的静态数据。
WebService在允许重用代码的同时,可以重用代码背后的数据。使用WebService,再也不必像以前那样,要先从第三方购买、安装软件组件,再从应用程序中调用这些组件;只需要直接调用远端的WebService就可以了。举个例子,要在应用程序中确认用户输入的地址,只需把这个地址直接发送给相应的WebService,这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息,确认这个地址是否在相应的邮政编码区域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的,那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库,而且这个数据库还是不能实时更新的。
另一种软件重用的情况是,把好几个应用程序的功能集成起来。例如,要建立一个局域网上的门户站点应用,让用户既可以查询联邦快递包裹,查看股市行情,又可以管理自己的日程安排,还可以在线购买电影票。现在Web上有很多应用程序供应商,都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露”出来,就可以非常容易地把所有这些功能都集成到你的门户站点中,为用户提供一个统一的、友好的界面。
将来,许多应用程序都会利用WebService,把当前基于组件的应用程序结构扩展为组件/WebService的混合结构,可以在应用程序中使用第三方的WebService提供的功能,也可以把自己的应用程序功能通过WebService提供给别人。两种情况下,都可以重用代码和代码背后的数据。
从以上论述可以看出,WebService在通过Web进行互操作或远程调用的时候是最有用的。不过,也有一些情况,WebService根本不能带来任何好处。
短处一:单机应用程序
目前,企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下,最好就不要用WebService,只要用本地的API就可以了。COM非常适合于在这种情况下工作,因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用。当然WebService也能用在这些场合,但那样不仅消耗太大,而且不会带来任何好处。
短处二:局域网的同构应用程序
在许多应用中,所有的程序都是用VB或VC开发的,都在Windows平台下使用COM,都运行在同一个局域网上。例如,有两个服务器应用程序需要相互通信,或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。在这些程序里,使用DCOM会比SOAP/HTTP有效得多。与此相类似,如果一个.NET程序要连接到局域网上的另一个.NET程序,应该使用.NETremoting。有趣的是,在.NETremoting中,也可以指定使用SOAP/HTTP来进行WebService调用。不过最好还是直接通过TCP进行RPC调用,那样会有效得多。
总之,只要从应用程序结构的角度看,有别的方法比WebService更有效、更可行,那就不要用WebService
web 3.0
Web 3.0一词包含多层含义,用来概括互联网发展过程中可能出现的各种不同的方向和特征,包括将互联网本身转化为一个泛型数据库;跨浏览器、超浏览器的内容投递和请求机制;人工智能技术的运用;语义网;地理映射网;运用3D技术搭建的网站甚至虚拟世界或网络公国等。
Web 3.0特点
第一,Web3.0的API(应用程序编程接口)是全球范围的,也就是XMLWebServices;
第二,Web3.0的速度达到10G,所有的应用都不用担心速度;
第三,Web3.0是一个技术框架或操作系统。
历史
Web 3.0是针对Web 2.0提出的,较有名的首次提及是在2006年初Jeffrey Zeldman的博客中一篇批评Web 2.0的文章中。
2006年5月,Tim Berners-Lee曾说[2]:
“ 人们不停地质问Web 3.0到底是什么。我认为当可缩放矢量图形在Web 2.0的基础上大面积使用——所有东西都起波纹、被折叠并且看起来没有棱角——以及一整张语义网涵盖著大量的数据,你就可以访问这难以置信的数据资源。 ”
──Tim Berners-Lee, A 'more revolutionary' Web
2006年11月的Technet峰会上,Yahoo创办人兼首席执行官杨致远作出阐述:
“ 目前对Web 2.0的归档和讨论很多。借助网络级别所能达到的效能,网络的力量已经到达了一个临界点。我们同时也看到最近4年出现了更富级的设备以及更富级的与网络互动的方法,不仅仅体现在游戏机和移动设备这样的硬件,同时也体现在软件层面。你不一定得是计算机科学家才能创作出一个程序。这种现象在Web 2.0里初现端倪,而3.0将更加深化,是一个真正的公共载体……专业,半专业和消费者的界限越来越模糊,创造出一种商业和应用程序的网络效应。 ”
──杨致远
在这个峰会上,Netflix创始人Reed Hastings阐述了定义Web术语的简单公式:
“ Web 1.0是拨号上网,50K平均带宽,Web 2.0是1M平均带宽那Web 3.0就该是10M带宽,全视频的网络,这才感觉像Web 3.0。 ”
──Reed Hastings
2007年8月7日,谷歌首席执行官Eric Schmidt出席首尔数字论坛时被与会者问及Web 3.0的定义, Eric Schmidt首先开玩笑的地说“Web 2.0只是一个行销术语,而你刚才正好发明了Web 3.0这个行销术语。”随后他谈及了自己的具体看法:
“ ……(Web 3.0)创建应用程序的方法将不同。到目前为止Web 2.0一词的出现主要是回应某种叫做“AJAX”的概念……而对Web 3.0我的预测将是拼凑在一起的应用程序,带有一些主要特征:应用程序相对较小、数据处于Cloud中、应用程序可以在任何设备上运行(PC或者移动电话)、应用程序的速度非常快并能进行很多自定义、此外应用程序像病毒一样地扩散(社交网络,电子邮件等)。 ”
──Eric Schmidt
自2006年底以来,Web 3.0一词正受到越来越多的关注,也是越来越多争论的焦点,这个现象正持续到2007。
关于Web 3.0的争论
关于如何定义Web 3.0,及其所代表的含义的争论非常激烈,观点也琳琅满目。
将互联网转化为数据库
迈向Web 3.0的第一步是“数据网络”这一概念的体现,结构化数据集以可重复利用、可远程查询的格式公布于网络上,比如XML,RDF和微格式。最近SPARQL的发展为网络上以RDF方式配发的数据库提供了一套标准化的查询语言和应用程序接口。数据网络让数据契合和应用程序互用性更上新台阶,使数据像网页一样容易访问和链接。在数据网络时代,重点主要是如何以RDF的方式提供结构化的数据。全语义网时期会拓宽语义范围,这样结构化,半结构化甚至零散的数据内容(比如传统的网页、文档等)都能以RDF和OWL语义格式的形式普遍存在。[5]
向人工智能进化的道路
Web 3.0也被用来描述一条最终通向人工智能的网络进化的道路,这个人工智能最终能以类似人类的方式思辩网络。一些人对此表示悲观,认为这是不可企及的设想。然而,像IBM和Google这样的大公司已经在使用一些正提供惊人的信息的新技术,例如通过挖取学校音乐网站的数据来预测未来的热门单曲。同时也有人提出是否智能系统将是Web 3.0背后的推动力,抑或智能会以人的形式出现,即某体系的人们(例如del.icio.us这样的协同过滤服务,Flickr和Digg这样人工抽取网络资源)以及他们之间如何互动。[5]
语义网络和SOA的实现
和人工智能的方向有关联,Web 3.0可以是语义网概念的实现和扩充。各学院正在研究开发一种基于描述逻辑和智能代理的推理软件,这样的软件通过运用表述网络上概念和数据之间的关系的规则来进行逻辑推理操作。
Sramana Mitra对语义网成为次世代互联网基本要素的看法不同,并提出了一道封装Web 3.0的公式[7]
Web 3.0也被认为和服务导向结构及语义网的具体体现有关。[8]
向3D进化
另一条可能的道路是Web3D联盟拥护的3D化构想,包括将整个网络转化为一系列3D空间,采用第二人生启发的概念。[9]同时也提供新的方式在3D共享空间连接和协同。[10]
所建议的一些延伸性定义
Nova Spivack建议将Web 3.0的定义延伸至当前各大技术潮流迈向新的成熟阶段的具体体现,包括:
无处不联网,宽带网普及和发展,移动通信设备的互联网介入。
网络计算,“软件就是服务”的商业模型,Web服务互用性,分布式计算,网格计算和效用计算(又“云雾计算”)。
开放技术,开放API和协议,开放数据格式,开源软件平台和开放数据(如创作共享,开放数据许可)。
开放身份,OpenID,开放名声,跨域身份和个人数据。
智能网络,语义网技术比如资源描述框架,网络实体语言,SWRL,SPARQL,语义应用程序平台和基于声明的数据储备。
分布式数据库,万维数据库(“World Wide Database”,由语义网的技术实现)。
智能应用程序,普通语言的处理。[11],机器学习,机器推理,自主代理。[12]
针对Web 2.0的扩展和革新
Web 2.0以AJAX概念为契机,提供了高仿桌面应用程序的网络应用程序,激励用户生成内容和搭建具有向心力的社区,并以高耦合的技术形成轻快有效的商业模型。在此基础上,Web 3.0被认为肩负著发扬2.0的精神,并冲破目前Web 2.0所面临的障碍。因此通过对目前Web 2.0所面临的瓶颈和具体实例进行分析,可以对Web 3.0作一些展望。
带宽
用户所在区域的网络的带宽均值,将直接影响到网站内容的投放和索取,是制约富级互联网应用程序发展的一大瓶颈。
应用程序的速度
虽然许多网站使用异步JavaScript和XML/JSON以及各种UI Widgets来实现仿桌面应用程序的网络应用程序,但这些前台程序的速度都无法与传统桌面程序媲美,为了实现桌面程序界面的一些常见功能(如拖拽、排序、缩放等),必须使用复杂的JavaScript,这样容易造成许多用户的浏览器响应延时甚至假死,进一步降低用户体验。
应用程序开发的草根化,社区协同化
目前网络应用程序的开发门槛仍然较高,并且较为封闭,这样虽然可以满足开发一般的以用户生成内容(“User-generated content”)为主导的应用程序,却制约了用户生成程序(“User-generated application”)的发展空间。在向用户生成程序过度的期间,值得注意的应用程序、技术和概念有:
Mash-up,更人性化的Mash up如Microsoft Popfly项目协同,Basecamp,Bugzilla,Project.net,Google Earth,facebook API
Web 3.0特点
第一,Web3.0的API(应用程序编程接口)是全球范围的,也就是XMLWebServices;
第二,Web3.0的速度达到10G,所有的应用都不用担心速度;
第三,Web3.0是一个技术框架或操作系统。
历史
Web 3.0是针对Web 2.0提出的,较有名的首次提及是在2006年初Jeffrey Zeldman的博客中一篇批评Web 2.0的文章中。
2006年5月,Tim Berners-Lee曾说[2]:
“ 人们不停地质问Web 3.0到底是什么。我认为当可缩放矢量图形在Web 2.0的基础上大面积使用——所有东西都起波纹、被折叠并且看起来没有棱角——以及一整张语义网涵盖著大量的数据,你就可以访问这难以置信的数据资源。 ”
──Tim Berners-Lee, A 'more revolutionary' Web
2006年11月的Technet峰会上,Yahoo创办人兼首席执行官杨致远作出阐述:
“ 目前对Web 2.0的归档和讨论很多。借助网络级别所能达到的效能,网络的力量已经到达了一个临界点。我们同时也看到最近4年出现了更富级的设备以及更富级的与网络互动的方法,不仅仅体现在游戏机和移动设备这样的硬件,同时也体现在软件层面。你不一定得是计算机科学家才能创作出一个程序。这种现象在Web 2.0里初现端倪,而3.0将更加深化,是一个真正的公共载体……专业,半专业和消费者的界限越来越模糊,创造出一种商业和应用程序的网络效应。 ”
──杨致远
在这个峰会上,Netflix创始人Reed Hastings阐述了定义Web术语的简单公式:
“ Web 1.0是拨号上网,50K平均带宽,Web 2.0是1M平均带宽那Web 3.0就该是10M带宽,全视频的网络,这才感觉像Web 3.0。 ”
──Reed Hastings
2007年8月7日,谷歌首席执行官Eric Schmidt出席首尔数字论坛时被与会者问及Web 3.0的定义, Eric Schmidt首先开玩笑的地说“Web 2.0只是一个行销术语,而你刚才正好发明了Web 3.0这个行销术语。”随后他谈及了自己的具体看法:
“ ……(Web 3.0)创建应用程序的方法将不同。到目前为止Web 2.0一词的出现主要是回应某种叫做“AJAX”的概念……而对Web 3.0我的预测将是拼凑在一起的应用程序,带有一些主要特征:应用程序相对较小、数据处于Cloud中、应用程序可以在任何设备上运行(PC或者移动电话)、应用程序的速度非常快并能进行很多自定义、此外应用程序像病毒一样地扩散(社交网络,电子邮件等)。 ”
──Eric Schmidt
自2006年底以来,Web 3.0一词正受到越来越多的关注,也是越来越多争论的焦点,这个现象正持续到2007。
关于Web 3.0的争论
关于如何定义Web 3.0,及其所代表的含义的争论非常激烈,观点也琳琅满目。
将互联网转化为数据库
迈向Web 3.0的第一步是“数据网络”这一概念的体现,结构化数据集以可重复利用、可远程查询的格式公布于网络上,比如XML,RDF和微格式。最近SPARQL的发展为网络上以RDF方式配发的数据库提供了一套标准化的查询语言和应用程序接口。数据网络让数据契合和应用程序互用性更上新台阶,使数据像网页一样容易访问和链接。在数据网络时代,重点主要是如何以RDF的方式提供结构化的数据。全语义网时期会拓宽语义范围,这样结构化,半结构化甚至零散的数据内容(比如传统的网页、文档等)都能以RDF和OWL语义格式的形式普遍存在。[5]
向人工智能进化的道路
Web 3.0也被用来描述一条最终通向人工智能的网络进化的道路,这个人工智能最终能以类似人类的方式思辩网络。一些人对此表示悲观,认为这是不可企及的设想。然而,像IBM和Google这样的大公司已经在使用一些正提供惊人的信息的新技术,例如通过挖取学校音乐网站的数据来预测未来的热门单曲。同时也有人提出是否智能系统将是Web 3.0背后的推动力,抑或智能会以人的形式出现,即某体系的人们(例如del.icio.us这样的协同过滤服务,Flickr和Digg这样人工抽取网络资源)以及他们之间如何互动。[5]
语义网络和SOA的实现
和人工智能的方向有关联,Web 3.0可以是语义网概念的实现和扩充。各学院正在研究开发一种基于描述逻辑和智能代理的推理软件,这样的软件通过运用表述网络上概念和数据之间的关系的规则来进行逻辑推理操作。
Sramana Mitra对语义网成为次世代互联网基本要素的看法不同,并提出了一道封装Web 3.0的公式[7]
Web 3.0也被认为和服务导向结构及语义网的具体体现有关。[8]
向3D进化
另一条可能的道路是Web3D联盟拥护的3D化构想,包括将整个网络转化为一系列3D空间,采用第二人生启发的概念。[9]同时也提供新的方式在3D共享空间连接和协同。[10]
所建议的一些延伸性定义
Nova Spivack建议将Web 3.0的定义延伸至当前各大技术潮流迈向新的成熟阶段的具体体现,包括:
无处不联网,宽带网普及和发展,移动通信设备的互联网介入。
网络计算,“软件就是服务”的商业模型,Web服务互用性,分布式计算,网格计算和效用计算(又“云雾计算”)。
开放技术,开放API和协议,开放数据格式,开源软件平台和开放数据(如创作共享,开放数据许可)。
开放身份,OpenID,开放名声,跨域身份和个人数据。
智能网络,语义网技术比如资源描述框架,网络实体语言,SWRL,SPARQL,语义应用程序平台和基于声明的数据储备。
分布式数据库,万维数据库(“World Wide Database”,由语义网的技术实现)。
智能应用程序,普通语言的处理。[11],机器学习,机器推理,自主代理。[12]
针对Web 2.0的扩展和革新
Web 2.0以AJAX概念为契机,提供了高仿桌面应用程序的网络应用程序,激励用户生成内容和搭建具有向心力的社区,并以高耦合的技术形成轻快有效的商业模型。在此基础上,Web 3.0被认为肩负著发扬2.0的精神,并冲破目前Web 2.0所面临的障碍。因此通过对目前Web 2.0所面临的瓶颈和具体实例进行分析,可以对Web 3.0作一些展望。
带宽
用户所在区域的网络的带宽均值,将直接影响到网站内容的投放和索取,是制约富级互联网应用程序发展的一大瓶颈。
应用程序的速度
虽然许多网站使用异步JavaScript和XML/JSON以及各种UI Widgets来实现仿桌面应用程序的网络应用程序,但这些前台程序的速度都无法与传统桌面程序媲美,为了实现桌面程序界面的一些常见功能(如拖拽、排序、缩放等),必须使用复杂的JavaScript,这样容易造成许多用户的浏览器响应延时甚至假死,进一步降低用户体验。
应用程序开发的草根化,社区协同化
目前网络应用程序的开发门槛仍然较高,并且较为封闭,这样虽然可以满足开发一般的以用户生成内容(“User-generated content”)为主导的应用程序,却制约了用户生成程序(“User-generated application”)的发展空间。在向用户生成程序过度的期间,值得注意的应用程序、技术和概念有:
Mash-up,更人性化的Mash up如Microsoft Popfly项目协同,Basecamp,Bugzilla,Project.net,Google Earth,facebook API
订阅:
博文 (Atom)