创建灵活易扩展的J2EE企业应用程序框架
2008-01-05 08:04:54 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽i鍓х<闁诡垎鍐f寖闂佺娅曢幑鍥灳閺冨牆绀冩い蹇庣娴滈箖鏌ㄥ┑鍡欏嚬缂併劎绮妵鍕箳鐎n亞浠鹃梺闈涙搐鐎氫即鐛崶顒夋晬婵絾瀵ч幑鍥蓟閻斿摜鐟归柛顭戝枛椤牆顪冮妶搴′簼缂侇喗鎸搁悾鐑藉础閻愬秵妫冮崺鈧い鎺戝瀹撲礁鈹戦悩鎻掝伀缁惧彞绮欓弻娑氫沪閹规劕顥濋梺閫炲苯澧伴柟铏崌閿濈偛鈹戠€n€晠鏌嶆潪鎷屽厡闁汇倕鎳愮槐鎾存媴閸撴彃鍓卞銈嗗灦閻熲晛鐣烽妷褉鍋撻敐搴℃灍闁绘挻娲橀妵鍕箛闂堟稐绨肩紓浣藉煐濮樸劎妲愰幘璇茬闁冲搫鍊婚ˇ鏉库攽椤旂》宸ユい顓炲槻閻g兘骞掗幋鏃€鐎婚梺瑙勬儗閸樺€熲叺婵犵數濮烽弫鍛婃叏椤撱垹纾婚柟鍓х帛閳锋垶銇勯幒鍡椾壕缂備礁顦遍弫濠氱嵁閸℃稒鍊烽柛婵嗗椤旀劕鈹戦悜鍥╃У闁告挻鐟︽穱濠囨嚃閳哄啰锛滈梺褰掑亰閸欏骸鈻撳⿰鍫熺厸閻忕偟纭堕崑鎾诲箛娴e憡鍊梺纭呭亹鐞涖儵鍩€椤掑啫鐨洪柡浣圭墪閳规垿鎮欓弶鎴犱桓闂佸湱枪閹芥粎鍒掗弮鍫熷仺缂佸顕抽敃鍌涚厱闁哄洢鍔岄悘鐘绘煕閹般劌浜惧┑锛勫亼閸婃牠宕濋敃鈧…鍧楀焵椤掍胶绠剧€光偓婵犱線鍋楀┑顔硷龚濞咃絿妲愰幒鎳崇喓鎷犻懠鑸垫毐闂傚倷鑳舵灙婵炲鍏樺顐ゆ嫚瀹割喖娈ㄦ繝鐢靛У绾板秹寮查幓鎺濈唵閻犺櫣灏ㄥ銉р偓瑙勬尭濡繂顫忛搹鍦<婵☆垰鎼~宥囩磽娴i鍔嶉柟绋垮暱閻g兘骞嬮敃鈧粻濠氭偣閸パ冪骇鐎规挸绉撮—鍐Χ閸℃ê闉嶇紓浣割儐閸ㄥ墎绮嬪澶嬪€锋い鎺嶇瀵灝鈹戦埥鍡楃仯闁告鍕洸濡わ絽鍟崐鍨叏濡厧浜鹃悗姘炬嫹

