如何为混合 Web 应用程序改进浏览器 ![]() |
![]() |
级别: 中级 Brent Ashley ([email protected]), 总裁, Ashley IT Services, Inc. 2007 年 5 月 09 日 当前的 Web 浏览器设计不能轻松而安全地从多个源获取内容并将其显示到页面上。了解开发人员如何充分利用可用的工具来完成该任务,以及使用这些工具给所得应用程序带来的安全和可伸缩性方面的压力。另外,学习提出的几种用于补救此情形的浏览器改进,以及如何参与相关讨论,使 Web 开发超越这一障碍,使互操作性达到的一个新水平。<!----><!----><!---->
mashup 是一个 Web 应用程序,它集成了来自多个源的内容并将其交付到一个页面中进行显示。服务器向每个内容源发出请求,解析收到的信息,并将结果综合到一个页面中发给浏览器,如 图 1 所示。 图 1. 混合来自多个源的内容 Asynchronous JavaScript + XML(Ajax)应用程序 使 Web 页面能从服务器获取内容并使用 JavaScript™ 代码异步地在适当位置进行自我更新,如 图 2 所示。这样,用户就可以与富用户界面 (UI) 进行交互而无需重新加载整个页面。服务器向浏览器发送初始页面,后者回调服务器以获取更新后的内容。异步的 JavaScript 代码调用频繁使用 XML 来编码数据;但是,其他的数据格式则更通用,如 JavaScript Object Notation (JSON)、HTML 和分隔文本。 图 2. 使用 Ajax 的交互式数据显示 Ajax mashup 是一种混合的 Web 应用程序。它使用 Ajax 技术来显示富 UI,此类富 UI 使用从多个源异步检索到的内容在适当位置进行自我更新。服务器向浏览器发送初始页面,后者发出调用以检索更新后的内容。这些调用可从浏览器直接发往第三方源或者发回初始服务器,初始服务器用作第三方内容的代理。
当设计包含当前浏览器环境的元素时,没有人注意到 Ajax mashup。浏览器、超文本传输协议(HTTP)或 HTML 或专门设计用于容纳浏览器的(以一种安全而健壮的方式)异步检索多个源中内容的功能的 XHTML 都没有内置任何组件。World Wide Web Consortium (W3C) HTTP 规范中的一些可能用于 mashup 的一些特性(如 Document Object Model (DOM) Level 3 Load 和 Save Specification)并未由大多数浏览器完全实现,或是根本没有实现。 Dynamic HTML (DHTML) 开始时不与动态检索到的内容结合使用。动态 Web 页面的显示和数据元素都与操作它们的脚本一起交付。这些脚本将显示、隐藏、移动、创建和销毁文档对象以便实现动态效果,但是一旦需要从服务器获取更多数据,原页面就被新页面取代。数据流与页面重新加载同步。 因此,希望构建混合 Web 应用程序(现在称为 mashup)的开发人员必须利用可用的技术设法对其进行扩展以满足他们的需求。有两种方法可使浏览器在无需重新加载页面的情况下检索内容:嵌入外部传输机制和使用浏览器本地对象执行传输任务。 早期的解决方案是 Microsoft 的 Remote Scripting,它使用一个 Java™ applet 与服务器端组件交换 XML 格式的消息。此方法很快就因为供应商的争论以及 Java Virtual Machine (JVM) 和安全模型的差异而变得不实用。 Microsoft 稍后构建了 很多开发人员使用 Macromedia Flash 的 XML 通信特性来构建可嵌入的组件与服务器进行通信。 由于外部传输机制相关的问题和依赖性,互联网开发团体协作发现并开发了几个浏览器本地的远程调用方法。
请参阅 参考资料 中关于这些工具和技术的详细信息的链接。
大多数可用于异步检索内容的技术都继承了 JavaScript 安全模型的安全性,它使脚本只与源于该脚本所属页面所在的同一服务器的元素进行交互。这就是所有浏览器都实现了的同源策略(Same Origin Policy)。 要让 Web 页面从第三方检索内容,必须避开同源策略。常用的不受同源策略限制的例外是 使用
当前广泛用于启用 Ajax mashup 的工作区都会产生一些代价。当扩展浏览器的设计限制时,就会影响应用程序总体操作的其他方面。这种做法通常会导致应用程序的安全性或可伸缩性降低。 当受到浏览器的同源策略限制时,承载应用程序的服务器必须承担获取第三方内容并将其发送到客户机的任务。服务器除提供常规的服务器功能外,还担当第三方服务的客户机的角色。 使用服务器作为每个客户机事务的代理意味着大量用户可能导致过度的服务器负载。使用此技术的应用程序需要设计成服务器端可伸缩,使用多个同等的服务器处理请求负载。 使用
很明显,浏览器当前提供的用于 mashup 的工具不能构建同时具有可伸缩性和安全性的应用程序。开发人员必须找到从当前和长远角度来看都有效的解决方案。 一种最近开发的内容检索技术通过其 由于脚本必须了解彼此的地址并且它们自身之间必须协作以取得对协议的一致遵守,因此要确保信任。由于任何服务器交互都在每个组件本地并且与脚本间通信分离,因此不会暴露 cookie。 虽然仍不完美(例如,它依赖于设计行为以外的异常,并且查询更改不如用事件激活来响应更改),但是这个解决方案比任何其他方案都更接近于提供浏览器本地的、安全的、页面中的跨域通信。 请注意:James Burke 是 AOL Developer Network 的一名开发人员,他开创了片段标识符技术并将其构建到最新版本的 Dojo Toolkit JavaScript 库中。 浏览器制造商和开发团体当前正在讨论几种可能的修改浏览器环境元素的方法,使其以 Ajax mashup 为构建目标。Web Hypertext Application Technology Working Group (WHATWG) 在其用于 Cross Document Messaging 机制的 Web Applications 1.0 Working Draft 的 7.3 节中提出了一个建议。Opera 浏览器已经实现了此特性。它指定了不同域中的 DOM 对象之间协作通信的方法,该方法允许消息的接收方根据消息的起源来选择所要响应的消息。 Ian Hickson 以前任职于 Opera,现在任职于 Google。他提出了对现有的 Douglas Crockford 是任职于 Yahoo! 的一名 JavaScript 传道者和架构师,他是全球最有造诣的 JavaScript 语言专家之一。您可在他的个人 Web 站点上及通过 Yahoo! Developer Network 找到很多他的解释高级 JavaScript 技术的展示和文章。Crockford 提出的另一项计划是 JSON,它是一种 Ajax 应用程序中广泛使用的数据交换格式,其主要原因是易于被 JavaScript 解析并且不像 XML 那样冗余。Crockford 编写了两个提议来将 mashup 敏感的元素构建到浏览器中。 几个绝妙提议可帮助您应对此困境:
请参阅 参考资料 中关于这些提议的详细信息的链接。
作为开发人员,我们都与这些讨论的结果息息相关。通过参加讨论,您可帮助设计最灵活、安全的浏览器改进,使所有人都能构建健壮而安全的富 Web 应用程序。我鼓励您去寻找倡导浏览器改进的浏览器供应商和组织,并参与以下活动:
您可在本文的 参考资料 部分找到可作为起点的链接。 学习
获得产品和技术
讨论
|