你好，Shale！了解Struts框架的全新后代(1)

Shale不是什么？Shale不是打包好的、有编制好的文档并经过严格测试的产品，也没有附带自动安装程序和优雅的管理界面。那么Shale到底是什么呢？Brett McLaughlin在本文中将揭开这个Struts后代的面纱。本文是一个由五部分组成的系列中的第一篇文章，在本文中，Brett解释了Shale是什么，Shale与Struts框架的不同之处，以及如何在开发环境中安装和设置它。

在过去5年间出现的所有Web框架中，Jakarta Struts是Java™开发人员使用得最多的一种框架，因此其后代的问世是一件值得注意的事情。虽然Shale还不是最流行的框架，也不是最为人熟悉的框架，但是出自名门的背景仍给人以深刻印象。更令人兴奋的是，Shale并不仅仅是Struts的重大升级和新的发行版：它彻底更新了Struts中的很多核心原则，并且加入了Web开发中最新的思想。

在这个由五部分组成的系列中，您将了解到，Shale与Struts的背离是一柄双刃剑。一方面，Shale是经过精心设计的Struts的后代。Shale的创立者综合考虑了Struts的优点和不足，提出可与其前辈媲美的下一代框架。另一方面，正如您很快就可以在这个系列中看到的一样，Shale是一种完全不同于Struts的框架，其中隐含着很多新的开发工作！

Shale不仅仅是Struts的又一个修正版，它已扩展到超出Struts所能达到的高度。它包含Java Web程序设计中一些最重要的、最近的开发成果，包括JSP Standard Tag Library（JSTL）和JavaServer Faces（JSF），并建立在这些开发成果之上。Shale完全应该被看作是与Struts不同的一种框架，在这个系列中，我将还Shale框架以本来面目。在这个月的文章中，将首先对Shale与Struts之间的区别作一个概述，然后带您体验安装Shale并测试安装情况的步骤。最后，我将给出一些思想，令您能进一步参与到Shale项目（它是开放源码的）中，并提供一些相关的信息。整个系列的目的就是要向您展示如何安装Shale以及如何使用Shale构建和开发项目，同时很少涉及Shale的前辈，即Struts框架。

评价Shale

任何新的Web开发框架要想在这个竞争已经很激烈的领域占得一席之地，最好能够经受住巨大压力下的评测。好消息是，Shale独力经受住了细致的考察。但是，坏消息是，由于Shale完全是对Struts重新构建的产物，因此必须重新编写和重新测试您所有基于Struts的代码，以便实现这些代码。您将花同样多的精力来编写一个新的Shale应用程序，或将一个Struts应用程序转换成Shale应用程序，就好像Shale与Struts完全无关一样。

所以接下来我们忍不住要问，为什么还要采用Shale呢？为了得出答案，我首先解释一下Shale的伟大之处——这在很大程度上是由于它的Struts血统，但这又不是惟一的原因——然后讨论Shale之所以没有被发布为Struts框架的重要修正版的两大原因。这样，您就会更好地理解从Shale身上可以得到什么，这将有助于评价使用这种下一代的框架是否值得。

Struts血统

Shale重用了大量的Struts代码基，并声称Struts是它的“父”框架，因此如果您要相信Shale的价值，就得相信Struts的价值。首先，Struts作为第一个真正意义上的Web开发框架，拥有巨大的价值。据Shale和Struts网站报道，第一批代码是在2000年6月提交给Struts CVS存储库的，而Struts 1.0是在2001年末才发布的。当很多开发人员正在艰难地使用Java Server Pages（JSP）和不断变化的servlet规范时，Struts提供了一种易于使用的Model 2方法来构建基于servlet和JSP的Web应用程序。换句话说，Struts使Web开发人员可以开发健壮的Web应用程序，而不必精于日志记录、分布式计算、JDBC、Servlet、JSP、JNDI、RMI和大量其他的API和技术。