随着J2EE的飞速发展,已经有越来越多的企业应用程序以J2EE技术为其构建的基石,J2EE本身并不是产品,它只是制定了一套创建企业应用程序的规范,不同厂商根据J2EE规范,创建了符合J2EE规范的产品,这给予了我们更多的选择创建企业应用的平台。
一个典型的J2EE的应用,至少应该包括以下三部分:表现层,业务逻辑层和数据持久层,为了更加轻易地创建企业应用程序,许许多多的Framework涌现出来,表现层我们可以选择Struts, JSF, Tapestry, WebWork, Velocity等,数据持久层我们可以选择原始的JDBC, ORMapping tools(Hibernate,toplink等),SQLMapper tools(Ibatis),JDO, EJB(Entity Bean)等,业务逻辑层我们可以用普通的java Beans,也可以用EJB(session Bean)。
每种技术都有它的优点与缺点,各自有各自的适用范畴,例如EJB可以很好地进行分布式处理和Object Cache等,但EJB的运行需要EJB容器,开发调试起来很不方便,非凡在需求不确定性很大、模型不稳定的情况下,实在是一种重量级别的开发;而JAVA BEAN则是一种很轻量级的方式,开发调试轻易,但又很难实现分布式处理。
在各种技术纷争的今天,暂时还没有一种技术处于绝对的霸主地位,在这种条件下,我们不能把“赌注“押在任何一种技术上,如何使我们的应用程序有很高的灵活性和易扩展性是我们要仔细研究的课题。
在实际的项目中,关于应用程序开发时所用技术的问题,大致存在两种情况,一种是构架师或技术经理没有严格限定用什么技术来实现具体的业务逻辑或者只有简单的开发规范,程序员在开发时,只是依据自己的技术背景,选择自己熟悉的实现方式,这种情况一般属于横向开发,在小的项目中,每个人只做自己负责的一个模块,从表现层,业务逻辑层,一直到数据层,都由同一个人来负责,这种方式给了技术人员更多的自我发挥能力的空间,但不便于后期维护,非凡是人员流动频繁的情况下,问题更是严重。
第二种情况是构架师或技术经理在项目初期从开发成本,项目需求等等各个方面做出评估,经过几番取舍,确定项目各个层面使用什么样的技术实现方式,按不同层面进行分工,不同的工作人员负责不同层面的技术实现,这种方式比第一种方式要好得多,适合校大项目的开发,但也存在很多问题。
在目前各种实现技术纷争的情况下,没有一种技术是万能的,在做取舍时,难免和某一技术或实现方式依靠性过强,同时限定了技术人员个人技术特长的很好发挥,当由于某些原因要更改实现方式时,经常是牵一发而动全身,造成资源的极大浪费和开发成本的提高。
所以,在构建企业应用时,应该有个好的技术框架,这个框架应该考虑到各种主流的实现技术,我们既可以根据实际情况进行取舍,同时在从一种实现方式变更为另一种实现方式时,又可以进行平滑过度,让多种技术实现并存,发挥技术人员的最大优势,降低项目成本,提高开发效率。
基于SOA的构架
图一

