简单来说，DWR所提供的是提取Java类，使它们能够方便地被Javascript应用的一个方法。首先取一个Java类，然后你可以告诉DWR“我们想要输出这个”，DWR会为你创建一些stubs，你可以很容易的从JavaScript中调用这些stubs，它会为你处理像类似排序这些事情。主要观点在于，它使你可以从JavaScript中调用几乎所有的Java方法，并且处理像排序这些事情，所以你都可以从浏览器使用map、string和integer的集合，甚至DOM模块。这些都是一些基础的东西。我们还有一个小的DHTML库提供你方法来处理网页。DWR并不是只关于widgets, 基本上，我们处理一系列的事务来帮助你从网页得到你所要的数据。

其实很容易就抱怨所有的浏览器，因为它们都会由于各种原因而崩溃。公平地说，崩溃实际上也不是一个公平的描述，只是最初所有的浏览器都不是为了处理这些而设计的，所以它们有各种不同的响应方式。在AJAX开发中，真正的挑战是找出一个方法使它在所有的浏览器的不兼容中正确工作，我的工作就是确保用户不会再面对这样的难题，这个难题是我的。所以实际上这是最大的挑战。

是的。到目前为止，我们所讲的都还是DWR 1.0的基础，它都是关于从浏览器向服务器调用。但是现在，我们正在做的是反向来处理。你将可以在服务器异步发送命令到浏览器。所以，你可以很容易地说：“返回给我正在访问这个页面的所有的浏览器” 或者“提供给我这个特定的浏览器”， 然后再说：“我想要所有的或者那个特定的浏览器做这件事情，这是做这件事情的命令”——这实际上是2.0的基础。我想下一步，我们会得到一组JAVA API, 也是在JavaScript中的模拟API。目前也是最初的API是script.aculo.us ，它的功能和DWR DHTML使用库一样好。

它使你可以做一些事情，比如说这个简单的每个人都会用到的例子，聊天应用程序。当某个用户在聊天框中输入信息的时候，你可以说：“给我所有除了这个浏览器以外正在浏览这个网页的其他浏览器，将这个输入的信息加入到列单中。” 然后有一个JAVA API你可以使用来处理这个页面，同时它会自动将Java的基本类型数据转换成JavaScript类型，并且将它们传输到其他正在浏览这个页面的浏览器。所有的浏览器将单单由于一个Java命令而动态变换，这非常不错。我们不仅使用DWR Util网页处理库，而且也运用了script.aculo.us来处理。我觉得在今后的开发中，如果我们能够用相同的方式来处理其他的一些开发库，那就非常棒。我觉得我们会首先从TIBCO GI、Dojo和Yahoo!用户界面库（User Interface Library）开始。实现远程控制的过程会是非常有趣的。

基本上，有3个方法可以从服务器取得数据再发送到浏览器。明显地，关键问题总是在于是浏览器发送请求给服务器，而不是服务器来请求浏览器，在这点上有各种各样的理由来解释为什么我们不能完全将所有的任务推向浏览器。这3种基本方法有：Comet、polling和piggyback。 其中最简单的是polling, 你的浏览器向服务器阶段性地发送询问“你有没有什么信息要发送给我？”。对于负载较轻的应用程序，这样做没有什么问题，但是如果你在实现过程中不够仔细的话，就容易引发棘手的难题。这个算法很简单很漂亮并且几乎所有的浏览器都支持得很好。 另一个比较优化的算法是Comet, 实现这个算法，你必须一直保持浏览器和服务器间的连接，在浏览器询问“你有没有什么信息要发送给我”的时候，服务器不会发送任何东西直到它确实有数据要发送，但在这个等待的期间，两者间的连接一直是打开着的。

这个算法可以保证一旦服务器有数据要发送，它能够在几毫秒之内将数据推向浏览器。缺点在于，在负载比较重的应用程序中，你将遇到的问题是服务器端有很多线程同时运行着。所以我们集成了像Jetty这样的工具来断开一些连接，重复使用一些线程保证在服务器端一部分线程是运行的，而不再保证所有的线程在全部过程中都运行。随着时间的推进，我会进一步研究使这个方案在更多的服务器上工作，比如说Tomcat和WebLogic等等。这是其中两个算法。第三个方法是piggyback, 这个算法很简单。我们等待浏览器发送其它请求，我们在某种程度上将对于该请求的回答融合请求数据本身构成最后对浏览器的回复，DWR试图来管理和决定针对该请求最好的回复。你可以使用不同的方法来配置你觉得最好的回复信息的组合方式，但实际上你并没有必要去理解实现这个信息组合的方法是怎样的。你可以简单的从一种组合方式转换到另一种，而不需要去做另外的任何修改。

