当前页面: 开发资料首页 → J2EE 专题 → 不是魔术 -- 只是Alchemy

不是魔术 -- 只是Alchemy

摘要: 不是魔术 -- 只是Alchemy

Daniel H. Steinberg

当您正在飞机上时，想要查看一下正要去拜访的一位客户的记录。您打开浏览器，输入 URL 并且滚动客户列表来找到这名客户。正在您准备点击正在寻找的客户的名字时，邻座的乘客大惑不解：您没有连接到网络。您怎么能浏览一个网站呢？

您点击了客户名称并且查看了他的记录。您希望在记录中添加一个注释来表示今天早上登机之前给他打过一个电话。您点击“保存”按钮然后得到一个标准的确认，您所做的更改已经完成。在客户名称上点击“后退”来确保所做更改已反映在您的浏览器中显示的页面上。您旁边的乘客问您这是不是一个魔术。而您则微笑着说：“这并不是魔术，这是Alchemy”。

过去是序幕

像 Alfred Chuang和 Scott Dietzen在他们的开幕式主题演讲中所做的那样，Adam Bosworth 基于对过去的回顾对浏览器的发展趋势做了一个评论。他说：“要理解您正在走向哪里，您需要知道从何处而来”。

Bosworth 然后谈到了与出现因特网之前的应用程序相比在因特网上的应用程序的意义。他解释说，1992 年前后客户端－服务器计算开始发展起来，因为您一旦有了很多可以做为客户端的计算机的时候，共享服务器的价值就变得极为重要。随着因特网的发展，将任何应用程序连接到任何其他应用程序并将它当作一个服务来使用就成为可能。Bosworth 说，在 1994 和 1995 年我们不知道这种机制将能够很好地工作，但是从中发展出了我们今天称为 Web 服务的架构。

Bosworth 解释说，服务背后所隐藏的思想是您再也不能关闭应用程序，因为到处都有使用您的服务的程序。这意味着您必须全天候待命。您无法知道在一个指定的点您会接收到多少请求。问题在于在某些点您将改变应用程序的功能。这常常需要您关闭应用程序来改正错误或者增强功能。Bosworth 说，我们现在通过使用一种元数据驱动的模型可以避免这种情况，在这种模型中您只需要修改元数据，然后系统就会自动重新配置一个正在运行的应用程序。

在回顾过去的时候，Bosworth 说到，大约 15 年之前我们使用客户端－服务器模型，无论我们何时需要任何数据或者想要修改任何数据，都可以访问服务器。一旦一个应用程序被连接到因特网上用作一个服务，一个被过于频繁查询的数据库就可以使之濒临崩溃。我们已经学习了一些诸如发送远程请求并且查询返回结果等的一些技术。这意味着如果我们想获得一个顾客的姓氏、名字和邮政编码等，我们不需要对每一个内容都发送一次单独的数据库请求。在 PowerBuilder 中演示了一种方法，它使得用户可以取得一个快照，然后查询快照并且对快照进行更新。当然，困难在于当不同的用户在以冲突的方式修改同一个记录时如何重新同步数据。

发送消息

Web 服务的使用要多于远程过程调用。Bosworth 说 WSDL 模型非常成功，但是补充说，工业上建立该模型时将它建成了同步模型。如果您调用一个关闭的应用程序将会怎么样呢？如果负载处于峰值而应用程序被阻塞了又会怎样？如果网络发生故障又将如何？您不想让您的本地应用程序被阻塞或者不必要地失败，而这只是因为您在应该使用异步调用的时候使用了一个同步调用。

在可能的地方或者如果有任何疑问，将会返回对您的请求的响应，您应该发送一个消息并且在您醒来的时候应该收到一个返回消息。您发送了一个请求然后进入休眠，所有您的数据都处于休眠状态，当您得到响应的时候唤醒这些数据。您甚至可以在一台完全不同的计算机上醒来。您可以在家里的 PC 上发送请求并且可以在上班的路上从手机上收到响应。问题在于这种模型很难编程实现。

Bosworth 再一次回顾说 15 年前我们曾在一个不同的领域－－客户端计算――中遇到过这个问题。我们正在进入到 GUI 时代，用户可以自由地点击任何地方、进入菜单或者从工具栏中选择一个工具。用户在管理一切。那里的解决方法是发送窗口消息。随之而来的范式是表单。

我们在服务器中使用基于消息的通信的时候，如何隐藏 API 的复杂性呢？Bosworth 说行业是围绕业务处理建模来进行标准化的。他回想起早年数据库调用标准的缺乏和他坚持建立 ODBC 的信念。除了所有自由的建议之外，他被质问为什么这种层次的标准化难以进行或者不起作用，他发现一旦具备了一定的生态系统，简化数据库连接的价值就会被广泛接受。

