注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

骇客归来

ぁ枫あ

 
 
 

日志

 
 

J2EE应用程序部署的一些建议(1)   

2007-01-27 11:29:16|  分类: Java |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

http://www.onjava.com/pub/a/onjava/2003/06/11/j2ee_deployment.html?page=1
1。介绍:
如今你和一些资历较高的J2EE开发人员交流的话,他们大部分都很乐意给你提供一些不同类型的EJB的细节问题,或者是怎么样来使用
JMS来发送和接受异步的消息。然而很难找到某个人能够描述一个能够确保可测试性,可靠性,和性能很好的系统构架部署。许多J2EE程序员缺少深入的理解部署。其中一个原因是J2EE specification中包含的应用程序的部署本来就甚少。把这个难题留给个人去考虑。所以这导致了许多困惑,比如每一个设计人员都有可能自己部署j2ee应用程序的方法。在此篇文章中,我们首先要介绍的是描述不同的J2EE模块和不同的打包结构。随后我们将来一起探讨一些可行的部署结构和一些在设计和执行J2EE应用程序中的部署技巧。

再此之前,你最好要了解一些J2EE核心技术,例如JSP,servlet,EJB,XML。

1.1J2EE 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文件中?这些决定将会直接影响到程序的运行稳定性,可维护性,和程序的执行。我们一会就来探讨这些,
1.2类加载器的关系(classLoader RelationShip)
  经常在设计J2EE application时我们会忽略不同的模块类型间类加载之间的关系。Java虚拟机(JVM)用类加载器classloader来查找类和对象并把他们载如内存。在默认的情况下,系统的类加载器会根据在系统中的环境变量的Classpath的位置来加载类,当然也可以为自己的application提供别的加载的地方而不是默认的。

 图1  类加器的
解释图1.应用程序端的server用SystemClassLoader加载,并且只能从通过系统的classpath才能看到资源。每一个EAR和RAR和WAR模块中中都有分离的单独的classloader。Classloaders加载器们的关系没有背很明确的确定,但是一般情况下在4种不同的类加载器中有一种关系就是父与子的关系,就像子类和父类的关系,当子类的classloader可以在在父类的classloader中定位class。但反之不行。在J2EE中systemloader就是所有的EARclassloader的父类classloader。然而EAR classloader是WAR和RAR的父类classloader。
图2 

根据java规范,一个子类类加载器(classloader)在试图定位自己的了类之前必须先用其父类classloader定位这个类。这虽然听起来感觉没什么必要,但是这样是可以阻止当有多个类加载在同一个JVM里的多个类加载器(classloader)之间的含糊不清和之间的冲突。有个别的应用程序服务器允许你自己来选择性的查找EAR和WAR类加载器的加载行为。但是不推荐这样做,因为这样可能造成其他的麻烦,例如classcastException会在一下情况下发生:当在两个相同version的类但是在不同的类加载器中。

2部署结构 (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将会有很好的灵活性,但是这里还有一些别的需要在部署结构形成之前考虑到。

  评论这张
 
阅读(79)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017