评论专栏: 使 Web 2.0 趋向成熟

Web 2.0 迅速成为主流应用程序。富互联网应用程序和社交网络比比皆是。浏览器的日益成熟、网络速度的迅速增长、以及 HTTP 基础架构的建立都铸就了这一切。Ajax 是客户端的主要服务调用模型。中间件逐渐无用武之地。然而在这种情况下,构建现代应用程序时仍然有许多人墨守陈规,这就会导致技术方案变难。 本文来自于 IBM WebSphere Developer Technical Journal 中文版

Roland Barcia (barcia@us.ibm.com), Software Services for WebSphere, IBM

Roland Barcia 是一位高级技术人员,并且是 IBM Software Services for WebSphere 的一流 Web 2.0 架构师。他是 IBM WebSphere:Deployment and Advanced Configuration 和即将推出的 Persistence within the Enterprise 的合著者。


developerWorks 2 星大师作者

2010 年 8 月 19 日

解放思想

应用程序在不断演化当中,基础架构和最佳实践也是。图 1 是在 Java™ EE 中常见的一个经典 Web 架构例子。在这个架构中,应用程序服务器被看作既执行业务逻辑又处理 Web 事务。除了执行事务逻辑之外,运行在此架构中应用程序服务器上的应用程序必须:

  • 生成 HTML。
  • 组合 HTML 布局。
  • 处理一个 Web 页面向另一页面的流动。
图 1. 经典 MVC
图 1. 经典 MVC

Struts 和 JSF 这类架构提供设备管理。对于如今的许多应用程序来说,这类架构仍然有重大作用,但是对这个应用程序模型存在负面影响:

  • 这些典型的应用程序依赖于 HTTP 会话状态。久而久之,这将导致 HTTP 会话变得十分庞大,因此影响应用程序的可伸缩性。会话状态越庞大,对可伸缩性和执行能力的影响越大。
  • 服务器的内存占用通常比较大。很多时候, 框架维护应用程序视图的内存副本,例如,创建维护 UI 树所需对象和任何请求限定对象的一个典型的 JSF 应用程序。这会随着 UI 对象的垃圾收集而增加 CPU 周期。
  • 紧耦合开发是这种方法的另一个劣势。Web 页面开发人员与创建业务逻辑的开发人员的技 能不同。Web 开发人员往往在语言、HTML、CSS 和脚本呈现方面较为娴熟。他们常常使用 WYSIWYG 编辑器、脚本编辑器和浏览器调试工具之类的工具。他们经常为实现 Web 页面可视化而进行快速变更,且频繁四处移动。业务逻辑开发人员通常精通数据访问、消息传递、事务处理和整合,且精于使用各种工具。

由于浏览器现在可以托管富互联网应用程序了,它会是一个一流的服务使用方。Dojo 等工具包启用了一整套 UI 工具。 浏览器现在可以管理这些事务:布局管理、组件之间的 Web 流、MVC、Web 状态和其他 Web 事务。应用程序服务器现在可以处理数据呈现、执行业务逻辑和业务流,且变得越来越无状态和可伸缩。图 2 展示了一个现代风格的 Web 2.0 应用程序。

图 2. 现代 Web 2.0 架构
图 2. 现代 Web 2.0 架构

这种方法有许多优点:

  • 视图显示逻辑向浏览器移动,这使服务器更为无状态且更加可伸缩。
  • 服务器内存占用减少了,因为保持请求级别状态只需较少的对象。
  • UI CPU 周期移出到浏览器以外,这使得业务服务层减少 CPU/资源争用。
  • Web 开发人员依赖于无处不在的 Web 核心技术(HTML、JavaScript™ 和 CSS),而很少依赖于服务器端技术。
  • Web 研发更为灵活。因为模拟 JSON 之类的 Web 负载比较容易,现在 Web 开发人员可以勉强接受 Web 服务器。Web 2.0 客户端开发人员不需要功能全面的应用程序服务器,一个普通 Web 服务器或单元测试文件系统也可以。我现有的几个开发工作中,Web 开发人员在无实际服务可用的情况下开发了 80% 的 Web 层。集成测试周期也减少了。图 3 是该模式的一个例子。
图 3. Web 界面
图 3. Web 界面

放松约束条件

在企业中, 我认识到我们不能总是完全基于客户端浏览器进行 UI 呈现。对此有几个原因。最重要的一个是安全逻辑。因为浏览器一般用来查看资源,而有些逻辑您又不想让客户浏览。这种情况下,就需要服务器端页面了。例如,您可以将您的纯 HTML 内容包装在一个 JSP 中,然后实现一些逻辑。UI 逻辑例子在服务器上运行是否安全取决于终端用户在浏览器上可以看到什么。图 4 展示了这个例子。

图 4. 安全逻辑的服务器呈现
图 4. 安全逻辑的服务器呈现

当您想隐藏决定终端用户所见内容的 “逻辑” 时,这个模式是最好的选择。关于初始载荷,您可以用一个简单的服务器页面标记同业务逻辑对话来进行管理。

然而,我想将这同隐藏用户不能查看的数据选项区分开。例如,假设您不得不呈现一个动态表单,并隐藏基于用户权限的输入字段。您可以轻松建立一个 JSON 元服务,它仅提供许可字段(仅向浏览器提供这些字段)和有一个通用客户端呈现器,使用 DTL in Dojo 这样的技术。图 5 展示了这个模型的一个例子。

图 5. 带有元服务的动态表单
图 5. 带有元服务的动态表单

难上加难

