JSF技术在基金管理系统中的应用与分析

2022-09-12

自2000年以来, 随着JAVA技术在网络应用系统中的发展与深入, 越来越多针对服务系统中不同组成部分的新技术不断涌现, 如Struts, jstl, xslt, HTTPS, ajax, SOA, J S F等等。这些新技术有的有利于系统架构的开发, 有的保护网络数据传输的安全性, 有的能使应用界面更加友好。J S F作为出道不久的新秀, 一露面就受到了众多网络系统开发人员的追捧。其主要原因就是J S F具有类似V B一样的组件事件响应的机制而且开发出来的界面友好。目前, 金融行业是网络应用系统的主要客户之一, 各大银行, 证券公司, 金融行业机构都需要网络应用系统来处理公司内部 (如资金转移, 股票基金结算等) 或者外部 (如用户账户操作, 银行间资金转账, 抵押贷款等) 业务。J S F作为主要针对网络应用系统中表现层的新技术, 其特性到底能对现有的网络应用系统带来多大改观和相关性能的提升。本文中我们将以基金管理系统为研究平台, 以原有基于J S P作为界面开发语言的管理系统作为比照对象, 从开发者, 使用者, 维护者的角度出发对J S F改写的基金管理系统进行比较。

1 JSF技术的发展及背景

在目前的网络应用系统 (Web Application) 中, Java已成为主要的开发语言, 其具有的安全性, 易操作性是J a v a受欢迎的主要原因。Servlet与JSP的组合已成为很多网络应用程序的首选。开发人员能够利用这两种技术开发出丰富多彩的界面和健全的后台程序。然而, 随着界面越做越复杂, 单一界面的集成越来越高, H T T P协议的不足之处逐渐凸现。H T T P协议是一种简单的无链接通讯协议, 每次链接只处理一个请求。服务器处理完客户的请求, 并收到客户的应答后, 即断开连接。采用这种方式可以节省传输时间。其无链接的特性使得H T T P协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息, 则它必须重传, 这样可能导致每次连接传送的数据量增大。另一方面, 在服务器不需要先前信息时它的应答就较快。但是对于许多信息数据处理方面的开发人员来说, H T T P协议的这一特性, 无疑给他们带来了很多编程的负担。开发者们开始怀念过去使用G U I框架的美好时光。同时传统的G U I框架提供了很多方便好用的U I组件, 而且事件驱动模型 (e v e n tdriver model) 也比较符合网络应用系统的结构。特别是G U I框架可以帮开发者处理掉很多琐碎的细节。

在J S F推出以前, 已经有许多开发人员开始模拟传统G U I框架, 并推出众多开源或者商业版本, 其中比较著名的有S u n的JATO, Apache的Tapestry以及甲骨文的UIX。2001年初, 各家开发公司开始考虑采众家之所长并能够兼容各家框架的标准解决方案, 最终成立了J a v a C o m m u n i t y Process (JCP) 团队。在2004年的3月, JCP正式推出JavaServer Faces 1.0。

2 基金管理系统简介

基金管理系统是金融管理系统里一个典型而又重要的一部分, 它涵盖了金融交易所需要的各个模块, 主要有 (1) 参数维护, 其中包括:基金设置, 货币设置, 系统参数设置等等; (2) 账户维护, 包括:建立账户, 账户查询与修改; (3) 交易, 其中包括基金买卖, 分红, 基金关闭, 拆分等等; (4) 订单处理, 其中包括订单查询, 订单取消, 订单属性修改等等; (5) 查询系统。

虽然表面上看, 整个基金管理系统的各个模块并不复杂, 但是每种模块在界面上的特点确大不相同。表1列出了各个模块的界面元素特点。

输入元素数量:界面上用户可以输入的元素数量, 元素可以包括输入框 (多行) , 下拉菜单, 单选框以及多选框。

显示元素数量:只在界面上显示的元素数量。

提交元素数量:提交H T T P请求时所需要上传数值的元素数量, 考虑到安全的问题, 几乎每个用户可输入的元素都有一个隐藏元素相对应。所以, 提交的元素数量可能是输入元素数量的一至二倍。

需验证元素数量:需要验证用户所输入值是否正确或符合要求。

需动态显示元素数量:需要根据用户的操作来改变元素内容或属性的数量。

流程深度:运行完一个完整模块所需要访问的页面数。