接下来，Struts要做的事情就是保持它的强大性：从写出第一批代码开始，Struts连续6年一直是最流行的Web开发框架之一。至今它仍然是人们口中的谈资，笔下的素材，使用得不比任何竞争对手少。由于Struts是如此流行，如此长寿，如今它已经有丰富的功能，有良好的文档，被广泛地支持，并且易于使用，在它上面进行开发和管理也很容易。数千名开发人员对Struts邮件列表上的问题作出答复，数万名开发人员试用Struts并报告问题，这使得这些问题很容易得到修复。

最后，Struts是不断发展的。很多框架一开始比较强大，然后就停滞不前（商业产品和开放源码项目都存在这样的现象），而Struts总是不断提供新的特性。当您下载Struts时，核心发行版中还包含一个健壮的确认引擎（validation engine），并且Struts已经与JavaServer Faces集成，拥有广泛的标记库和一个不断发展的Model 2架构，其中引入了在分布式n-层应用程序领域中最新的思想。而且告诉您，Struts还紧跟程序设计中出现的新模式，例如IoC（Inversion of Control）。Struts与WebWork和Spring框架自然地集成，后两者都是具有最佳血统的、为使用Web开发中的新方法提供入口的框架。

简而言之，您很难发现在Struts中有做不成或不支持的事。所以显然我们就要问，为什么Shale要另起炉灶呢？为什么Shale没有成为Struts的下一个版本呢？这有两个主要原因：一个原因与鲜为人知的新软件发行惯例有关，另一个原因则与众所周知的Struts根基中的弱点有关。让我们分别来考虑这两个原因。

发行版辨析

要理解Shale为什么没有成为Struts的一个新的发行版，首先需要理解关于新软件发行的一两件事。对于一个新的软件发行版，大多数用户首先看的是一组新的特性。版本升级的幅度越大，用户对新特性的期待就越大。因此，如果软件版本从2.1升级到2.2，就应该有一些新的特性，但是如果从版本2.2升级到版本3.0，那么就应该有很多新特性。这就是为什么当一些大型产品（例如Microsoft Word）或操作系统（例如Windows和Mac OS X）出了新版本的时候，用户总是对它们很挑剔。对于每一个新的发行版，用户总是期待有更多新的特性。

由于大多数用户一味地将注意力放在特性上，他们没有意识到向后兼容性（backward compatibility）才是真正最有价值的东西。虽然每个人都希望Excel中加入新的、很好的选项，希望Panther与iTunes有更好的集成，希望Gnome中对XUL有更好的支持，但是如果那些用户现有的程序和文件在新版本下突然不能运行的话，相信他们会尖叫，“这是血腥谋杀”。在这种情况下，新特性毫无价值。

对于Struts也一样。一般来说，Struts的每个新版本都增加了新的特性，同时保持了与之前版本的向后兼容性。此外，新版本的Struts还需要支持旧版本的Java平台和Servlet规范，因为已安装的旧的Struts要在这些平台上运行。这两个需求——向后兼容性和对旧版本的Java API的支持——对于Shale来说已经是一个严重的约束。尤其是，至少就Java平台而言，JSF API已经成为Web的中心组件。虽然Struts也支持JSF，但是Shale却是完全依赖于JSF的——这对于需要维持向后兼容性的Struts来说简直是不可能的。

最后，派生出一个像Shale这样的新项目，同时继续在Struts这种已有的项目上进行开发活动，这样做具有无与伦比的优势。如果Struts只是简单地升级到2.0（或者3.0或4.0），并在不考虑向后兼容性的情况下实现Shale，那么对于很多人来说，由此造成的移植工作将是令人痛苦的，可能有人干脆连Struts也不再使用了。即使仍然维护更旧的代码基，也难于吸引开发人员花时间来修复bug，他们也不愿意为一个“遭到废弃”的或者“旧”版本的软件增加特性。

由于这些原因，让Shale成为一个全新的项目，使其建立在一个新的代码基之上，是很有意义的。