InfoQ

InfoQ

文章

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

基于Facebook和Flash平台的应用架构解析(二)

作者 Jeanette Stallons 译者 罗小平 发布于 2009年8月26日

领域
架构 & 设计,
企业架构,
语言 & 开发
主题
Web 2.0 ,
企业架构 ,
企业信息集成 ,
Java ,
平台 ,
RIA ,
架构
标签
API ,
Flex ,
Adobe ,
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文件的访问权:

    <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中)。

阅读英文原文Understanding the architecture of applications built on the Facebook and Flash Platforms

相关内容

基于Facebook和Flash平台的应用架构解析(一)


译者简介:罗小平,上海某大型公司互联网中心技术总监,CSDN大版主,网络ID为lxpbuaa(桂枝香在故国晚秋),曾著有《Delphi精要》一书。个人博客为http://blog.csdn.net/lxpbuaa,他的Email和MSN为lxpbuaa AT 263.net

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

深度内容

专访Jeffery Richter:Windows 8是微软的重中之重

Jeffery Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffery Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。

解析JDK 7的动态类型语言支持

随着JDK 7的发布,字节码指令集终于迎来了第一位新成员——invokedynamic指令。这条新增加的指令是JDK 7实现“动态类型语言(Dynamically Typed Language)”支持而进行的改进之一,也是为JDK 8可以顺利实现Lambda表达式做技术准备。在这篇文章中,我们将去了解JDK 7这项新特性的出现前因后果和它的意义。