展望DWR的未来，这点非常棒。我觉得使反向AJAX很好的工作是我到目前为止遇到的最难的问题。它是多线程的，因为在上层，你可以同时接收到多个浏览器的请求，可以有两个连接来自同一个浏览器，甚至于来自同一个窗口，然后在底层，你可以同时得到许多不同的线程，再然后你还必须处理下层各种不同的服务器程序和上层各种浏览器的怪异行为。去达到一切正常运行的过程真的是个噩梦。其实我们已经向测试志愿者发送正式发布前的版本已经有一段时间了，基本上它也已经工作了很长一段时间，但还是不时的有这样那样奇怪的问题需要去探索解决。如果没有TIBCO的支持，我们可能根本达不到现在的状态，接近正式发布的状态。也正是由于TIBCO的支持，我才得以继续开发，但我们还在集成GI的工作中。目前我们完成了基本的集成工作，我们使用OpenAjax集线器将服务器事件发布到TIBCO GI。这是个非常好的方式来进行浏览器和服务器交互，你基本上可以有两个非连接的应用程序，他们之间没有大的互相的锁绑，他们只是发布事件而已，这对测试非常有益。我们有一个小小的程序完全致力于发布DWR的东西到GI，两者之间并不不知道彼此，他们都只在OpenAjax集线器的两端各占一端而已。

答案是：不是。毋庸置疑，我们将继续支持。尤其是TIBCO希望我继续支持Dojo,这是目标，他们也将帮助我去实现。很大程度上来说，他们并不是在和GI竞争，GI是关于提供庞大的局域网应用程序而不是一般的面向互联网的开发。你可以去实现它，但是它大部分是基于局域网，而Dojo面对的是不同的领域。一个非常好的例子，TIBCO发布了一些关于怎样使GI和Dojo一起工作的例子，这可以推翻你可能存有的觉得它们是完全对立的看法，其实我们都同属于OpenAjax联盟。我觉得存在的难题那么多，以至于我们都没有办法将它们全部解决，这个游戏这么大，我们所有的人都可以有自己足够大的空间。

我不知道其他的IDE，NetBeans已经很棒了。它最近刚做了更新，增加了对Struts的支持。对类似的事情我举双手支持，我认为Sun现在努力所做的这件事是非常棒的。

我觉得我能想到的最大的应用程序是不会在花哨的方式上感兴趣的。比如说，沃而玛有个非常大的网上商店，他们是个庞大的公司，沃而玛优点在于他们不会去重写他们的商品，而只是加上一点小功能，例如他们加上一个“更多信息”的按钮，然后使用一点DWR来得到关于你正在考虑是否购买的商品的更多信息。这是一个小范围内实现集成的例子。大的东西，不管后台是各种各样的结构，你都可以仅仅做一些小修改使得DWR运行，这点非常酷。再举个漂亮的例子，New York City创建了一个地图应用程序，有点像Google地图，但是运用的是DWR和服务器交互来改变数据的显示。

和Google 地图不同，很显然，它覆盖的范围小，但是它牵涉更多的数据，要覆盖更多的信息，比如地铁站，它比Google地图覆盖更多有关建筑物的信息。它有本身的局限性，不覆盖整个美国，所以不会是Google地图真正的竞争对手，但这是一个非常漂亮的运用了DWR的实例。我们正在做一些工作，我们认为将二进制数据从Java发布到JavaScript是应该有可能实现的，尽管我们尚未完成这个可能性的证明，但是如果实现的话，那我们将拥有一个很干净利落的方法在服务器端动态生成图像而在客户端显示它们。我还没有开始工作在这个方向上，但是在我说“哦，我不确定”的时候，已经有一些优秀的开发者跟我说“你知道，我们很确定”。这很酷，它将提供动态生成数据并发送到浏览器的很不错的功能。

是的。和DWR集成并没有很多新的东西，讲到后端（back end），我想Spring是最大的了。你一直都可以用DWR抛出Spring beans, 但是现在有一个Spring命名空间，所以如果你想要保留你的Spring配置文件，并且在Spring配置文件中申明“哦，顺便说，这个是为了使用DWR来抛出”的话，你可以摒弃所有的DWR配置文件，这个做法很干净。我们增加了很多集成，当前DWR默认地和RIFE捆绑。如果你想在RIFE中实现AJAX,你将运用DWR。我们做了很多的修改和优化，我们和Struts交互，和JSF交互，我们也有一些新的跟WebWork相关的东西，实际上，WebWork 2/Struts 2也捆绑有DWR，作为实现AJAX的方法，所以无论是在前端还是后端的交互都是很有趣的。