俺的垃圾箱

OpenSimulator项目，也就是OpenSIM，是基于BSD开源协议的虚拟世界服务器项目，它是用C#开发的，类似于SecondLife的网格服务，可以创建和部署虚拟世界，以及在各个OpenSim虚拟世界中跳转。目前OpenSim尚在Apha阶段，不过已经有人在OpenSim中模拟出了N体仿真。并且已经有人已经在部署OpenSim的虚拟世界：http://osgrid.org/。

据路透社报道：

对于SL(SecondLife)来说这可不是什么好事情：在未来，由成千上万个竞争性的虚拟世界建成的虚拟宇宙中，Second Life只是其中的一个角色，也许被掩埋其中。SL林登实验室副总裁，Joe Miller，也就是Second Life居民熟知的Zero  Linden，向路透社透露了林登实验室的长期战略，林登实验室积极推动一套虚拟世界网格标准协议的开发，以使未来不同的虚拟世界可以互通。“总的来讲，标准组最终将达成一致，”Miller说到。随着SL 林登实验室的Open Grid Protocol 以及 Open Grid Public Beta(开放网格测试服务)的推出， 而林登实验室Second Life 虚拟化身从传送到OpenSIM虚拟世界的测试也取得成功，IBM注资的林登实验室正试图在使OpenSim与Second Life互通的工作中取得主导地位。 

而OpenSim的推出有可能意味着其垄断地位行将结束。OpenSim正在挖林登财政收入的墙角，除了收取Lindex虚拟货币交易的费用外，林登的核心业务就剩管理虚拟土地了。不计少数IBM主机上的区域，其余所有 Second Life虚拟土地都运行在林登管理的服务器上。购买土地（实际上就是购买林登服务器CPU的使用时间）的用户，每月要交土地使用费，也称为“tier”。 虽然新用户注册减速了，还时常有小技术故障，付费用户也缩水了，不过虚拟土地（林登的印钞机）的供给却以每季度44%的速度持续增长。林登面临挑战。

去年一月，林登将Second Life客户端软件开放了源码。但直到今天，仍将其服务器端代码唔得紧紧，服务器代码职责是管理用户物品库，处理登录，运行‘印钞机’-土地。岂料一些热切的程序员通过客户端代码，猜测出林登服务器端软件的基本构造。OpenSimulator项目，也就是OpenSim，迅速成长，提供与Second Life类似的功能，并且不依赖于林登的计算机也不交钱给林登。已经有一些开拓者和被林登驱逐的人开始转移到OpenSim世界中了。

林登的新盈利模式
    如果林登还用虚拟土地赚钱，而OpenSim又能提供比林登能承受的价格更低的土地，其功能和可靠性又接近现在的Second Life,林登将如何生存？林登又为何要如此积极地使Second Life与OpenSim之间的旅行变容易？
Miller说，林登的计划是提供增值服务，这区别于未来潜在的杂牌军组成OpenSim网 格。他拒绝解释公司的具体策略，只是坚持林登有“一些非常具体的计划”。不过在后续提问中，Miller还是提供了一些内幕，关于林登如何在 OpenSim主宰的世界里保持繁荣。“我可以预见 林登将提供经济服务，贸易服务，搜索服务”Miller说。一些OpenSim世界将看重Second Life的知识产权保护和商业功能。有着多年稳固财政支持声誉的林登币，或许会成为虚拟货币的金本位。Miller还引用了VeriSign在互联网顶级 域名管理中扮演的角色。林登也许某天会扮演一个活跃角色，不仅使OpenSim和Second Life可以互通，还会使两个无连接的OpenSim世界互通。

短期内
    从一个卖虚拟土地的公司转变为异构OpenSim世界的基础主干，将是缓慢的，Miller强调。在周三林登博客上的声明中，CEO Mark Kingdon证实平台稳定性、客户端性能、网络延迟、用户物品管理将是短期内的优先任务。
当然，林登的头儿们相信OpenSim时代即将到来，并保证，不仅要帮助这一事件的发生，而且还要改善自己的服务。“我们看好，在将来某天，加入Second Life的价值要远大于加入OpenSim”。

 

 

