最重要的Java EE最佳实践 - 编程入门网
| 程序中使用不适当的 J2SE 方法（例如线程或 singleton），以及使用您自己的方法解决程序到程序（program-to-program）的 通信，而不是使用 Java EE 内在支持的机制（例如 JCA、JMS 或 Web 服务）。 当您将一个遵循 Java EE 的服务器移植到其他的服务器上，或者移植到相同服务 器的新版本上，上述的设计选择将会造成无数的问题。使用 Java EE 之外的元素 ，通常会导致一些细微的可移植性问题。唯一要背离规范的情况是，当一个问题 在规范的范围内无法解决的时候。例如，安排执行定时的业务逻辑在 EJB2.1 出 现之前是一个问题。在类似这样的情况下，我们建议当有厂商提供的解决方案时 就使用厂商提供的解决方案（例如 WebSphere Application Server Enterprise 中的 Scheduler 工具），而在没有厂商提供的解决方案时就使用第三方提供的工 具。当然，现在的 EJB 规范提供了基于时间的函数，所以我们鼓励使用这些标准 接口。如果使用厂商提供的解决方案，应用程序的维护以及将其移植到新的规范 版本将是厂商的问题，而不是您的问题。
最后，要注意不要太早地采用新技术。太过于热衷采用还没有集成到 Java EE 规范的其他部分或者还没有集成到厂商的产品中的技术常会带来灾难性的后果。 支持是关键的——如果您的厂商不直接支持某种特定的技术，那么您在采用此技 术时就应该非常谨慎。有些人（尤其是开发人员）过分关注于简化开发过程，忽 略了依赖大量本组织之外开发的代码的长期后果，而供应商并不支持这些代码。 我们发现，许多项目团队沉迷于新技术（例如最新的开放源代码框架），并很快 地依赖于它，却没有考虑它对业务带来的实际代价。坦白地说，对于使用您的供 应商所提供的产品之外的任何技术的决策，都应该由企业组织结构中的各个部门 、业务团队和法律团队（或您的环境中的等同机构）仔细地进行评审，这与正常 的产品购买决策完全相同。毕竟，我们中的大多数人是在解决业务问题，而不是 推进技术的发展。 5. 从一开始就计划使用 Java EE 安全性。 启用 WebSphere 安全性。这使您的 EJB 和 URL 至少可以让所有授权用户访 问。不要问为什么——照着做就是了。 在与我们合作的客户中，一开始就打算启用 WebSphere Java EE 安全性的顾 客是非常少的，这一点一直让我们感到吃惊。据我们估计大约只有 50% 的顾客一 开始就打算使用此特性。例如，我们曾与一些大型的金融机构（银行、代理等等 ）合作过，他们也没有打算启用安全性。幸运的是，这种问题在部署之前的检查 时就得以解决。 不使用 Java EE 安全性是件危险的事情。假设您的应用程序需要安全性（几 乎所有的应用程序都需要），敢打赌您的开发人员能够构建出自己的安全性基础 设施，其比您从 Java EE 厂商那里买来的更好。这可不是个好的赌博游戏。为分 布式的应用程序提供安全性是异常困难的。例如，您需要使用网络安全加密令牌 控制对 EJB 的访问。以我们的经验看来，大多数自己构建的安全性基础设施是不 安全的，并且有重大的缺陷，这使产品系统极其脆弱。（有关更详细的信息，请 参考 [Barcia] 的第 18 章。） 一些不使用 Java EE 安全性的理由包括：担心性能的下降，相信其他的安全 性（例如 IBM Tivoli® Access Manager 和 Netegrity SiteMinder）可以 取代 Java EE 安全性，或者是不知道 WebSphere Application Server 安全特性 及功能。不要陷入这些陷阱之中。尤其是，尽管像 Tivoli Access Manager 这样 的产品能够提供优秀的安全特性，但是仅仅其自身不可能保护整个 Java EE 应用 程序。这些产品必须与 Java EE 应用服务器联合起来才可能全面地保护您的系统 。 其他一种常见的不使用 Java EE 安全性的原因是，基于角色的模型没有提供 足 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
