J2EE开发模式探讨(小方)

以下是方旭尘对公司目前J2EE开发中存在一些问题看法,希望大家都提提自己的看法。
具体分以下5点来说明：
1.关于J2EE安全性的考虑
公司目前程序的安全性采用的是数据库和程序代码相结合的控制方式,个人觉得采用这种方式存在以下弊端:
A.程序复杂,维护困难
因为目前程序上所有的安全性的控制与实现都是采用代码+数据库的方式,这样就需要书写大量的代码如用户合法性的验证,用户权限控制等等都是需要我们用代码来人工实现的,同样这一切也都需要人工来维护的.如果需求上有所变动也都要更改大量的程序,比如当按钮权限代码更改时就需要更新所有与此相关jsp页面的代码.
B.页面上不易控制
    由于目前代码的方式尚无法对URL访问进行安全控制(因为目前的页面只验证了session而无法验证访问该页面用户的权限),同时因为按钮控制目前是采用从数据库取ID并用js判断的方式,所以使得目前页面上的信息不安全,用户可以通过查看页面源代码的方式得到实现功能页面的URL地址,用户就可以通过在地址栏上的直接输入跳过程序上的安全控制.而又因为页面是发送给客户且js也是运行于客户端所以也就根本不存在页面加密的这一说法,也根本无法实现真正的加密,所以如果采用客户端加密的方式也是不可取的.
C.移植性不强
因为目前采用代码控制安全性所以与现在流行的LDAP控制方式不兼容,如果今后采用标准的LDAP来控制的话,就需要更改权限控制代码,移植性不强.

而如果采用J2EE自带的安全性控制的方式则可以很轻松解决以上的问题. J2EE安全性采用用户(user),分组(group),角色(role)相结合的方式来控制程序安全性.J2EE使用一个领域(realm 指存有完整的用户,角色和分组信息的数据库)来控制一切.在websphere开发中只需要实现一个UserRegistry接口的类,将数据库中用户(user)和分组(group)信息读入即可控制.而在具体的程序开发中(任何在此服务器上的程序项目)不用任何代码来实现安全性的控制,只需要配置安全策略,剩下的实现都是由J2EE容器来实现.由于采用配置安全策略的方式,没有具体的程序代码,所以开发和维护或者今后需求的变更的时候都只需配置或更改安全策略和配置文件而无须书写或更改程序代码.所以就可以很好的解决上面说到”程序复杂,维护困难”的问题
通过J2EE的安全策略可以很好的控制访问每一个页面的用户权限,采用角色(role)的控制,可以指定任何一个页面以何种方式(Get,Post…)允许什么角色来访问.因此就可以很好的控制URL,解决用户在地址栏上直接输入URL以跳开程序控制的问题.至于页面信息的控制同样也可以使用servlet的标准API来取得用户角色来控制是否输出该按钮,而非采用在页面使用js判断是否显示或加密页面的方式.最根本的解决思想就是给用户看到的就是用户能看到的信息,而用户看不到的就不能输出给用户,而不是将其加密后给用户.
至于移植性的问题,因为LDAP本身就是属于J2EE安全性的一部分,websphere中J2EE容器就提供了用户定制验证(数据库属于该种),本地OS验证,以及LDAP验证.所以如果将来使用标准LDAP或其他方式来控制用户安全性的时候,代码或安全策略根本就无需有任何更改,可以完美过渡到任何一种认证方式,不存在任何移植性的问题.
2.关于展现层的讨论
目前公司展示层的开发大部分是采用ocx的方式,采用ocx的优点在于开发实现简单,但也存在一些不足
A.需要安全签名:因为微软对于ocx的安全性控制十分的严格,特别是现在的WINXP SP2对ocx安全性的控制更加严格,在系统默认配置下根本不允许安装没有CA签名的OCX.如果更改客户端的配置,实施量大,就算采用程序来统一更改客户端配置来允许安装,也会存在问题,因为如果更改客户端的配置那么就大大降低客户端的安全性,被修改过的客户端不会区分那些是我们的ocx那些是网络上没有安全签名而带有病毒的ocx.,被修改过的客户端就像是给别人留了一个后门.
B.兼容性问题:ocx存在兼容的问题,在WINDOWS 2000下开发的ocx可能无法很好的运行于winxp下,而在xp下开发的也可能无法运行在2000下(主要原因是操作系统不同,机制上存在差异),现在客户端的操作系统各式各样都有,所以兼容性上存在问题