注：中国电信近日与北京「神州恒基网络」签署合作协议，正式进军3D社区平台，与该公司合作共同推出虚拟3D时尚社区《ChinaQ》，意图打造出中国版的《Second Life》（第二人生）。

 

评估比较产品，解决方案，技术方案的难题在于确定它们是否能针对问题域有效的解决问题。

首先要明确服务是完成一定业务功能的组件，服务是可以自包含的和自解释的，通过良好组织定义的标准接口提供服务。服务是被各种不同的策略驱动的。

 以架构师的角度来看，SOA 面向服务的统一管理必须解决服务的安全，服务的管理（监视，守护），服务的依存管理等诸如此类的各种服务管理策略问题。

OK, 统一管理机构的要解决的核心问题就是抽象出一系列针对服务的强制性策略，根据具体需求有选择的应用到不同的服务上。不同的域采用不同策略组。

 策略：

• 安全策略：访问策略和认证策略
• 管理策略：性能策略，监视策略，守护策略，可靠性策略，可用性策略
  
• 使用策略
• 路由策略：如信息转发的策略
• 开发标准策略：如开发语言，文档标准，Unit测试，集成Build

从运营维护的角度来看，他们关注的是安全访问，服务的版本和上线，服务的监视和管理，服务的生命周期，服务的状况及时通知，服务的消费（调用）行为数据分析，服务调用的API接口技术支持，服务的可维护性等等方面。

 

 综上所述，这些策略可以被抽象出来，作为统一的通用策略服务层使用。如有时间，再具体说明。

     摘要: 愚作之 SNDA-RPC 是基于JSON-RPC[1] 的扩展和修改，其目标是继续保持它的简单调用，修正其不足，以及扩展它对RESTful[2]的支持。SNDA-RPC 是运行在 HTTP 协议[3]上无状态的，轻量级远程调用协议。 SNDA-RPC描述了两类资源，Service API资源和Data API资源： * Service API资源，即通常所说的远程方法API资源，只能以HTTP GET或POST的方式被调用。其Service API的数据格式使用的是JSON[4] * Data API资源，即数据资源，可以被CRUD(Create, Read, Update, Delete)操作的资源（注，可能许多数据资源都是只读性质），Data API的数据格式使用的JSON[4], Atom[5],RSS[6]。 草拟阶段，您的建议对我很重要.  阅读全文

REST的使用，多从资源角度考虑设计，而我却以为不竟然，我以为可以同时从资源和RPC的角度考虑设计。
首先要明确的是RESTful是一种面向Sevrice和资源的架构类型，而不是标准，与此相对，它使用了如下的标准：
* HTTP
* URI
* XML/HTML/JSON/GIF/etc（Resource Representations）

注：这里的“资源”可以理解为，1、真实的资源（可以CRUD）；2、看作是Service API返回的结果（只能R）。
 
REST架构的具有如下特性：
统一接口：所有的资源通过统一的接口访问（HTTP GET, POST, PUT, DELETE)）
统一命名：REST系统中的资源(API)必须统一命名和规划，REST系统由使用URI命名的资源组成。REST最大的优势是提出了一个可以对资源和RPC统一命名的URI标准。这难能可贵。
交互形式: 主要以拉(pull)为基础的交互形式，通过长连接实现push。
可以缓冲：提升网络效能，可以将资源（响应）分为可缓存的和不可缓存的。
资源呈现：资源呈现（Resource Representation）允许有不同的表现的形式（text,xml,json,bin,gif,...）, 同一RESTful API可以取得不同表现形式的Resource。
分层组件：可以在客户和资源之间插入不同的中间组件来提升性能和安全等，如，代理服务，缓存服务，网关服务等。
无状态：本次连接和下一次到服务器的连接之间没有状态。这在在服务之间需要状态的时候是弊端。如果服务内的状态可以用长连接解决（如聊天服务）。


RESTful使用http方法（GET, PUT, DELETE, POST）来调用API或管理资源.
从RPC API的角度来看，这些方法的使用目标如下：

Http方法     使用目标
GET          可以缓冲的 resources
GET, PUT     可以缓冲和修改的 resources
GET, PUT, DELETE 可以缓冲，修改和删除的 resources
POST         不能缓冲的 resources