很多情况下,一个简单的服务器页面包装器就足够了。然而,发开人员经常在经典 Web 风格和 Web 2.0 风格架构的混合中走向极端。例如,JavaServer Faces (JSF) 等技术在服务器上提供了一个完整的组件呈现模型。如果您继续保留黑箱模式,您可以使用这个模式勉强对付;有人认为,服务器小部件部件模型中的输出是一个黑箱。服务器小部件的提供者能够改变一个组件在浏览器中的显示方式。

不过这只是我的经验,您绝不能 100% 使用这个模式,且经常不得不偶尔加入一些本地代码。在这个模式中,加入本地代码的次数可能要更多一些,因为服务器端工具包通常落后于新的、更丰富的组件。在这个方面,UI 层的风险较大,因为对那些经常改变需求的业务人员来说,它是一个可视层。一旦您必须向代码中增加定制的 Ajax 和 JavaScript 行为,您的实现开始一分为二且受损的风险更大。因为 JavaScript 经常不得不同一个服务器组件产生的显示代码进行会话,您只能任由底层小部件集发生变更,这是不容易演化的。

图 6. 混合呈现将引发破损和膨胀
图 6. 混合呈现将引发破损和膨胀

模式演变的下一步是用一个工具包(比如,JFS)包装另一个工具包(比如,Dojo)。这经常发生,因为人们更习惯使用 Java,且认为底层呈现模式是一个熟悉的工具包,它可以抵消黑箱问题。然而以我的经验,开发人员经常不得不成为服务器小部件和底层客户端小部件技术这两方面的专家,因为他们必须排除故障和维护系统。因此,您失去了成为一个纯 Java 开发人员的价值, 更不用说这个模式将使您的架构臃肿:

  • 您可能要为服务器和浏览器中的内存付出双倍的代价。浏览器上有 DOM 和小部件,而服务器上有 JSF 树。
  • 您错过了界面解耦议题。Web 开发人员现在需要浏览器工具和一个完整的 Java 应用程序服务器来执行全面测试。

在您支持 Open Web 技术、Flex 和 Mobile App 平台等多个互联网 UI 范例的场景中,JSF 这类技术仍具有实用性。您可能想要保留带各种呈现功能的一套组件,但这仅适用于特殊情况。

图 7. 服务器呈现应当关注多渠道
图 7. 服务器呈现应当关注多渠道

Web 2.0 成熟度

像 Dojo 这类浏览器端技术和 JAXRS 这类客户端技术正在日益成熟。我曾参与了若干项目,这些项目使用纯 Web 技术成功交付了 Web 2.0 应用程序。此外,使用类似 Dojo 的框架可使代码易于维护且容易演化,更多迹象表明框架已经随着时间的推移而走向成熟。Web 2.0 成熟度的不同阶段:

  • 可视化

    用户界面在继续驱动 Web 上的大量应用程序。就这点而论,满足 Web UI 可视化需求是关键。

    图 8. 可视化
    图 8. 可视化

    UI 设计人员和开发人员必须紧密合作。UI 设计人员必须精通 CSS 才能在这个世界上得以生存。一旦您使数据可视化,这将导致您的 REST API 首次迭代的形成。

  • 公开

    当您明白了您的用户可视化数据的方式,规划您的 REST API 是走向成熟的下一步。REST 是 World Wide Web 的设计原则,World Wide Web 旨在以可伸缩的方式提供浏览内容,含有链接其他 Web 页面的 Web 页面。整个页面被传输给用户,即状态传递。基于 REST 的 Web 服务是围绕建立无状态 Web 服务来向客户传递资源这一原则设计的。资源用一个 URI 描述。以这种方式设计 Web 服务有很多益处。

    REST 围绕约束集创建 Web 服务。以既定方式使用 HTTP 来遵守约束能够使服务提供者优化这些模式。通过遵守约束,您可以更好地利用 Web 基础设施。为传递最佳 Web 内容,路由器、缓存代理(包括浏览器中的缓存)和 Web 服务器经过优化。例如,通过在您的数据服务中设置某个缓存消息头,您可以将浏览器作为一个自由缓存使用。通过这些渠道交付您的服务也可以使其达到最优。REST 围绕 REST 式原则交付 SOA,遵循 Web 架构。

    当您的 REST API 演化时,您可以为新的可视化提供机会。您的用户可以选择您的 Web 可视化,也可以按照 REST API 创建他们自己的可视化。新客户有助于 REST API 的演化。

    图 9. REST API
    图 9. REST API
  • 社会化

    在 Web 2.0 中社交方面至关重要。提供 REST API 能帮助创建社交团体,因为您的内容格式可以通过简单的互联网渠道使用。许多人已经意识到这个价值。例如,我在 developerWorks 上的博客可以通过一个 Atom 提要得到。由于一个 REST API 是围绕内容提供的,现在我可以通过我的 Facebook 页面提供我的博客,这样使我的 Facebook 社区和 developerWorks 读者都能从中获益。

    图 10. 内容社会化
    图 10. 内容社会化

    实现内容社会化是 Web 2.0 走向成熟的下一步。尽管您可能不想让您的所有内容对公众开放,企业们逐步意识到防火墙后内部团体的价值。

Web 2.0 技术为您的开发过程提供了诸多益处,包括系统的可伸缩性和数据获取,但是一些您自己的传统系统可能会阻碍 Web 2.0 趋向成熟。开始接受 Web 平台并通过采用现代架构使其发展,这是很重要的。


致谢

作者感谢 Kyle Brown 和 Chris Mitchell 审阅本文并提出宝贵反馈。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, Web development
ArticleID=509527
ArticleTitle=评论专栏: 使 Web 2.0 趋向成熟
publish-date=08192010