由于对各个模块的业务需求不同, 有些模块偏向与显示数据 (订单处理) , 有些模块则倾向与用户输入 (参数维护) 。而对于那些流程深度较大的模块, 因为需要保留用户的操作过程, 所以隐藏元素将会大幅增加。

3 实现基于JSF的系统表现层

J S F技术是一种只针对表现层的技术, 所以对原有系统只要求支持J S P (J a v aServer Page) 。而在JSP页面中, JSF是以自定义标签库 (T a g l i b) 的形式出现。因此, JSF对JSP具有相当好的兼容性。除JSP之外, J S F也支持其他表现层, 不过本文主要的研究对象是采用以J S P为主的表现层, 所以对J S P技术之外的技术, 本文将不加以累述。

3.1 准备工作

开发基于J S F技术的基金管理系统表现层其实并不是很困难, 因为J S F并不是一项商业技术, 并不需要承担任何费用。而且与J S F相关的J A R包非常好找, 在目前的几大网络搜索引擎中, 我们都可以找到很多相关下载的链接。

用J S F技术实现基金管理系统的表现层, 我们需要一下几个J A R包:

(1) commons-beanutils.jar:包含定义并访问JavaBeans组件相关属性的工具。

(2) commons-collections.jar:包含对于J2SE中的Collections Framework的相关扩展代码。

(3) commons-digester.jar:包含用于处理X M L文件的代码。

(4) commons-logging.jar:包含通用的登录代码, 开发者可以用l o g g i n g语句来完成代码。

(5) jsf-api.jar:包含JSF的核心代码。

(6) jsf-ri.jar:包含JSF相关的用于参考的实现类。

(7) jstl.jar:JavaServer Pages Standard Tag Library classes的相关代码。

(8) jstl_el.jar:包含JSTL表达式相关的代码。

(9) standard.jar:包含JSTL需要的文件。

3.2 配置环境

开发之前我们需要引用以上所有文件, 并在WEB-INF下的web.xml (服务器配置文件) 中加入一下语句:

由于访问J S F技术开发的页面时, 需要FacesContext来获得JSF请求相关的上下文环境, 所以无论采用J S F技术的页面路径在哪里, 访问时都要在路径的r o o t后面插入/f a c e s/, 让J S F请求先进入FacesServlet中进行处理, 而FacesServlet会将处理完的结果直接forward到/faces/后的页面路径中。

除了在web.xml加入FacesServlet相关的代码外, 我们还要在WEB-INF文件夹中建立一个faces-config.xml文件。这个文件的作用于Struts技术中的struts-config.x m l文件有点类似, 它是针对一些基于J S F技术所开发系统的配置文件, 其相关代码如下:

定义了Java Bean的相关信息, 表示在采用J S F技术的页面中, 存储与读取J a v a Bean的别名, 定义了别名所对应的class文件, 而则定义了存储与读取Java Bean的范围。

的作用与strutsconfig.xml中的的作用相似, 是对FacesServlet处理完后结果的一个转发, 表示发送HTTP request的页面, 包含转发地址的配置信息, 是转发地址的别名, 每个页面调用的Java Bean中的方法必须是返回一个S t r i n g对象, 这个对象包含的内容就是转发地址的别名, 而表示实际转发的地址。

3.3 编写代码及要求

配置完后就是实际的编写代码阶段, 在faces-config.xml中所涉及的Class文件必须是标准的Java Bean, 其中必须包括无参的构造方法或匿名构造方法, 以及与所有成员变量相匹配的get/set方法。如果页面中的JSF taglib调用了Java Bean中的某一个方法, 这个方法的返回类型必须是java.lang.String。

对于页面文件 (J S P文件) , 因为J S F是以taglib的形式出现, 所以JSP文件没有多大的规定。编写时只要在JSP中导入对JSF相关t a g l i b的引用即可, 代码如下:

在编写页面时, 可以利用J S F提供的U I组件来代替原来的H T M L节点, 例如:

H T M L节点中的输入框:

JSF中taglib实现的输入框

另外J S F技术提供了一种类似于自动回填的功能, 只要采用了J S F提供的相关表单、输入框、下拉菜单以及JSF的EL语言, 在表单提交以后, J S F会自动将用户在这些输入元素中输入的数值根据E L的所表达的显示路径回填至相关Java Bean的成员变量中。这就是J S F技术所表现的类似于传统G U I框架的功能, 为开发人员省去了许多维护H T T P状态的代码量, 也为开发人员节约了编码的时间。

