分析J2EE架构的6个最佳实践(二)

  　　第2课：安全并非是附加物

　　如第1课所述，我曾有幸研究过许多Web应用程序。我发现所有的JavaServer Page（JSP）都有一个共同的主题，那就是具有类似下面伪代码的布局：

　　HTML， JavaScript， and JSP

　　code to display data and

　　allow user interaction ——>

　　如果项目使用诸如Struts这样的MVC框架，所有的Action Bean都会具有类似的代码。尽管最后这些代码可能运行得很好，但如果您发现一个bug，或者您必须添加一个新的角色（例如，“guest”或者“admin”），这就会代表一场维护恶梦。

　 　此外，所有的开发人员，不管您多年轻，都需要熟悉这种编码模式。当然，您可以用一些JSP标签来整理JSP代码，可以创建一个清除派生 Action Bean的基本Action Bean.尽管如此，由于与安全相关的代码会分布到多个地方，所以维护时的恶梦仍旧存在。由于Web应用程序的安全是强迫建立在应用程序代码的级别上（由 多个开发人员），而不是建立在架构级别上，所以Web应用程序还是很可能存在弱点。

　　很可能，根本的问题是在项目接近完成时才处理安全 性问题。最近作为一名架构师，我曾在一年多的时间里亲历了某一要实现项目的6个版本，而直到第四版时我们才提到了安全性？？即使该项目会将高度敏感的个人 数据暴露于Web上，我们也没有注意到安全性。为了更改发布计划，我们卷入了与项目资助人及其管理人员的争斗中，以便在第一版中包含所有与安全相关的功 能，并将一些“业务”功能放在后续的版本中。最终，我们赢得了胜利。而且由于应用程序的安全性相当高，能够保护客户的私有数据，这一点我们引以为荣，我们 的客户也非常高兴。

　　遗憾的是，在大多数应用程序中，安全性看起来并未增加任何实际的商业价值，所以直到最后才解决。发生这种情况时， 人们才匆忙开发与安全相关的代码，而丝毫没有考虑解决方案的长期可维护性或者健壮性。忽视该安全性的另一个征兆是缺乏全面的服务器端验证，如我在第1课中 所述，这一点是安全Web应用程序的一个重要组成部分。

　　记住：J2EE Web应用程序的安全性并非仅仅是在Web.xml 和ejb-jar.xml文件中使用合适的声明，也不是使用J2EE技术，如Java 认证和授权服务（Java Authentication and Authorization Service，JAAS）。而是经过深思熟虑后的设计，且实现一个支持它的架构。

　　第3课：国际化（I18N）不再是纸上谈兵

　 　当今世界的事实是许多英语非母语的人们将访问您的公共Web应用程序。随着电子政务的实行，由于它允许人们（某个国家的居民）在线与政府机构交互，所以 这一点特别真实。这样的例子包括换发驾照或者车辆登记证。许多第一语言不是英语的人们很可能将访问这样的应用程序。国际化（即：“i18n”，因为在 “internationalization”这个单词中，字母i和字母n之间一共有18个字母）使得您的应用程序能够支持多种语言。

　 　显然，如果您的JSP 页面中有硬编码的文本，或者您的Java代码返回硬编码的错误消息，那么您要花费很多时间开发此Web应用程序的西班牙语版本。然而，在Web应用程序 中，为了支持多种语言，文本不是惟一必须“具体化”的部分。因为许多图像中嵌有文字，所以图形和图像也应该是可配置的。在极端的情况下，图像（或者颜色） 在不同的文化背景中可能有完全不同的意思。类似地，任何格式化数字和日期的Java代码也必须本地化。但问题是：您的页面布局可能也需要更改。

　　例如，如果您使用HTML表格来格式化和显示菜单选项、应用程序题头或注脚，则您可能必须为每一种支持的语言更改每一栏的最小宽度和表格其他可能的方面。为了适应不同的字体和颜色，您可能必须为每一种语言使用单独的样式表。

　 　显然，现在创建一个国际化的Web应用程序面临的是架构挑战而不是应用程序方面的挑战。一个架构良好的Web应用程序意味着您的JSP页面和所有与业务 相关的（应用程序特有的）Java代码都不知不觉地选择了本地化。要记住的教训是：不要因为Java、J2EE支持国际化而不考虑国际化。您必须从第一天 起就记住设计具有国际化的解决方案。