• 基于Facebook和Flash平台的应用架构解析(二)
    时间:2012-02-11   作者:罗小平   出处:互联网

    Flash平台可帮助你构建富用户体验的应用,而Facebook平台可帮助你构建富社会化体验的应用。将二者合而为一,你就可以构建高交互性、富于表现力,并融入了社会化功能的杀手级应用了。
    1. 基于Facebook和Flash平台的应用架构解析(一)
    2. 基于Facebook和Flash平台的应用架构解析(二)
    3. 基于Facebook和Flash平台的应用架构解析(三)

    Flash iFrame Facebook应用

    至此,我们已经介绍了iFrame和FBML的情况,接下来开始讨论在应用中如何集成Flash内容的问题。虽然你完全可以构建一个包含了 HTML/JavaScript/ActionScript的混合应用,但为了说明的方便,我们还是将注意力集中在基本的Flash应用层面——其全部视 觉效果和功能都封装在SWF文件(Flash Player可识别并渲染的、编译后的字节码格式)中。 在上述混合应用中,可以使用到多种API调用,比如服务端API、前面已讨论过的客户端JavaScript API,以及这里将讨论的客户端ActionScript API调用。 你可将SWF文件集成到iFrame或FBML应用中。图3说明了在iFrame应用中的简单实现方法。

    图3 Flash iFrame Facebook应用

    1. 用户在Facebook站点上访问你的应用时,浏览器向Facebook服务器发出一个HTTP请求。
    2. Facebook服务器返回一个HTML/JS页面,其中包含Facebook站点容器和一个iFrame HTML标签。
    3. 用户浏览器向你的服务器请求包含在iFrame中的页面。和前面讨论过的情况不同,这个页面不再是一个服务端页面,而是一个简单的 HTML页面(内含SWF文件)。此时,Session信息仍通过GET请求的URL参数传递;你的服务器解析这些参数,并转换为内嵌的SWF所需的 flash参数,这样,在SWF中的ActionScript代码就可以根据这些参数,直接向Facebook服务器发出请求了。
    4. 你的服务器将HTML/JS页面返回给用户浏览器,并在iFrame中展示。
    5. 用户浏览器向你的服务器发出其他请求,即请求展示在iFrame中的HTML页面中内嵌的SWF文件。
    6. 你的服务器返回SWF文件。

    当用户和你的应用交互时,SWF可向Facebook服务器、或你的服务器发送异步请求。

    • SWF文件中的ActionScript脚本直接访问Facebook服务器(步骤7-8)。你可以使用Google代码中的ActionScript 3.0 Library for Facebook Platform
      出于Flash Player安全性的考虑,SWF文件只能从两类服务器获取数据:(1)提供SWF文件的服务器(这里即你的服务器);(2)有跨域策略文件(在文件中列 出了SWF来源服务器)的服务器。也就是说,若要你的SWF能直接访问Facebook服务器,Facebook服务器必须在跨域策略文件中开放了访问权 限。如果看过Facebook的跨域策略文件,你会发现它通过一个通配符,授予了来自任何服务器的SWF文件的访问权:
      1
      2
      3
      4
      <cross-domain-policy>
            <site-control permitted-cross-domain-policies="master-only"/>
            <allow-access-from domain="*"/>
       </cross-domain-policy>
    • 你的ActionScript访问Facebook服务器时,必须像前面非Flash的iFrame和FBML应用部分讲到的那样,传送 应用API Key和用于说明访问来自何处的签名信息。利用ActionScript 3.0 Library for Facebook Platform中的类可自动生成签名;为此,你只需向ActionScript session类的构造函数传入应用的API Key和密钥。

      但是,你不应在SWF文件以硬编码方式写入上述数据,因为SWF文件可用多种软件反编译。相反,SWF应该在运行时向你的服务器发出请求(可 HTTP或Flash Remoting方式),从而获得应用的密钥,接下来再传给ActionScript session类的构造函数,从而生成访问Facebook服务器时所需的签名。

      记住,此签名由下列信息组成:传递给Facebook服务器的URL参数、Session Key(用户访问你的应用时分配)的MD5哈希串、应用的密钥等。
    • 若需实现任何服务端处理功能(如在你的服务器上保存某些数据),可在ActionScript代码中通过远程过程调用方法实现(见步骤 9-10)。对于利用Flex构建的Flash平台应用而言,这些方法包括HTTP、Web Service和Flash Remoting请求技术。其中最便捷的方法当属Flash Remoting——它通过开源的二进制Action Message Format (AMF)实现服务器和Flash Player间的数据交换。当然,服务端代码在向客户端返回数据之前,可根据需要访问Facebook服务器(此点未包含在图3中)。

    Flash FBML Facebook应用

    除了在iFrame中集成你的Flash应用,还可以通过FBML标签<fb:swf>将其植入到FBML应用中。在这种情况中,你的应用会由一或多个服务端页面组成;这些页面包含FBML(用于获取或展示Facebook形式的可视化内 容、对话框和小控件)、不能通过简单的FBML标签实现的服务端API调用,以及包纳了你的Flash内容的<fb:swf>标 签。FBML应用的好处是在访问Facebook提供的社会化特性时非常简单,向Facebook传送FBML标签,就可自动渲染为HTML内容。 而其不足,则是此处在多个地方编写表现层和逻辑层的代码更为复杂:SWF文件中、服务端页面中,以及发向Facebook服务器的FBML代码中(见图 4)。有关iFrame和FBML应用区别的更详细信息,请参看iFrame、FBML Flash Facebook应用比较

    图4 Flash FBML Facebook应用

    1. 用户通过Facebook站点访问你的应用时,浏览器向Facebook服务器发送HTTP请求。
    2. Facebook服务器向你的服务器发出请求——一般请求的是PHP、JSP或ColdFusion式的服务端页面。在这种情况 下,Session信息通过POST请求(而非iFrame中的GET请求)中的URL参数传递,那么,你的应用服务器就知道该请求来自 Facebook、是哪个用户发出的请求了。
    3. 服务端页面执行时,可根据需要访问数据库和其他服务器,当然包括利用REST API访问Facebook服务器。

      API调用必须包含认证信息——包括在Facebook上注册应用时获得的API Key、该调用的签名(通过传给Facebook方法的参数、用户请求你的应用时指定的Session的MD5哈希串生成)、应用的密钥和其他信息。

      对于非Flash的iFrame和FBML应用来说,服务端页面通常可利用现成的代码库实现对Facebook的访问,以及生成签名。因此对于所有FBML应用而言,用户浏览器的所有请求都是通过Facebook代理的,你的应用在请求Facebook服务器时,就没必要每次单独调用一个API;同时,诸如获得用户姓名、图片、生成对话框等等,都可以利用FBML 标签实现。

      Facebook服务器在将页面返回给用户浏览器前,会自动将FBML转换为HTML和JavaScript代码。当然,不是所有功能都有标签支持的,比如要取得朋友的生日信息,还是得从你的服务器向Facebook发送对应的API调用请求。
    4. Facebook服务器将被请求数据返回给你的服务器,格式可为XML或JSON。
    5. 你的服务器向Facebook服务器返回包括HTML/JS和FBML内容的页面。
    6. Facebook服务器向用户浏览器返回HTML/JS页面。该页面包括了(用标签<fb:swf>指定)对你的服务器上SWF文件的引用。
    7. 用户浏览器向你的服务器请求内嵌在HTML页面中的SWF文件。
    8. 你的服务器返回SWF文件。

    在用户和你的应用交互过程中,SWF可向Facebook服务器或你的服务器发出异步调用。

    • SWF中ActionScript代码直接访问Facebook服务器(见步骤9-10),这可利用宿主在Google代码上 官方支持的ActionScript 3.0 Library for Facebook Platform实现。当然,Facebook必须通过跨域策略文件开放了访问权限,且API调用中传送了所需参数。有关这部分的详细问题,前面的 Flash iFrame应用中已有讨论。
    • 若需实现任何服务端处理功能(如在你的服务器上保存某些数据),可在ActionScript代码中通过远程过程调用方法实现(见 步骤11-12)。对于利用Flex构建的Flash平台应用而言,这些方法包括HTTP、Web Service和Flash Remoting请求技术。其中最便捷的方法当属Flash Remoting——它通过开源的二进制Action Message Format (AMF)实现服务器和Flash Player间的数据交换。当然,服务端代码在向客户端返回数据之前,可根据需要访问Facebook服务器(此点未包含在图4中)。
    1. 基于Facebook和Flash平台的应用架构解析(一)
    2. 基于Facebook和Flash平台的应用架构解析(二)
    3. 基于Facebook和Flash平台的应用架构解析(三)

    阅读英文原文Understanding the architecture of applications built on the Facebook and Flash Platforms
    来源:Infoq中文

    网友留言/评论

    我要留言/评论

    相关文章

    基于Facebook和Flash平台的应用架构解析(一):Flash平台可帮助你构建富用户体验的应用,而Facebook平台可帮助你构建富社会化体验的应用。将二者合而为一,你就可以构建高交互性、富于表现力,并融入了社会化功能的杀手级应用了。
    由12306.cn谈谈网站性能技术:12306.cn网站挂了,被全国人民骂了。我这两天也在思考这个事,我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促,而且完全基于本人有限的经验和了解,所以,如果有什么问题还请大家一起讨论和指正。(这又是一篇长文,只讨论性能问题,不讨论那些UI,用户体验,或是是否把支付和购票下单环节分开的功能性的东西)
    百万级PHP网站架构工具箱介绍:Poppen.de是德国的一个社交网站,相对Facebook、Flickr来说是一个很小的网站,但它有一个很好的架构,融合了很多技术,今天我们就来了解一下该站点的架构技术。
    memcacheq队列服务安装与原理:  Memcache是一个高性能的分布式的内存对象缓存系统,通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。简单的说就是将数据调用到内存中,然后从内存中读取,从而大大提高读取速度。
    Nginx + PHP-FPM + APC=绝妙的组合:本文将介绍目前让PHP最快的方法:Nginx + PHP-FPM + APC,看似有些复杂,实际上我们只需要几个步骤就可以完成,并且性能远超Apache,有兴趣的朋友不妨去试一试。
    Facebook图片存储架构技术全解析:Haystack提出了一种通用的基于HTTP的对象存储,它含有指针,映射到存储对象。在Haystack中以指针储存照片,把数以十万计的图像聚集到一个Haystack存储文件,从而消除了元数据负荷。这就使得元数据的开销非常小,并且使我们能够在存储文件和内存索引中存储每个指针的位置。这就使得能用少量的I/O操作来完成图像数据的检索,可以消除一切不必要的元数据开销。
    世界最大的PHP站点 Facebook后台技术探秘:每月570000000000页面浏览量,每个月超过30亿的图片上传,5亿的用户数量,Facebook的后台是用哪些技术保障网站的流畅运行呢?在今年举行的Facebook F8开发者大会上,我们带您了解了其最新的开放图战略和语义搜索。今天我们一起来了解Facebook背后的软件,看看作为当今世界上访问量最大的网站之一,Facebook是如何保证5亿用户的系统一直稳定可靠的运行。
    php-fpm文档中文介绍:起初php-fpm 只有俄文文档,比较郁闷,于是先用 google 翻译先弄成英文,然后再人工翻成中文。这当中会难免会在我自己的英文水平引起的错误之外,再多些错误出来。后来终于有了一个英文的 wiki,并邀请我提供中文翻译。同时,距上一次翻译(2008年5月)以后,原来的文档也已经有了更新。于是我就根据英文 wiki ,重新翻译了一遍。
    超级电驴Mldonkey:查看ADSL的当前流量: sudo ethstatus -i ppp0