4 JSF与传统JSP在基金管理系统中的对比

前一节中描述了用J S F技术实现基金管理系统的一个简便快捷的方法。但是基于J S F技术的基金管理系统, 能否在各个方面超越原来用J S P技术实现表现层的系统呢?我们将对这两个系统进行对比。

4.1 代码量与开发速度

基于J S F技术的页面, 主要就是将原来与输入输出相关的HTML节点用JSF提供的UI组件以及Taglib来替代。从开发的角度上来看, 完成一个基于J S F技术的界面与实现一个基于J S P技术的页面所需要消耗的时间几乎没有什么很大的区别。但是, J S F技术最大的特色就是能够实现类似于传统G U I的特性, 即保留当前的状态, 它能够将用户输入的信息通过J S F自己的EL语句反映射入对应的Java Bean。JSF技术的这种特性能够帮助开发人员节省许多原来J S P页面与数据回填相关的代码, 同时还可以减少后台文件的体积。

4.2 代码重用与可移植性

虽然J S F技术为开发人员提供了许多简单实用的U I组件, 但是这些组件的使用还是基于J S P技术和规范。所以在代码重用与可移植性方面, 两者之间并没有什么差别。

4.3 响应速度

在用J S P开发的页面中, 表单的提交过程相对来说比较简单, 在完成对表单数据的一系列验证过程以后, 开发人员可以调用form.submit () 来直接发送请求。而在服务端, 后台S e r v l e t直接接收这一请求。在处理完这个请求以后, 将结果转发至指定页面。而用J S F实现的页面, 其处理请求的过程相对来说就比较复杂, 由于基于J S F技术的U I组件会在表单的提交过程中插入许多JSF框架自己的javascript, 所以在页面数据比较庞大的情况下, 表单的提交速度会受到影响。在到达服务端后, 请求并没有直接进入开发人员的后台程序, 而使先经过FacesServlet, 他会对请求进行所配置的检验, 数据回填以及请求的再包装, 这些过程都会消耗一部分系统资源并减慢的响应速度。特别是数据回填, 表面上看J S F的这一特性使开发更加省力, 实际上是将这一过程从开发人员实现转换成系统自动实现, 所以资源的消耗和运行的代码量并没有减少, 而且实现这一功能会用到反射 (reflection) , 使响应时间大大增加。最后生成页面的过程中, 由于使用了大量的 (自定义) J S F标签, 运行的代码量有了一定量的增加, 同时也影响了整体响应速度。所以在请求响应速度方面, JSF远不如JSP那样快捷。

4.4 代码的维护

根据J S F技术的特性, 我们可以把它看作是一种Taglib在JSP中的扩展应用, 而且可读性非常高。只要会使用t a g l i b以及对JSF框架有所了解, 就可以对基于JSF技术的基金管理系统进行维护。

5 结语

从以上对J S F技术的描述以及与纯J S P开发的基金管理系统的对比来看, J S F技术虽然是一种非常方便而又快捷的系统表现层实现技术, 但是它所带来的性能下降不可忽视。特别是对于基金管理系统这种数据量大, 而且对请求响应速度比较敏感的系统, 不建议用J S F技术完全替换原有系统的代码。相对的, 可以在一些不常用或访问频率不高并且对响应速度要求不是很严格的模块 (如参数维护) 上采用J S F技术, 这样可以大大减少开发的时间和代码量。

摘要：在目前应用于金融服务系统的技术中, 通常使用JSP来生成用户界面。然而, 随着系统越来越复杂, 开发人员在编写JSP页面上的用时越来越长, 而HTTP协议的stateless本质使得开发者忙于处理那些原本可以由AWT (或Swing) 处理掉的内容。开发者们开始怀念过去GUI框架, JSF技术因此孕育而生。JSF技术具有类似VB一样的组件事件响应的机制而且开发出来的界面文件简洁明了, 受到许多开发人员的追捧。然而, 对于金融行业的服务系统, JSF技术真的能不负众望在金融服务系统中大展拳脚吗?本文将以基金管理系统为平台, 对JSF技术的应用加以对比分析。

关键词：JSF,JSP,金融业,事件驱动模型,UI