最后，派生出一个像 Shale 这样的新项目，同时继续在 Struts 这种已有的项目上进行开发活动，这样做具有无与伦比的优势。如果 Struts 只是简单地升级到 2.0（或者 3.0 或 4.0），并在不考虑向后兼容性的情况下实现 Shale，那么对于很多人来说，由此造成的移植工作将是令人痛苦的，可能有人干脆连 Struts 也不再使用了。即使仍然维护更旧的代码基，也难于吸引开发人员花时间来修复 bug，他们也不愿意为一个 “遭到废弃” 的或者 “旧” 版本的软件增加特性。
由于这些原因，让 Shale 成为一个全新的项目，使其建立在一个新的代码基之上，是很有意义的。
Shale 的面向服务架构
Shale 之所以没有成为 Struts 的一个新的发行版，其最后一个原因与逻辑没有关系：而是与该框架将新方法接纳到 Web 开发中的能力有关系。Shale 在很多方面与 Struts 存在不同之处，其中有两点最为突出：
Struts 实质上是一个巨大的、复杂的请求处理器；而 Shale 则是一组可以以任何方式进行组合的服务。
Shale 对 JSF 的依赖性具有深远的、令人惊讶的意义，而且大部分情况下是积极的意义。随着这个系列的深入，我将深入研究这些意义。在讨论其他方面之前，有必要对造成 Shale 与 Struts 之间差异的第二个方面进行详细的讨论。
如果您多次使用过 Struts，那么会意识到它很大程度上可以看作一个请求处理器，通过它可以接受请求，并指示框架如何处理请求。您可以指出采取哪种动作，使用什么模型，将哪种视图显示给用户，采用什么验证规则，显示哪种表单 ... Struts 是完全可以配置的。然而，所有这些的核心是一个请求处理器，为每个请求提供服务。这样的处理器是 Struts 中最重要、也是最复杂的部分，因为对于在处理一个请求的过程中涉及的所有工作，它都必须进行处理或托管，在 Struts 代码基中几乎没有哪一部分与这个请求处理器没有关系或不受它的影响。
因此，Struts 基本上难于作出改变。如果想修改处理请求的方式，或改变处理请求过程中各部分的顺序，那么将面临巨大的困难。实际上，不得不重新编写 Struts 代码基。更改请求处理器的行为倒是稍微可行，但是大部分是不容变动的。这是 Shale 试图解决的关键问题之一（如果您需要 Web 框架有那种程度的灵活性的话）。
Shale 没有像 Struts 请求处理器那样的中心组件，它只是一组数量很多的服务。可以自由组合这些服务，每个服务与其他服务之间是松散耦合的。通