Bosworth 说有了服务模型，他被告知“您不能制定标准”。和以前对待 ODBC 一样，他说经济学是正确的，摩尔定律将推动标准化的进行，从而每个人都可以接入到这种中间件总线。我们将需要开始管理消息、规范和调度消息。需求包括对消息排定优先级和监视以及汇集相关消息。Bosworth 说今后我们会使用更多的异步调用，并且确保您的应用程序待命的唯一方法是通过元数据驱动的编程和松散耦合，在这个过程中，前面所说的需要将被满足并且用户的体验将会得到改进。

基于浏览器的前端

Bosworth 曾参与一个调查，该调查预言 60％的客户端应用程序将会是 GUI，25％是传统程序，剩下的 15％将是使用 HTML 表述的廉价的面向用户的应用程序。浏览器和HTML的重要性被大大低估了。HTML 代表了多于 80％的市场。

建立一个应用程序的成本在部署、维护和支持面前显得苍白无力。考虑一个 GUI 应用程序的部署。在 B2E 应用程序中，一个公司可以大量生产 GUI 前台终端，因为他们自己的 IT 部门了解目标机器。该过程是痛苦的但是还是可行的。在 B2B 中，现在您必须支持拥有您的公司不能控制的系统和配置的伙伴。对于 B2C，需要支持的平台范围有一次戏剧性的增长。与之形成鲜明对比的是，Bosworth 说，部署一个基于浏览器的应用程序只需要提供一个 URL。

回顾一下产品的生命周期，每次调整和修改一个应用程序的时候，您都要不辞辛苦的进行发布过程。Bosworth 指出，在这种情况下，我们很少能理解支持的含义。他说：“GUI 可能是丰富的并且有交互性，但是它们可能不是自明的”。

移动计算的增长再次将我们带到了一个转折点，我们需要重新考虑我们应用程序的客户面对的组件。Bosworth 说，首先业界认为我们应该为移动计算做我们为 PC 做的同样的事情，但是用户的感受是糟糕的。在一个 PDA 上，您得到一小段信息然后点击一个按钮或者链接来继续。每次您点击的时候，都要对服务器进行一轮访问。在一个移动的世界里，您的连接可能是受限值的。如果您断开了连接，您点击的结果可能是期望的结果、一种假象、一个错误或者一个长时间的延迟。

可能看起来这表示解决方法是回到富应用程序（rich applications），但是 Bosworth 警告说，移动式富应用程序更难以开发，因为它们总是有很多部署困难。返回到产品生命周期，他推断说看起来得在用户体验好、总拥有成本高的应用程序和相对用户体验差些但是总拥有成本低的基于浏览器的移动应用程序之间做一个折中了。

Alchemy

Bosworth 看到了基于浏览器的应用程序在部署、支持和维护方面的优点，这使得他重新考虑移动应用程序提出的挑战。他提出的解决方案是扩展浏览器模型，并且考虑要将基于 Web 的模型应用到一个连接速度很慢、断断续续或者是断开的环境中需要什么。

Bosworth 邀请他的儿子 Alexander 在舞台上展示其概念证明，它的代号为 Alchemy。Alchemy 是一个 Web 浏览器，它有额外的功能从而在你连接状态不同时它的行为也不同。作为一个类推，您可能希望能使用富邮件客户端来编写邮件并且阅读比您上一次同步旧的消息。当您再次连接到网络时，您的本地版本就会和服务器上的版本同步。

设想如果在一个基于 Web 的邮件客户端中您可以使用这些功能。如果您处于连接状态，您应该可以在浏览器中点击消息列表来阅读、恢复或者删除消息。如果您的连接断开了，Alchemy 将允许您进行同样的更改，只是这些更改要在以后您连接到网络的时候才能完成。

考虑当您处于连接状态或者断开连接时，需要什么才能使用户有良好的体验。这需要一个扩展，就是说通过增强浏览器和服务器的功能来浏览现有的信息。每次您在浏览器中点击某些东西时，系统必须解决如何处理才能不阻塞您。如果您有一个好的连接，您应该可以看到最新的数据。通过使用智能高速缓存和后台联合组织，您应该也可以在连接不好或者没有连接的时候和应用程序交互。

Bosworth 说如果 BEA 沿着这个方向发展并且构建一个产品，该公司将会开放该框架的源代码，这与他们和 Beehive 一起公开 WebLogic 框架的源代码的方式是一样的。这意味着即使您没有一个智能的客户端，服务器仍可以启用一些同步和缓存功能。尽管这不是Bosworth 的优先选择，他认识到有时您想要部署一个富客户端。高速缓存架构和同步机制也应当可用于富客户端。