SOA(Service Oriented Architecture),对这一术语我们并不生疏,因为Web service是基于SOA的一种技术,服务的提供者将提供的服务注册到UDDI,其使用者从UDDI上获得服务的描述(WSDL),然后根据服务接口使用服务。
Web Service用xml进行消息的传递,通过SOAP绑定在现有的轻量级协议,如HTTP之上,可以透过防火墙,不依靠服务端和客户端具体地实现技术,进行分布式远程调用,它是现有的应用向Internet的延伸。
Web service在EAI,B2B,应用到应用的集成等方面体现了巨大的优势,有很多文献介绍Web service,由于这不是本文重点,在此不再赘述。
SOA的优势在于降低了服务的提供者与使用者之间的耦合性,服务的提供者将自己提供的服务注册在中介那里,服务使用者先通过中介查找自己所需服务,使用者获得的是服务接口,但并不知道服务的具体实现,它根据调用接口调用服务,这样即使服务的实现方式发生了变化,只要供使用者调用接口没有改变,服务使用者就不会受到任何影响,这种思想正是我们应该学习和借鉴的地方。
那么既然Web service是基于SOA的,我们的企业应用是不是就可以完全构架在Web service上呢?我们并不建议这么做,Web service对于企业内部的应用并不太适合,在一个应用内部使用Web service,系统大量的资源花费在进行XML消息的解析和进行远程调用上,造成系统运转缓慢。
当然,从某种意义上讲,EJB也是SOA的一种实现,服务的提供者把服务注册在JNDI上,使用者通过JNDI找到自己想要的服务,通过远程接口使用服务,但EJB的运行需要EJB容器,开发调试起来不方便,非凡对于需求经常变化的系统,进行EJB调试的时间会更久。
我们所需要的是一个轻量级的构架,能兼顾各种主流的技术,但又不依靠具体的某个实现方式,当实现方式从一种技术变更为另一种技术时,对于服务的使用者来说几乎没有影响,从而实现客户端和服务器端的松耦合,这样,我们的表现层,业务逻辑层和数据持久层都可以依据实际需求情况与偏好随意选择各种实现方式。
随着J2EE的飞速发展,已经有越来越多的企业应用程序以J2EE技术为其构建的基石,J2EE本身并不是产品,它只是制定了一套创建企业应用程序的规范,不同厂商根据J2EE规范,创建了符合J2EE规范的产品,这给予了我们更多的选择创建企业应用的平台。
一个典型的J2EE的应用,至少应该包括以下三部分:表现层,业务逻辑层和数据持久层,为了更加轻易地创建企业应用程序,许许多多的Framework涌现出来,表现层我们可以选择Struts, JSF, Tapestry, WebWork, Velocity等,数据持久层我们可以选择原始的JDBC, ORMapping tools(Hibernate,toplink等),SQLMapper tools(Ibatis),JDO, EJB(Entity Bean)等,业务逻辑层我们可以用普通的JAVA Beans,也可以用EJB(Session Bean)。
每种技术都有它的优点与缺点,各自有各自的适用范畴,例如EJB可以很好地进行分布式处理和Object Cache等,但EJB的运行需要EJB容器,开发调试起来很不方便,非凡在需求不确定性很大、模型不稳定的情况下,实在是一种重量级别的开发;而JAVA BEAN则是一种很轻量级的方式,开发调试轻易,但又很难实现分布式处理。
在各种技术纷争的今天,暂时还没有一种技术处于绝对的霸主地位,在这种条件下,我们不能把“赌注“押在任何一种技术上,如何使我们的应用程序有很高的灵活性和易扩展性是我们要仔细研究的课题。
在实际的项目中,关于应用程序开发时所用技术的问题,大致存在两种情况,一种是构架师或技术经理没有严格限定用什么技术来实现具体的业务逻辑或者只有简单的开发规范,程序员在开发时,只是依据自己的技术背景,选择自己熟悉的实现方式,这种情况一般属于横向开发,在小的项目中,每个人只做自己负责的一个模块,从表现层,业务逻辑层,一直到数据层,都由同一个人来负责,这种方式给了技术人员更多的自我发挥能力的空间,但不便于后期维护,非凡是人员流动频繁的情况下,问题更是严重。
第二种情况是构架师或技术经理在项目初期从开发成本,项目需求等等各个方面做出评估,经过几番取舍,确定项目各个层面使用什么样的技术实现方式,按不同层面进行分工,不同的工作人员负责不同层面的技术实现,这种方式比第一种方式要好得多,适合校大项目的开发,但也存在很多问题。
在目前各种实现技术纷争的情况下,没有一种技术是万能的,在做取舍时,难免和某一技术或实现方式依靠性过强,同时限定了技术人员个人技术特长的很好发挥,当由于某些原因要更改实现方式时,经常是牵一发而动全身,造成资源的极大浪费和开发成本的提高。
所以,在构建企业应用时,应该有个好的技术框架,这个框架应该考虑到各种主流的实现技术,我们既可以根据实际情况进行取舍,同时在从一种实现方式变更为另一种实现方式时,又可以进行平滑过度,让多种技术实现并存,发挥技术人员的最大优势,降低项目成本,提高开发效率。
基于SOA的构架
图一

SOA(Service Oriented Architecture),对这一术语我们并不生疏,因为Web service是基于SOA的一种技术,服务的提供者将提供的服务注册到UDDI,其使用者从UDDI上获得服务的描述(WSDL),然后根据服务接口使用服务。
Web Service用XML进行消息的传递,通过SOAP绑定在现有的轻量级协议,如HTTP之上,可以透过防火墙,不依靠服务端和客户端具体地实现技术,进行分布式远程调用,它是现有的应用向Internet的延伸。
Web service在EAI,B2B,应用到应用的集成等方面体现了巨大的优势,有很多文献介绍Web service,由于这不是本文重点,在此不再赘述。
- ››创建SQL2005自动备份,定期删除的维护计划
- ››创建动态表单 javascript
- ››灵活更改Windows 7“自动播放”设置
- ››灵活更改Win7系统“自动播放”设置
- ››扩展Axis2框架,支持基于JVM的脚本语言
- ››灵活运用ISA的链接转换功能:ISA2006系列之十三
- ››创建基于PPTP的站点到站点VPN连接:ISA2006系列之...
- ››创建基于L2TP的站点到站点的VPN连接:ISA2006系列...
- ››灵活配置DHCP服务器 解决更改IP地址问题
- ››扩展WebSphere Portal V6个性化功能
- ››创建一个Twisted Reactor TCP服务器
- ››扩展JavaScript的时候,千万要保留其原来的所有功...
更多精彩
赞助商链接