OpenSocial, FaceBook, NetVibes 都致力于社区平台的研究发展。

其中OpenSocial和NetVibes侧重于整合并和提供第三方Gadget到社区平台的标准。而FaceBook则从自身平台的需要，为了吸引更多的开发者更容易开发FaceBook App，提供了平台API，并开放了部分平台源码。

FaceBook是从社区平台自身数据->API开始制定社区平台的标准的。而OpenSocial则是从社区平台的功能互联互通开始着手制定的。

与OpenSocial类似的则是Netvibes，Netvibes也是以Widget(Gadget)入手，提供了Universal Widget API，其侧重点为开发用于个性网站（个人门户或个人桌面）的通用的Widget。与iGoogle的Widget相比，其窗体的表现更为美观，功能更多，License为可用于商业化的GNU LGPL. 其Widget的XML格式也和OpenSocial的Gadget类似（不知道是谁抄袭谁的）。
他们都提供客户端Gadget API，RESTful API，以及Gadget容器。

shindig是google的一个opensocial容器的参考实现:http://incubator.apache.org/shindig/，实现了java和Php两种语言的容器服务器。php的较为简单，用svn checkout出来，即可用（我已经安装测试过了），java的必须使用Maven工具编译。

Netvibes Platform(LGPL Open Source):
  优势：开放（承诺源代码全部开放，兼容大部分Widget:iGoogle, Opera, Apple Dashboard, Window Vista, Window Live；但是目前的开放进度缓慢），美观，功能，速度
  弱势：公司没有足够的影响力去推动UWA作为标准

Exposition Widget Server 是Netvibes 提供的容器参考实现（PHP），我的测试是极为简陋，只是简单渲染了Widget的内容，根本没有窗体外壳，别谈什么功能了。

与FaceBook的比较（Facebook Open Platform(f8)）
FaceBook License： Common Public Attribution License (CPAL) and Mozilla Public License (MPL)..

API： With the API, you can add social context to your application by utilizing profile, friend, Page, group, photo, and event data.
FBML： Facebook Markup Language (FBML) enables you to build full Facebook Platform applications that deeply integrate into a user's Facebook experience. You can hook into several Facebook integration points, including the profile, profile actions, Facebook canvas, News Feed and Mini-Feed.
FBML is an evolved subset of HTML with some elements removed, and others which have been added that are specific to Facebook. You set the FBML for a profile box by calling profile.setFBML through the API. The FBML is cached on Facebook's server until profile.setFBML is called again through a canvas page.
FQL：Facebook Query Language, or FQL, allows you to use a SQL-style interface to more easily query the same Facebook social data that you can access through other Facebook API methods (assuming your application has access!).
FBJS is Facebook's solution for developers who want to use JavaScript in their Facebook applications. We built FBJS to empower developers with all the functionality they need, and to protect our users' privacy at the same time.

与此还开放了Thrift——跨语言的Service库；MemcacheD——分布式内存对象缓存。

Viewer, Agent, Region
Viewer 是通过控制一个角色与虚拟世界交互的客户端，角色Agent 是持久存在的，控制该角色玩家离线也可能与之交互。Region也是持久存在的，是虚拟世界的土地。
众多的角色存在于土地上。

基本流程：
  1. Viewer 向 Agent Domain发出认证请求控制一个Agent
  2. Viewer 指导 Agent Domain 将角色放在一个区域
  3. Agent Domain 联系 Region Domain 请求获得该区域服务， 并协商该角色的放置位置
  4. 区域服务授权访问给Agent Domain，并一部分授权访问给Viewer.
  这时，交互开始：
    Viewer 访问 Regions Resource 移动 avatar
    区域通知 Viewer Resource 更新区域中对象的状态
    Viewer 访问其它 Agent 沟通交流。

SL社区数据的可移植性
http://dataportability.org/
提供策略和一组技术标准（已存在）使得在社区（social networks）玩家能共享他们的数据到其它服务上，控制他们的去向，重新组织等等。
另一方面，SLGAWG期望SL能被internet共同使用，并最终成为领导业界的基于开放协议的开发虚拟世界基础架构。