于是自己考虑在展现层上可以使用其他的方式来实现,以下是几个UI(User Interface)层的开发技术
A.Applet:与ocx的机制相似,兼容性和安全性上强过ocx,而且由于都是基于java机制可以方便与后台交互(使用RMI等技术均可),但开发上比较困难些,而且每次运行都要载入,速度比较慢,还有就是也必须在客户端安装jre的支持,但不同于ocx,jre的支持可以采用程序统一安装的方式因为applet不存在安全的问题.
B.JS+XMLHTTP:我个人目前比较推荐的展示层的表现技术,该方式完全建立在HTML上不存在任何安全和兼容的问题,而且开发上也不困难,JS本身也是类对象的开发脚本,可以很方便的控制页面显示,而且目前也有许多优秀的open source javascript lib来支持开发.比如说ActiveWidgets就是很好的一个,他封装了多个js对象,包括了XMLHTTP,而且借此派生出了Grid等对象,可以方便的将数据转为表格显示.使用xmlhttp对象可以方便的在后台与页面间无刷新传递XML,在加上XSL技术就可以很方便的将数据在客户端转化为HTML显示.而且通过Css可以很方便的实现个性定制等问题(这也是OCX比较难实现的)当然该技术也存在的缺陷,因为采用脚本的方式无法完全达到ocx和applet那种的swing.
C.Flex:也是目前比较流行的一种表现方式,用flash RemoteObject远程调用服务器端的程序,使用XML为传输形式,其优点是脱离了HTML采用FLASH+XML的方式,而且在Flash也可以很方便的实现swing,同时网络上Flash也提供了多种控件的支持,其采用ActionScript来控制.但由于自己对flash的开发不熟悉,所以还无法进行开发,自己现在也在努力研究该技术,个人觉得该技术是一个很不错的方式.
D.XUL, XAML, XWT:这三种方式都是类似的采用以 XML来描述 GUI 布局的技术和 GUI 控件库。也与前面提到的Flash一样脱离了HTML,其中XUL是Mozilla提出的,XAML是微软提出制定的下一代WEB技术,XWT是一个开源项目.XUL的运行需要Mozilla支持, XAML需要微软的支持,微软会在下一个操作系统中默认添加对该技术的支持.而XWT 是完全跨平台的（IE、Mozilla、Opera；Windows、Linux、Solaris），不会像 XAML 或者 XUL 那样将你绑死在某个平台上，而且它很小，性能也很好。 XWT 有两个版本，在 IE 里面是作为一个 ActiveX 控件来运行的，而在所有支持 Java 的浏览器里面（IE、Mozilla、Opera）都可以作为一个 Applet 来运行。因为 IE 自带的 JVM 并不支持 Swing，所以 XWT 没有使用 Swing。XWT 通过 XML-RPC 或者 SOAP 与服务器通信，获得需要显示的数据，因此你可以使用任何支持 XML-RPC 或者 SOAP 的技术做服务器端的开发。XWT 运行在一个严格的沙箱里面，不需要担心其会执行非法的操作。它的 ActiveX 版本是用 Java 写的，而且是用 gcj 编译为本地代码，并且可以通过 COM 接口来访问。XWT 中采用了 JavaScript 作为其脚本语言.

但Flex,XUL,XAML,XWT这四种从本质上来说,都不是B/S结构,只是通过HTTP通讯的C/S结构,而且是瘦客户端C/S结构,是抛弃HTML,抛弃B/S的一种技术,虽然我自己也肯定的认为Web 表示层开发的最终出路是彻底抛弃那种笨拙的基于 HTML FORM 的请求/响应模式，以 XML 技术和 WebService 的体系架构为核心加以彻底改造。B/S 之间在不切换页面的时候，传输的全部是 XML 格式的纯数据.但就目前而言WEB开发的主流还是HTML至少在未来的两三年还会是如此,所以以上这四种技术也许会在将来是主流,但目前自己对他们还不是很熟悉,现在只能作为关注学习的对象,实际的开发中恐怕还不能熟练使用.至于JS+XMLHTTP和OCX我个人的意见是能用JS的用JS,JS实在解决不了的情况下使用OCX
3.关于Java Web FrameWorks的讨论
采用Web framework模式开发是现在流行的做法,公司目前没有采用任何的Web framework,因此开发上缺乏整体的架构,一切显得相当无序,各层之间的界定也不十分明确,耦合太紧.因此强烈建议公司采用一套Model 2/MVC架构的Web framework.以下是自己对目前几个比较流行Web framework的看法
A.Struts:由于发布时间长所以Struts是目前最流行的框架也是事实标准.网络上材料多,使用者多,支持也多.但也由于其先天的问题存在了很多不可解决的弊端比如FormBean,大量的标签,难以调试等问题
B.WebWork:与Struts类似,算是Struts的改良版,解决了很多Struts的问题,个人觉得是一个将来可能会替代Struts的框架.使用上相当灵活.
C.Spring:也是一个很好的MVC框架,特别是在IoC上,是目前IoC上最流行的框架,可以同Struts或WebWork搭配使用
D.Tapestry: 应该算是最先进的架构，然而过多的复杂度妨碍了Tapestry的普及

个人觉得WebWork+ Spring是一个很不错的选择,具体的架构后面给出
4.关于持久层框架的讨论
使用O/R Mapping将数据库映射为PO(持久对象),避免了大量的SQL,使用OO的操作方式来操作表更为直观,至于持久层的框架选择建议就是采用目前最流行的Hibernate.
Hibernate是目前最优秀的持久层框架,它是开源和免费的License，我们在开发中可以在需要的时候研究源代码，改写源代码，进行功能的定制。而且它是轻量级封装，避免引入过多复杂的问题，调试容易，也减轻了负担,还有就是它提供了完整的文档支持,使得开发变的简单了.
5.具体架构实现
这里是自己提出的一套WEB开发的架构
A.UI层技术:使用JS+DHTML+XMLHTTP(如果技术允许下可以使用Flex)
B.WEB层框架:WebWork(比Struts更为的灵活,也更易于搭建)
C.中间层框架:Spring(因为它与Hibernate的完美结合,而且在Ioc上很好的控制,对Bean的管理)
D.持久层框层:Hibernate