<script type="text/javascript">
</script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
J2EE部署技巧
如今你和一些资历较高的J2EE开发人员交流的话，他们大部分都很乐意给你提供一些不同类型的EJB的细节问题，或者是怎么样来使用JMS来发送和接受异 步的消息。然而很难找到某个人能够描述一个能够确保可测试性，可靠性,和性能很好的系统构架部署。许多J2EE程序员缺少深入的理解部署。其中一个原因是 J2EE specification中包含的应用程序的部署本来就甚少。把这个难题留给个人去考虑。所以这导致了许多困惑，比如每一个设计人员都有可能自己部署 j2ee应用程序的方法。在此篇文章中，我们首先要介绍的是描述不同的J2EE模块和不同的打包结构。随后我们将来一起探讨一些可行的部署结构和一些在设 计和执行J2EE应用程序中的部署技巧。再此之前，你最好要了解一些J2EE核心技术，例如JSP，servlet，EJB，XML。
J2EE Modules：
J2EE1.3支持把J2EE application打包成不同的可部署的模块.以下是2种J2EE modules
 Application modules(enterprise application or web application)
 Standalone modules(EJB or resource adapter)
基 本上，一个WAR文件(Web Application Archive)是用来部署一个基于web的application。WAR文件中可以包含 servlets,HTML文件，JSPs及一切与其有关系的图或资源文件。另一方面,一个EAR文件（Enterprise Application Archice)是一个容器可以包含EJBs 资源适配器(resuorce adapters)，和一个或多个web application模块.当在打包enterprise application的时候部分需要考虑的是这个application需要用多少个EAR文件.是否要包含我的所有的EJBs到EAR文件中?这些决 定将会直接影响到程序的运行稳定性，可维护性，和程序的执行。我们一会就来探讨这些， 类加载器的关系（class Loader RelationShip) 经常在设计J2EE application时我们会忽略不同的模块类型间类加载之间的关系。Java虚拟机（JVM）用类加载器classloader来查找类和对象并把他 们载入内存。在默认的情况下，系统的类加载器会根据在系统中的环境变量的classpath的位置来加载类，当然也可以为自己的application提 供别的加载的地方而不是默认的。
图1 类加器的
图中应用程序端的server用SystemClassLoader加载,并且只能 从通过系统的classpath才能看到资源。每一个EAR和RAR和WAR模块中中都有分离的单独的classloader。Classloaders 加载器们的关系没有被很明确的确定，但是一般情况下在4种不同的类加载器中有一种关系就是父与子的关系，就像子类和父类的关系，子类的 classloader可以在在父类的classloader中定位class，但反之不行。在J2EE中systemloader就是所有的EAR classloader的父类classloader。然而EAR classloader是WAR和RAR的父类classloader。
图2
根据java规范，一个子类类加载器(classloader)在试图定位自己的了类之前必须先用其父类classloader定位这个类。这虽然听起来感 觉没什么必要，但是这样是可以阻止当有多个类加载在同一个JVM里的多个类加载器（classloader）之间的含糊不清和之间的冲突。有个别的应用程 序服务器允许你自己来选择性的查找EAR和WAR类加载器的加载行为。但是不推荐这样做，因为这样可能造成其他的麻烦，例如 classcastException会在一下情况下发生：当在两个相同version的类但是在不同的类加载器中。
部署结构 (Deployment Architecture)
一个典型的3层enterprise application由3个主要的层组成:
表达层：这个层的任务是负责处理与用户的交互。
商业逻辑层：这个层通常是扮演server的角色，负责响应来自用户的表达层的请求。
数据层：这个层包含数据库和其他连接数据库的组件。
一 个大的商业系统的解决方案中，每一个层将被单独的部署在自己的域内，这样可以允许每个域来满足自己的商业需求。除此之外，负载平衡器将会在表达层之前被部 署用来提高可靠性和支持更好的fail-over，商业逻辑层和数据层倾向与依赖聚合技术来预防fail-over，下图解释了典型的部署结构。
图3
根据现实的商业用例，上图也有一些变化。
对 于一个J2EE application，表达层通常通过使用servlet和JSP来解决实现，而这些servlet和JSPs可以打包成一个或多个WAR文件。商业层 通常通过session beans来实现，而这些beans可以被打包为一个或多个EAR文件。数据层通常通过实体beans（entity beans）(通常用来和数据库的资源连接）或者是资源适配器（控制与lagacy和非JBDC资源的连接，同样的当然可以被打包为一个或多个EAR文 件）。下图给我们展示了在J2EE资源和模型中相同的部署结构。
如果按照上面的模型来部署一个J2EE application将会有很好的灵活性，但是这里还有一些别的需要在部署结构形成之前考虑到。通常认为remote calls比local calls需要花费更多的时间，在远程过程呼叫中，本地代理对象必须copy所有的参数并且把他们通过电缆传送过来，通过RMI，在远程控制对象时，会造 成网络交通堵塞和长时间的响应等待。考虑到用户在web page上发出一个命令的细节，而这特殊的请求轮流的调用servlet，随后就是处理在session beans和entity beans中的business method。至少4个网络操作都有同时的运行，其中的2个操作都是remote EJB calls。
当session beans call别的 session beans或者多个entity beans时，就需要创建额外的remote calls。如果执行的效果是首先要考虑到的，就需要在构架和设计时作出调整。来减少remote calss 的数量，而且要减少remote calls产生的消耗。
这里我们有许多方法来解决perforamce的问题:
我们可以通过使用EJB的coarse-grained设计模式来减少网络上的trips。
我们可以通过使用本地而不是远程接口或者是实体beans来消除一些不必要的远程呼叫。
我们可以通过改变打包结构来使更多的beans部署在一个EAR文件里从而使一些远程呼叫变成本地呼叫
本地接口 VS 远程接口
J2EE1.3 中引入本地enterprise beans的概念，它可以允许一个entity beans显示本地接口，这样可以允许以引用reference来传递参数而不是传值value。然而为了使session beans能够访问本地enterprise beans必须将本地enterprise beans打包到和session bean一样相同的EAR文件里。通常有两种方法来实现。
a.在数据层中可以在entiy beans之前创建一个session Facade，这样可以同样可以使entity beans在内部application中起到同样的作用，然而，如果仅仅依赖这种session Facade技术的话，程序运行的效果可能并不是很好。
b.把entity beans放到business层中，并且允许business层的session beans可以直接连接本地enterprise beans。这样可以减少entity beans重复使用的程度。本地的entity beans只能在位于相同的EAR文件里起作用，在application外部的模块中的其他的business beans就无法来与entity beans连接。这将使在不同applicatipn 模块中的相同entity beans的实例（instances）加倍。
打包结构
一 些J2EE application server例如BEA的weblogic会优化beasns之间的远程呼叫和本地呼叫.如果beans都在相同的EAR中,这很有利于一个 session beans呼叫多个session beans或者entity beans.但是这样也有一些不利之处:
降低可维护性:所有的打包在同一个EAR的beans必须在同一时间被部署或者是重新部署,这样会阻止在运行时间改变beans的可能性.
平台依赖性: 不是所有的app server都提供这种方式的优化,而且如果你转变app server vendors的话是没有任何作用的.
可能破坏到设计思路: 许多开发人员设计beans都假设所有的参数通过传值而不是传递引用.如果改变呼叫的约定将会破坏以前的假设,特别是如果传递对象的模式被同时用在entity beans中资源定位的考虑另一个区域我们必须考虑通用资源和库的位置,一条戒律是资源一定要随着用到的J2EE模块在一起.然而,如果在某种情况下比如一些同用资源被几个模块同时用 到时,你可以把他放到一个这些模块都可以获取到这些资源的地方.除此之外,把资源路径放入你的系统的CLASSPATH里将会引起与其他J2EE模块部署 到相同的容器的冲突.这样会同样的限制你来部署J2EE应用程序 资源绑定(其他类型的静态资源)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解决方案中高的实用型可用性是比较重要的,这样会导致更加复杂的系统维护.
Third-Party Libraries:
通 常在J2EE工程中包含完全免费第三方的软件是不常见的(比如Apache log4j).在这种情况下,一般是最好把那些库的JAR文件放入到制定地址的一个EAR文件里,如果库与现已存在的被application server正在使用的库冲突或者是改变或升级那些库的需求很小时,那么库路径必须放入到CLASSPATH里是最好的.如果你决定把通用的库放入到 EAR模块的内部,这是必须要确保第三方库必须在制定的地点被加载(eg/lib or /ext)这将会使查找并且处理故障更加的方便,通过鉴别那些内部组件依赖的模块.因为在不同的classloader之间有严格的限制,你必须把第三方 库的路径放入MEANIFEST文件或者使J2EE模块.包括WAR文件和EJB文件.
其他一些的建议
J2EE可以通过很简单的开发方式来开发可升级性能高的和可靠性高的工程,所以,一个J2EE的开发构架必须要在仔细考虑好升级性能和可靠性的需求之后才能作出决定.
可升级性(Scalability)
在前面,我们把application分解成在不通层(tiers)的多个单元(units)将给我们提供更高的可升级性高和可靠性高的模块.然而,必须要仔细考虑到要在确保颗粒度和模块性与灵活性和性能表现之间的平衡关系.
热部署和可维护性(Maintainability and Hot Deployment)
热 部署指的是不需要停止或者重启动application来进行部署和重新部署.如果你的application需要热部署,那么必须要确保 application的资源,依靠第三方库,或者以自身形式打包的其他enterprise模块.避免建立任何依赖与系统classpath的模块,确 保每一个enterprise application模块可能需要到的东西打包到同一个EAR文件中
安全性(Security)
取 决于application的安全性,不同的安全机制如(SSL,VPN,J2EE module declarative security model)可以在不同的层之间执行,从而来提供我们需要的安全级别.尽管J2EE规格说到安全需求是由appliacation server提供的.但是没有指定提供一种什么样的安全性,所以,安全需求可以是可以是由厂商来说明觉定的.入伙你的application 需要在不同的安全管理域通过安全身份来鉴别,(比如分布式安全),那么你就需要毫无疑问的和你的提供厂商来协商.在某些情况下可能会有限制,那么你就需要 限制你在部署构架中的选择
自动部署(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连接池,JMS等,这还是得要依赖于厂商的。
5. 安全配置:J2EE模块通过允许安全角色规范和在部署中的描述符来支持一个清晰的安全模块.然而如果安全信息在部署时改变,系统管理员还是要依赖于厂商所 提供的机制来作出改变模块的独立性:尽管新的标准通过部署描述符允许模块的独立性的规范,独立性并没有被追踪,这样卸载部署时,模块所需要的资源不会自动 的撤销.
总结: 部署还是一个许多J2EE开发人员不是很熟悉的部分,如果部署细节不在设计构架时考虑到,你将会很容使你改变你的构架,综上所述,通常有许多在一开始就要考虑到的地方来满足你的application的表现性,可靠性等的需求。
<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
如今你和一些资历较高的J2EE开发人员交流的话，他们大部分都很乐意给你提供一些不同类型的EJB的细节问题，或者是怎么样来使用JMS来发送和接受异 步的消息。然而很难找到某个人能够描述一个能够确保可测试性，可靠性,和性能很好的系统构架部署。许多J2EE程序员缺少深入的理解部署。其中一个原因是 J2EE specification中包含的应用程序的部署本来就甚少。把这个难题留给个人去考虑。所以这导致了许多困惑，比如每一个设计人员都有可能自己部署 j2ee应用程序的方法。在此篇文章中，我们首先要介绍的是描述不同的J2EE模块和不同的打包结构。随后我们将来一起探讨一些可行的部署结构和一些在设 计和执行J2EE应用程序中的部署技巧。再此之前，你最好要了解一些J2EE核心技术，例如JSP，servlet，EJB，XML。
J2EE Modules：
J2EE1.3支持把J2EE application打包成不同的可部署的模块.以下是2种J2EE modules
 Application modules(enterprise application or web application)
 Standalone modules(EJB or resource adapter)
基 本上，一个WAR文件(Web Application Archive)是用来部署一个基于web的application。WAR文件中可以包含 servlets,HTML文件，JSPs及一切与其有关系的图或资源文件。另一方面,一个EAR文件（Enterprise Application Archice)是一个容器可以包含EJBs 资源适配器(resuorce adapters)，和一个或多个web application模块.当在打包enterprise application的时候部分需要考虑的是这个application需要用多少个EAR文件.是否要包含我的所有的EJBs到EAR文件中?这些决 定将会直接影响到程序的运行稳定性，可维护性，和程序的执行。我们一会就来探讨这些， 类加载器的关系（class Loader RelationShip) 经常在设计J2EE application时我们会忽略不同的模块类型间类加载之间的关系。Java虚拟机（JVM）用类加载器classloader来查找类和对象并把他 们载入内存。在默认的情况下，系统的类加载器会根据在系统中的环境变量的classpath的位置来加载类，当然也可以为自己的application提 供别的加载的地方而不是默认的。
图1 类加器的
图中应用程序端的server用SystemClassLoader加载,并且只能 从通过系统的classpath才能看到资源。每一个EAR和RAR和WAR模块中中都有分离的单独的classloader。Classloaders 加载器们的关系没有被很明确的确定，但是一般情况下在4种不同的类加载器中有一种关系就是父与子的关系，就像子类和父类的关系，子类的 classloader可以在在父类的classloader中定位class，但反之不行。在J2EE中systemloader就是所有的EAR classloader的父类classloader。然而EAR classloader是WAR和RAR的父类classloader。
图2
根据java规范，一个子类类加载器(classloader)在试图定位自己的了类之前必须先用其父类classloader定位这个类。这虽然听起来感 觉没什么必要，但是这样是可以阻止当有多个类加载在同一个JVM里的多个类加载器（classloader）之间的含糊不清和之间的冲突。有个别的应用程 序服务器允许你自己来选择性的查找EAR和WAR类加载器的加载行为。但是不推荐这样做，因为这样可能造成其他的麻烦，例如 classcastException会在一下情况下发生：当在两个相同version的类但是在不同的类加载器中。
部署结构 (Deployment Architecture)
一个典型的3层enterprise application由3个主要的层组成:
表达层：这个层的任务是负责处理与用户的交互。
商业逻辑层：这个层通常是扮演server的角色，负责响应来自用户的表达层的请求。
数据层：这个层包含数据库和其他连接数据库的组件。
一 个大的商业系统的解决方案中，每一个层将被单独的部署在自己的域内，这样可以允许每个域来满足自己的商业需求。除此之外，负载平衡器将会在表达层之前被部 署用来提高可靠性和支持更好的fail-over，商业逻辑层和数据层倾向与依赖聚合技术来预防fail-over，下图解释了典型的部署结构。
图3
根据现实的商业用例，上图也有一些变化。
对 于一个J2EE application，表达层通常通过使用servlet和JSP来解决实现，而这些servlet和JSPs可以打包成一个或多个WAR文件。商业层 通常通过session beans来实现，而这些beans可以被打包为一个或多个EAR文件。数据层通常通过实体beans（entity beans）(通常用来和数据库的资源连接）或者是资源适配器（控制与lagacy和非JBDC资源的连接，同样的当然可以被打包为一个或多个EAR文 件）。下图给我们展示了在J2EE资源和模型中相同的部署结构。
如果按照上面的模型来部署一个J2EE application将会有很好的灵活性，但是这里还有一些别的需要在部署结构形成之前考虑到。通常认为remote calls比local calls需要花费更多的时间，在远程过程呼叫中，本地代理对象必须copy所有的参数并且把他们通过电缆传送过来，通过RMI，在远程控制对象时，会造 成网络交通堵塞和长时间的响应等待。考虑到用户在web page上发出一个命令的细节，而这特殊的请求轮流的调用servlet，随后就是处理在session beans和entity beans中的business method。至少4个网络操作都有同时的运行，其中的2个操作都是remote EJB calls。
当session beans call别的 session beans或者多个entity beans时，就需要创建额外的remote calls。如果执行的效果是首先要考虑到的，就需要在构架和设计时作出调整。来减少remote calss 的数量，而且要减少remote calls产生的消耗。
这里我们有许多方法来解决perforamce的问题:
我们可以通过使用EJB的coarse-grained设计模式来减少网络上的trips。
我们可以通过使用本地而不是远程接口或者是实体beans来消除一些不必要的远程呼叫。
我们可以通过改变打包结构来使更多的beans部署在一个EAR文件里从而使一些远程呼叫变成本地呼叫
本地接口 VS 远程接口
J2EE1.3 中引入本地enterprise beans的概念，它可以允许一个entity beans显示本地接口，这样可以允许以引用reference来传递参数而不是传值value。然而为了使session beans能够访问本地enterprise beans必须将本地enterprise beans打包到和session bean一样相同的EAR文件里。通常有两种方法来实现。
a.在数据层中可以在entiy beans之前创建一个session Facade，这样可以同样可以使entity beans在内部application中起到同样的作用，然而，如果仅仅依赖这种session Facade技术的话，程序运行的效果可能并不是很好。
b.把entity beans放到business层中，并且允许business层的session beans可以直接连接本地enterprise beans。这样可以减少entity beans重复使用的程度。本地的entity beans只能在位于相同的EAR文件里起作用，在application外部的模块中的其他的business beans就无法来与entity beans连接。这将使在不同applicatipn 模块中的相同entity beans的实例（instances）加倍。
打包结构
一 些J2EE application server例如BEA的weblogic会优化beasns之间的远程呼叫和本地呼叫.如果beans都在相同的EAR中,这很有利于一个 session beans呼叫多个session beans或者entity beans.但是这样也有一些不利之处:
降低可维护性:所有的打包在同一个EAR的beans必须在同一时间被部署或者是重新部署,这样会阻止在运行时间改变beans的可能性.
平台依赖性: 不是所有的app server都提供这种方式的优化,而且如果你转变app server vendors的话是没有任何作用的.
可能破坏到设计思路: 许多开发人员设计beans都假设所有的参数通过传值而不是传递引用.如果改变呼叫的约定将会破坏以前的假设,特别是如果传递对象的模式被同时用在entity beans中资源定位的考虑另一个区域我们必须考虑通用资源和库的位置,一条戒律是资源一定要随着用到的J2EE模块在一起.然而,如果在某种情况下比如一些同用资源被几个模块同时用 到时,你可以把他放到一个这些模块都可以获取到这些资源的地方.除此之外,把资源路径放入你的系统的CLASSPATH里将会引起与其他J2EE模块部署 到相同的容器的冲突.这样会同样的限制你来部署J2EE应用程序 资源绑定(其他类型的静态资源)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解决方案中高的实用型可用性是比较重要的,这样会导致更加复杂的系统维护.
Third-Party Libraries:
通 常在J2EE工程中包含完全免费第三方的软件是不常见的(比如Apache log4j).在这种情况下,一般是最好把那些库的JAR文件放入到制定地址的一个EAR文件里,如果库与现已存在的被application server正在使用的库冲突或者是改变或升级那些库的需求很小时,那么库路径必须放入到CLASSPATH里是最好的.如果你决定把通用的库放入到 EAR模块的内部,这是必须要确保第三方库必须在制定的地点被加载(eg/lib or /ext)这将会使查找并且处理故障更加的方便,通过鉴别那些内部组件依赖的模块.因为在不同的classloader之间有严格的限制,你必须把第三方 库的路径放入MEANIFEST文件或者使J2EE模块.包括WAR文件和EJB文件.
其他一些的建议
J2EE可以通过很简单的开发方式来开发可升级性能高的和可靠性高的工程,所以,一个J2EE的开发构架必须要在仔细考虑好升级性能和可靠性的需求之后才能作出决定.
可升级性(Scalability)
在前面,我们把application分解成在不通层(tiers)的多个单元(units)将给我们提供更高的可升级性高和可靠性高的模块.然而,必须要仔细考虑到要在确保颗粒度和模块性与灵活性和性能表现之间的平衡关系.
热部署和可维护性(Maintainability and Hot Deployment)
热 部署指的是不需要停止或者重启动application来进行部署和重新部署.如果你的application需要热部署,那么必须要确保 application的资源,依靠第三方库,或者以自身形式打包的其他enterprise模块.避免建立任何依赖与系统classpath的模块,确 保每一个enterprise application模块可能需要到的东西打包到同一个EAR文件中
安全性(Security)
取 决于application的安全性,不同的安全机制如(SSL,VPN,J2EE module declarative security model)可以在不同的层之间执行,从而来提供我们需要的安全级别.尽管J2EE规格说到安全需求是由appliacation server提供的.但是没有指定提供一种什么样的安全性,所以,安全需求可以是可以是由厂商来说明觉定的.入伙你的application 需要在不同的安全管理域通过安全身份来鉴别,(比如分布式安全),那么你就需要毫无疑问的和你的提供厂商来协商.在某些情况下可能会有限制,那么你就需要 限制你在部署构架中的选择
自动部署(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连接池,JMS等,这还是得要依赖于厂商的。
5. 安全配置:J2EE模块通过允许安全角色规范和在部署中的描述符来支持一个清晰的安全模块.然而如果安全信息在部署时改变,系统管理员还是要依赖于厂商所 提供的机制来作出改变模块的独立性:尽管新的标准通过部署描述符允许模块的独立性的规范,独立性并没有被追踪,这样卸载部署时,模块所需要的资源不会自动 的撤销.
总结: 部署还是一个许多J2EE开发人员不是很熟悉的部分,如果部署细节不在设计构架时考虑到,你将会很容使你改变你的构架,综上所述,通常有许多在一开始就要考虑到的地方来满足你的application的表现性,可靠性等的需求。
<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
2002
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