虚拟世界不仅仅包括3D数据，而且还包括众多的社区数据，如个人信息，好友信息，群组信息，他们之间通常存在可以彼此发送信息的机制。
因此我们只需要非常简单使用已有的一系列的开放标准，让虚拟世界融入社区之中。目前计划使用的开放标准如下：
  × 数字认证标准： OpenId/YADIS
  × 个人信息(Profile): hCard/FOAF
  × 好友列表： XFN/FOAF

SL开源的服务器端核心库(python > 2.3)

SL开源的目的是希望自身从3D虚拟世界网络娱乐，上升至服务平台，乃至成为业界的标准。SL认为，3D虚拟世界将组成了未来的网络架构，必须开放形成标准才能走在前面，更快的发展。自07年9月开始，由Zero Linden领头的Architecture Working Group 开始致力于规范和改善现有SL的通讯协议，同时包括服务器端和服务器与客户端之间的通信。主要目的是为了能在未来的SL Grid架构上，不仅能跑现有的SL，而且其他公司或私人搭建的虚拟世界也能跑。解决这些虚拟世界之间的相互链接，互联互通的问题。

目前开放的有Eventlet和mulib：

Eventlet: 使用非阻塞网络IO编写的高度伸缩性能的网络库，用来实现一个骨干Http服务。
  Require：
        greenlet(http://cheeseshop.python.org/pypi/greenlet)
        pyOpenSSL(http://pyopenssl.sourceforge.net/) 需要SSL的时候
  下载： http://svn.secondlife.com/trac/eventlet/changeset/8/branches/beta-1?old_path=%2F&format=zip

mulib: 是基于REST的Web服务架构，底层使用eventlet.httpd作为网络通讯库。
  Require：
         eventlet,
         simplejson(http://cheeseshop.python.org/pypi/simplejson)
  文件说明：
    * auth.py : 实现 HTTP 基本认证.
    * cgiadapter.py : cgi适配器，使得与MU应用作为cgi交互成为可能.
    * console.py : 多用户信息浏览终端，用于维护和监视服务状态。
    * eventrouter.py : Eventrouter 是浏览/服务器模式下的消息传递框架. It's used to build many of the neat little web apps included in mulib.
    * htmlexception.py : 格式化异常信息为html格式
    * logconsole.py : Eventrouter 日志终端
    * mu.py : 给出了来自mulib大多数最重要的API函数, 如：mu.Resource
    * nodes.py : 实现基于http的出版/订阅机制.
    * shaped.py : 用于描述python objects的meta信息的系统。, using python objects. E.g. a list of ints [1, 2, 3] has the shape [int]. Also at the proof-of-concept stage.
    * resources.py : mu.Resource的有用的子类.
    * shellconsole.py : 在浏览器中与python shell交互, 使用eventrouter实现
    * sourceconsole.py : Interactive source code browser for eventrouter. It's been a long time since anyone has looked at this code, it probably needs some freshening up.
    * stacked.py : 基于URL的递归遍历Python 数据结构。The various consume methods match up path segments from a url with a hierarchical data structure. The produce methods convert data for transport over the wire. The names of these methods are somewhat confusing, we could use some better ones.
    * testconsole.py : Unit test running and reporting application built with eventrouter.
    * tests.py : A place to keep test utilities. Lightly used, but it will become more useful as test coverage grows.
    * virtual.py : 虚拟主机(Host)实现(i.e. dispatching based on the Host header).
    * caps.py:  capability 服务，客户(Viewer)请求capability服务获取对特定功能的访问。
      URL Spaces(capability 提供的三个服务):
        /cap/grant
          调用该服务将记住Private URL，并返回一个Public URL（Capability 服务的代理地址）
        /cap/multigrant
        /cap/revoke
          取消某个PublicURL对应。
        /cap/UUID 为调用capability 代理服务。
      例子：看看登录的时候如何获得 AgentHost会话的(Seed) Capability 服务URL，首先客户进行登录（login server），login Server 在 AgentHost上启动一个新的会话，AgentHost想授权客户能访问该服务，于是AgentHost将该会话(seed)服务的私有URL传递给capability 服务，执行 /cap/grant ，返回该seed服务的PublicURL，然后AgentHost将该PublicURL地址发给登录服务，登录服务在作为登录响应一起返回给客户。
      好了，下次你就可以和AgentHost会话服务交谈了——通过Capability 代理服务。连接该PublicURL，实际上是连接上Capability 代理服务，Capability 代理服务然后在查找public对应的 privateURL，并将动作转发给该privateURL。 AgentHost Seed服务将检查你访问授权，通过之后才返回给你新的PublicURL去访问新的服务。
      利弊分析：
        利： 客户端不需要每次服务都去认证，不用保持用户会话信息，服务端也不用去管理实现用户权限验证。这由AgentHost中的 Seed capability 服务来解决，问题是它是如何知道哪个服务该授权给用户的？
        Seed Cap 需要知道每一个服务模块，以及如何访问他们的URL。目前SL的用户权限比较简单，只要为“居民”和“神”两类，
          其它某些服务需要处理他们自己处理认证并以某种方式连上会话服务用以获得权限。这个时候Cap可以很容易的把他们插接在一起。
        弊：网络流量增加。你不能直接知道你想使用的服务URL地址，你必须去Seed Cap服务询问获得该服务的URL。这意味着一次服务，需要两次Http连接请求（当然服务的CapURL地址可以在客户端缓冲）。
            seed cap服务必须知道每一个服务，以及如何去调用它。这不算什么大问题，从另一个角度看，也许还是优势——客户端用不着知道所有的服务。

SL目前采用的是 http REST轻量级SOA＋专用协议(区域主机)，数据序列化格式目前使用的是XML，将来会增加Binary和Json格式。

SL的设计目标：
  虚拟世界区域可伸缩性能
    * 6千万地图区域 (或更多)

  居民数量伸缩性：
    * 20亿用户

  同时在线用户数量伸缩性：
    * 5千万 - 1亿的同时在线用户(无论来自哪个平台)

SL的核心架构是由区域(Region地图)世界域Domain和角色（Agent）世界域Domain构成。

一、区域(Region地图)Domain

区域(Region地图)又分为区域服务，区域主机(Host)和区域数据仓库(Stores)等服务。
区域服务是用Python编写的无状态的HTTP/REST Service,区域主机则是专用协议高效的在某个区域的消息状态服务，处理该区域内的一切交互，而区域数据仓库则是数据层服务。
区域服务用于处理和区域相关的无状态信息：
    *  Avatar 位置
          o avatar 在缩略图上的位置 (绿色的小点)
          o 来自其它角色的请求
                + 交谈
                + God / Support level
    * 对象信息
          o 元数据 (名称 / 说明 / 待售)
                + 搜索
          o 任务物品
          o 地理位置
                + 打造地图图像
          o 区域统计 (FPS/Frame Times/etc)
    * 土地信息
          o 名称 / 说明
          o 当能搜索才公开

区域主机用于处理该区域的一切交互行为，也就是在SL中常提到的simulators。
    * 物理引擎
    * 脚本执行
    * 本地 avatar/脚本化聊天

区域主机的划分是一个有意思的课题：
  区域的适度大小划分
  区域的角色（Agent）数
    物理运算的能力
    脚本执行能力
可惜这部分并没有开源。

区域数据仓库

区域数据仓库存放了某个区域的数据：
    *  对象信息
          o 地理位置
          o 形状/贴图
          o 链接/组关系
          o 物品
          o 元数据
                + 名称 / 描述
                + 许可
                + 版本信息
    * 区域信息
          o 许可
          o 贴图
          o Logs
          o Metrics / Stats
    * Parcels(一小块土地)
          o 元数据
                + 名称 / 描述
                + 许可
                + 元数据
          o 搜索设置

角色（Agents）

角色(Agents)也同样分为角色服务，角色主机（Host）以及角色数据仓库等服务。
角色服务用于处理角色相关的无状态信息，角色主机（Host）服务实际上角色会话服务，保持的是和角色相关的状态的信息，同样角色数据仓库为其数据层。

     摘要: 云式计算既描述的是计算平台也描述的是应用平台,从应用平台角度来说是云式计算基于分布式处理、网格处理和并行处理的商业化实施，它信奉的观点是SaaS(软件即服务)，强调处理无所不在的分布性和社会性。而从计算平台的角度来说，云计算的目标是解决超大规模数据中心的分布式计算的问题。  阅读全文