原文来自 http://www.onjava.com/pub/a/onjava/2003/06/11/j2ee_deployment.html?page=1
接第二篇:
2.2.1 R资源绑定(其他类型的静态资源)
resource Bundles (and Other Types of Static Resources)
让我们稍微考虑一下,在一些web application需要一些包含一些信息的以.properties为后缀的文件(作为资源绑定),根据类加载器的关系和孤立的级别,通常有3种方式来放置这些资源文件
1.把资源绑定的拷贝放入每个WAR文件的WEB-INF/classes 目录下,这样做也有缺点,那就是如果某人后期决定他需要去修改这些文件的信息,他必须要进入每个WAR文件并且每一个都作出相同的修改,这是容易导致错误的,至少是这么说的.
2.把资源绑定都放入一个能被系统的calsspath能够识别出来的目录下,这样解决了第一点中的缺点即不需要修改相同文件夹下的多个的拷贝.然而这样做同样能够限制你的再次部署application(re-deploy)的功能.因为被系统classloader加载的资源只能通过重新启动JVM来再次加载(reload).在这种情况下你做的一些改变将不会实现在你重启动application server之前,在J2EE解决方案中高的实用型可用性是比较重要的,这样会导致更加复杂的系统维护.
2.2.2 Third-Party Libraries
:通常在J2EE工程中包含完全免费第三方的软件是不常见的(比如Apache log4j).在这种情况下,一般是最好把那些库的JAR文件放入到制定地址的一个EAR文件里,如果库不合已存在的被application server正在使用的库冲突或者是改变或升级那些库的需求很小时,那么库路径必须放入到CLASSPATH里是最好的.如果你决定把通用的库放入到EAR模块的内部,这是必须要确保第三方库必须在制定的地点被加载(eg/lib or /ext)这将会使查找并且处理故障更加的方便,通过鉴别那些内部组件依赖的模块.因为在不同的classloader之间有严格的限制,你必须把第三方库的路径放入MEANIFEST文件或者使J2EE模块.包括WAR文件和EJB文件
2.3其他一些的建议
J2EE可以通过很简单的开发方式来开发可升级性能高的和可靠性高的工程,所以,一个J2EE的开发构架必须要在仔细考虑好升级性能和可靠性的需求之后才能作出决定.
2.3.1 Scalability 可升级性
在我们第二篇文章中,把application分解成在不通层(tiers)的多个单元(units)将给我们提供更高的可升级性高和可靠性高的模块.然而,必须要仔细考虑到要在确保颗粒度和模块性与灵活性和性能表现之间的平衡关系.
2.3.2 Maintainability and Hot Deployment
热部署(Hot Deployment)和可维护性
热部署指的是不需要停止或者重启动application来进行部署和重新部署.如果你的application需要热部署,那么必须要确保application的资源,依靠第三方库,或者以自身形式打包的其他enterprise模块.避免建立任何依赖与系统classpath的模块,确保每一个enterprise application模块可能需要到的东西打包到同一个EAR文件中
2.3.3 Security安全性
.取决于application的安全性,不同的安全机制如(SSL,VPN,J2EE module declarative security model)可以在不同的层之间执行,从而来提供我们需要的安全级别.尽管J2EE规格说到安全需求是由appliacation server提供的.但是没有指定提供一种什么样的安全性,所以,安全需求可以是可以是由厂商来说明觉定的.入伙你的application 需要在不同的安全管理域通过安全身份来鉴别,(比如分布式安全),那么你就需要毫无疑问的和你的提供厂商来协商.在某些情况下可能会有限制,那么你就需要限制你在部署构架中的选择
2.3.4 Deployment Automation自动部署
在理想的情况下,你遇到的所有系统的管理员都是非常熟悉J2EE和application server的.然而,或许找出尽管有一个精通UNIX或者是Winodws系统管理员,他或她根本就不知道什么是J2EE.所以,为了那些可能部署和管理这个j2ee系统的人而着想,有一个清晰的部署步骤文档是最好的了.那将会是比提供那些如何自动部署的文档更加的方便.许多application server厂商如今都提供无论是精通厂商规范的人员还是一般人员的管理控制台,或者通过Java 管理扩展,(JMX)API(例如 BEA weblogic Management API)然而,基于不同厂商的不同的部署机制,你需要创建相应的平台来适应.
Future Direction未来方向
越来越多的J2EE application的应用程序的发布，确定在通用的标准的部署和打包一个J2EE应用程序的地方变得越来越重要了。然而，怎么样部署一个J2ee应用程序仍然没有标准可以遵循.
JSR的目的就是确定一个标准的API ，从而才能使任何的部署工具来部署任何的J2EE application server J2EE模块.特别时要考虑以下一些标准。
1.安装：部署一个pre-package的组件到container中的能力
2.配置：使用标准配置的机制重新得到配置的数据的能力
3.卸载部署:从一个容器中卸载一个部署的能力
从这个角度看,JSR将会包含到J2EE1.4的规范中,伴随着新的API,一个application 厂商可以创建部署工具或者脚本,从而可以不用担心不同的部署作用而来自动的部署他自己的application到不同的application server.但是还是有一些部分的区域没有被JSR考虑到.
4.J2EE资源部署和配置:部署和配置J2EE的资源,例如DB连接迟,DB,JMS等,这些还是得要依赖于厂商的
5.安全配置:J2EE模块通过允许安全角色规范和在部署中的描述符来支持一个清晰的安全模块.
然而如果安全信息在部署时改变,系统管理员还是要依赖于厂商所提供的机制来作出改变
模块的独立性:尽管新的标准通过部署描述符允许模块的独立性的规范,独立性并没有被追踪,这样卸载部署时,模块所需要的资源不会自动的撤销.
四:总结:部署还是一个许多J2EE开发人员不是很熟悉的部分,如果部署细节不在设计构架时考虑到,你将会很容使你改变你的构架,综上所述,通常有许多在一开始就要考虑到的地方来满足你的application的表现性,可靠性等的需求.
