精通J2EE应用程序开发之交叉分析J2EE

　　有一点可能比较令人吃惊的是，J2EE 软件套件并不能完全满足构建简单烟囱系统的开发人员的需要。当只需要一个表示层，且只有一个资源用于存储和检索数据时，J2EE 套件（尤其是 EJB）就显得“碍事”了。更诱人的方法是考虑轻型框架，因为它们并不那么专注于部署描述符，并且就 JNDI、JMS 之类而言也没什么不便的。它只是通过 web 浏览器进行的基本请求/响应通信，通常构建在类似 Struts 或相似的 MVC 样式 web 框架中，并与一组核心的传统 Java 对象（有时与单个机器上运行的表示层和业务逻辑层（而非数据库本身））进行通信。（您可能奇怪此处为什么没有使用术语“数据库”。原因很简单，虽然大多数项目使用数据库（而且还是关系数据库）存储数据，但数据存储通常是原有系统、商业软件程序包或形如 CICS 大型机、SAP 或 BizTalk 的“中介”技术。使用更一般的术语“资源”有助于强调这样一个看法：后端实现确实与本讨论无关。）

　　烟囱应用程序的另一个优势是它们通常是“独立的” — 也就是说不涉及其他应用程序。几乎不需要遵守任何已建立的安全、可靠性或管理标准，这是因为此应用程序所确立的所有内容都将成为标准（至少对此应用程序而言是这样，这正是此范围的关键所在）。开发人员经常利用此事实来构建正好适合于此应用程序的基础架构，从而消除了通常针对企业 Java 应用程序的指责：它们太复杂了，以至于无法使用和维护。

　　尽管人们希望如此，但 J2EE 的设计并非是针对烟囱应用程序的 — 当然，一个基于 J2EE 的应用程序可以构建此类应用程序（并且有上千个示例可以作为此事实的证据），事实上有点像用牛刀杀鸡。基于 J2EE 的应用程序实施了一定程度的层划分，但有时这种划分对于解决手头的问题显得有些矫枉过正，如传统的“10 用户”烟囱系统。当然，问题是 10 用户烟囱系统通常有一种另人不悦的趋势，即转变为其他四个版本中的某个版本，这样将使事情变得很糟。就像某位哲学家说的那样“没有哪个人是孤立的”，我们也可以很轻松和准确地说“没有哪个系统是孤立的”。至少在短期内是这样。（当然，如果系统无法完成其预期的目标，那它就无法与任何其他系统集成，并且可能停产，但我们将假设那不是预期的目标。）