说说Java for Google App Engine (2) － 关于前端的设计

Google App Engine前端和大部分的Java Web Server的设计相当。通过配制web.xml设置URL规则，比如<ervlet>, <servlet-mapping>和<welcome-file-list>。对了，还有<filter>和<filter-mapping>。

为了简单处理常用的JSP动态页面脚本，与普通的web.xml不一样，直接用<jsp-file>替代<servlet>中的<class-name>。但是这个处理方式有点别扭。主要是因为在普通的Java Web Server中，只需要配制好url-pattern，所有符合规则的JSP都会使用JSP解释器操作。而GAE的配制则不行，它需要对每个JSP都做一下配制……这会让开发变得明显的不容易，至少这个事情会变得很麻烦。

另外一个重要的设计是，是对于配制文件的。坦率的说，我很喜欢在配制文件appengine-web.xml可以把所有相应的配制信息都管理起来。但是在GAE的设计中，反而限制得更多了。相比之下，spring对配制文件的理解则要可爱得多。GAE限制了直接读取本地文件的java.io的类，但是又没有通过配制文件给出一个可以获得配制文件内容的方法。毕竟不光是logging，其他大量的框架和应用jar包，都有自己特有的properties和xml文件，需要读取。

如果能够像spring读取配制文件一样，提供一个：”classpath:myproperties.xml”，这样的配制方式，就可以指定所有的配制文件只会从WEB-INF/classes目录下读取，或者也可以从其他的指定目录的子目录中读取了。如果可以解决这个问题，那么就可以比较容易地解决许多第三方框架对配制文件地需求，重新把读取部分重新加载一下，类似于struts for GAE的架构就比较容易实现了。

但是现在Java for GAE的前端设计，给项目开发的余量很小。尤其是针对业务逻辑的开发模式，Module部分的支持不够强。同样，虽然JSP还是一个最广泛使用的动态页面模式，但是也是因为配制文件的问题，导致利用其他可以模板进行开发的难度就比较大了……

所以综上所述，GAE的架构更接近于开发一个Service而不是一个Application。至少它的Java体系太独立，与其他第三方的开发包不能很好的相匹配。作为一个开发语言，Java最大的长处是在于可以利用大量的第三方Package，才使得它的开发速度能够变得更快，但是GAE的设计，则没有考虑到这方面的因素，导致大家像写C语言一样，在只有一些基础类的前提下，来逐步开发应用。这个事情让人就很头疼了。所以也难怪，GAE在推出这段事件内，并没有引起大家使用的热潮，还是处于半试验的阶段。

但是，从另外一个角度。我们可以看到，一个从架构、自动分发角度触发的Java Web Server是怎么看待开发环境的。也从中学到了很多思路，比如说：通过配制文件来实现crontab，可能是一个很好的分布式算法的基础，而GAE禁止了Thread的相关操作，也说明，为了保证服务器的性能可以评估和监控。所以把任何可能长时间执行的Thread变成一个定期执行的脚本，这一点上，更接近分布式系统的思路——过度一类一个线程，只有开始没有结束地让它运行，并不是一个让Google喜欢的运行模式。

看完Google App Engine的说明之后，我比较赞同它后端的设计理念，虽然有些类似于count的瑕疵。而对于前端的灵活性方面，GAE做得明显不够。想做成一个真正好用的分布式平台，GAE还有很长的路要走啊。

PS: 今天又重新翻了一遍GAE的说明，发现在部署(Deploy)部分，对数据存储的索引有一个单独的步骤，就像处理定期事件一样。所以索引的建立，是通过命令行触发的，GAE引擎通过上传的配制文件，确定索引表的建立方式。