简析从J2EE框架到基于Web2.0框架的软件重构

2022-09-10

Web2.0的概念自2003年提出, 就开始广泛应用到W e b应用中, 渗透到了日常生活的方方面面。与此同时, 企业级软件产品在经历了C/S到B/S的转变后, 也正在web2.0的路径上摸索前进。如何实现一个基于w e b 2.0框架的软件产品, 为用户提供一个具有可用性、可修改性、可重用性、稳定性、安全性的系统, 是各大企业下一个的目标。

1 Web2.0简述

1.1 Web2.0概述

W e b 2.0代表着新一代的以W e b为基础的技术, 带给我们的是软件即服务的交付模式, 简化并促进了W e b用户参与分享、交互与协作, 从而产生更有价值的内容和服务。同时, 对于开发人员和最终用户而言, 它简化了对数据源的访问、使用和协作。

基于W e b 2.0的框架应具有如下基本功能: (1) 异步内容更新; (2) 可配置的用户界面和流程控制; (3) 松散的业务流程交互和操作。其功能正体现了其优越性:使用角度看, 以用户为中心, 丰富用户体验;开发角度看, 它是一个轻量级的开发模式、易于维护和更新、开放易于重用、具有可管理性。优势会在新框架的阐述中一一浮现。

1.2 Web2.0与SOA

S O A (面向服务的架构模式) , 简而言之, 就是一串代表业务功能的服务的组合, 流行于企业软件中, 与W e b 2.0采用同样的设计哲学和理——“软件即服务”。因此SOA是从根本上实现Web2.0的基石。Web2.0提供的丰富用户体验, 极度的简单性和易用性, S O A提供的核心业务服务和数据, 两者相辅相成。

1.3 Web2.0的相关技术

Web2.0包含了很多技术HTML、CSS、HTTP、JavaScript、XML等等, 在此重点研究Ajax技术、Web服务技术。

(1) A j a x与D O M技术:A j a x (异步JavaScript和XML) , 通过编写JavaScript代码来改进H T M L以期带给用户更丰富的体验。它是多项技术的组合, 其主要步骤为:DOM (Document Object Model) 技术实现数据传输和序列化, X M L与X S L T进行数据交换, XMLHTTPRequest进行异步数据读取, JavaScript绑定和处理返回数据。

(2) Web服务技术:Web服务, 是与平台和开发语言无关的应用程序通信方式。W e b服务是一个软件接口, 包含了一组基于标准化X M L消息、通过网络访问的操作。Web服务中所使用都是基于XML语言的协议, 包括了可执行的操作以及与其他Web service或应用程序交换的数据。Web服务之间都是松散偶合的。连接中的任何一方均可更改执行机制, 却不影响应用程序的正常运行。从技术角度讲, 它通过基于消息的异步技术来实现高可靠性的系统性能, 通过使用诸如H T T P、简单邮件传输协议 (SMTP) 以及至为重要的XML来实现统一的连接。但是W e b服务只是一个方便程序访问的包装, 真正的服务是要靠中间件来实现的。访问包括服务请求处理 (监听者) 和一个支持商业逻辑操作的接口, 商业逻辑本身是由传统的中间件平台实现的。

2 现有的J2EE框架及Web2.0的使用现状

如今在大型软件产品中, 存在着Mainframe、流程编排、数据转换等诸多的应用难题, 而当前J 2 E E框架下的开发方法往往会使软件面临高耦合度, 不宜维护, 无法及时响应需求变化等问题。

图1是现有系统框架, 在服务器端采用MVC设计模式将程序大致分成三层:s e r v l e t层用于处理客户端发送的请求, 并调用相应的service来实现特定业务逻辑, service会根据请求调用所需接口, 接口大致分为三类:D A O (数据访问对象) 来获取数据库数据;Wrapper即消息Bean, 用于通过MQ与M a i n f r a m e交换数据;其他文件系统接口, 用于与其他系统通信或交换数据。显而易见, 各程序间彼此依赖, 很难重用。

由图1亦可见, 在当前系统框架中, 对于W e b 2.0的应用还仅限于Ajax技术, 即用于实现页面的无刷新更新, 而这是远远不能满足用户对页面的需求的。

3 基于Web2.0框架的分析与探讨

3.1 基于Web2.0框架的描述

基于web2.0的框架是由Ajax技术和W e b服务技术共同实现的, 是基于S O A的架构模式。如图2所示, 新的框架将通过W e b服务调用实现客户端和服务器端的通信, 同时服务器端内部通信同样用W e b服务实现, 对所有数据存储系统的操作都以w e b服务的形式封装起来。

3.2 基于Web2.0框架的优势与不足

3.2.1 Web应用程序中的关键特性为可伸缩性、可用性、可维护性、可靠性

(1) 可伸缩性:W e b服务可以自由实现向上向外扩展。新架构是针对基于网络的应用, 向上扩展时, W e b服务的线程支持数可根据实际情况通过服务器设置;向外扩展时, W e b服务可以部署于任意多个服务器, 可以通过修改或已配置的U R L来实现访问不同服务器上服务、实现相同功能。而J 2 E E框架虽然也支持向上向外扩展, 但其部署远较W e b服务的部署来得复杂和费时。

(2) 可用性:新框架可以实现任意形式的分布式部署。

W e b服务是原子级的, 可以同时部署在不同的服务器上进行工作:一方面可以保证负载均衡, 另一方面一旦有服务器出现故障, 也不会导致系统完全瘫痪, 还没有定时停机的需要。

(3) 可维护性:可维护性是Web2.0架构的最大优势。同样由于W e b服务是原子级的, 对于功能升级或添加新功能几乎不耗费资源, 只需在原有系统配置一个入口 (如果原有系统具有配置新模块功能, 则对原有系统没有任何改动) 。对于功能升级, 如果接口没有变化, 亦可单独部署。

(4) 可靠性:首先, 从前三点可以看出, 新框架不存在性能问题引起的停机, 因为由于每个服务都相对独立, 且可重复部署;其次是程序内部错误引起的停机, 在W e b 2.0的框架中无论是客户端人机交互界面的JavaScript还是服务器端的Web服务都具有报错机制, 而如何建立良好的异常处理框架是我们需要构思的。

3.2.2 除了四大关键特性之外, 以下重要问题同样值得探讨

(1) 数据安全性:对于企业软件特别是金融软件而言, 数据的安全性是重中之重。

服务器端的W e b服务技术被公认为未来W e b发展的关键架构, 从一开始就充分考虑了架构中的认证、授权、加密、传输安全问题, 并制定了相关的安全标准和策略。例如, 使用WS-Security策略将安全信息嵌入S O A P请求内, 以及使用S A M L (Security Assertion Markup Language, 安全断言标记语言) 确保W e b用户可信任。

客户端的Ajax技术是JavaScript及X M L等几种技术按一定方式的结合, 它的出现并未充分考虑认证、加密等可能出现的安全问题且完全问题不但存在于请求发送还存在与响应接收。主要攻击为同源策略、跨站脚本攻击 (XSS, Cross SiteSript) 、窃取cookies或密码、监听键盘输入鼠标活动等。所以每个应用都需要根据具体情况设计对应的安全策略。除了对敏感数据加密之外, 对于服务器端攻击, 设想修改A j a x的脚本引擎, 使其在发送S O A P请求和收到S O A P响应时都进行安全验证从而使客户端脚本与服务器间建立起安全连接、避免安全性问题。而对于客户端的攻击则需针对攻击类型, 进行输入值检验和过滤、在集成不可信内容时使用等。

　　(2) 系统性能:系统性能上的忧虑主要存在于客户端文件加载和X M L数据解析及加密。当用户界面采用HTML+AJAX, 意味着有大量的J S文件以及X M L格式的数据需要与页面一起加载时到客户端, 同时Web2.0框架下的数据都是XML格式传输的, 而X M L编码方式的消息比二进制编码的消息平均要大六至八倍且它们还在不断地增大, 信息交换中使用的很可能是整个文档, 一般大小超过4 0 K字节的消息是很常见的。这无疑会加大服务器负荷而降低页面的加载速度。另外, 与通过R M I/I I O P传递的数据和/或对象相比, 将消息绑定到程序对象和数据操作时涉及到的X M L编码需要进行更多的计算——这也意味着在解析数据同时需要占用一定的客户端资源来解析, 这可能会对客户体验造成一定的影响。

　　对于J S文件的传输, 应当合理控制文件数量和文件大小。对于XML数据传输量而言, 一方面从算法上提高X M L数据解析的性能, 另一方面控制数据量的大小, 当数据量过大时, 对数据进行适当分页分批, 或者使用压缩技术对S O A P数据进行压缩后发送。

4 J2EE框架向基于Web2.0的新框架的转化过程

　　了解了W e b 2.0的新框架之后, 下一步是基于现有框架指定重构方案, 以降低软件的重复开发成本, 降低使用人员培训成本, 提高软件的可操作性。鉴于软件项目的生命周期和成本控制的因素, 一步到位的重构似乎并不太容易。因此基于现有J 2 E E架构, 我们将重构分为了两个阶段:客户端重构和服务器端重构。

4.1 第一阶段:客户端重构

　　客户端重构降低与客户端服务器端的耦合度, 重构客户端人机交互界面。

　　在客户端与服务器端之间加入E S F (Enhanced Service Face) 层, 以降低客户端与服务器端的耦合度。当一个请求发生时, 页面会向ESF层以SOAP的形式发送请求, E S F层会根据请求中相关的参数调用相应的W e b服务和操作, 这些W e b服务会通过Web Server调用现有的Java API。

　　在重构人机界面时, 以M V C模式搭建人机交互界面框架。M V C设计模式在面向对象的用户界面和应用程序控制工具包中得到了广泛地应用, 如今我们设想把其应用于通过JavaScript实现的UI。根据MVC设计模式把程序分成三个核心模块——模型、视图和控制器, 分别作用于业务逻辑实现, 数据显示和请求分发及实现。同时采用可配置的X M L文档来实现视图层和业务流程的可配置, 用户可通过特定模块维护系统参数来控制页面的显示和业务流程。

4.2 第二阶段:服务器端程序重构

　　W e b服务的部署及B P M (业务流程管理) 的实现会由第三方软件实现, 因此服务器端的重构将着重于两点, 一是如何将现有模块以服务为单位来归纳总结, 并以适当的W e b服务形式发布, 二是如何将现有的程序映射成W e b服务中的流程。

　　首先需要根据W e b服务的概念组成来决定模块的划分和W e b服务粒度的大小。Web服务包含一组基于标准化XML消息、通过网络访问的操作。如果W e b服务可以理解为J 2 E E中的一个功能模块入口 (即s e r v l e t) , 那么一系列的操作就是该功能模块中的诸多方法 (即servlet中的公有方法) 。例如, 对于一个数据维护的模块而言, 它所具有的操作是增、删、改、查、请求授权及授权。在J 2 E E框架下, 我们会用一个servlet类来实现各个功能, 而用Web服务实现时, 这些功能会以p o r t T y p e的形式定义在W e b服务内部, 可通过配置好的SOAP、HTTP或JMS方式调用, 其输入输出参数是以Schema的形式定义的。因此在重构成W e b服务时, 我们可以重用原有的功能模块划分和方法的, 简化设计步骤。

　　其次, 根据S O A中B P M的实现机制, 将现有的j a v a A P I转化为过程。一般来说, B P M, 即过程的管理、部署发布, 通过第三方的工具实现, 例如I B M或是T I B C O公司的产品。因此设计人员需要关心的是如何将现有的逻辑用以一个个过程的形式实现, 过程之间可以互相调用。根据现有J 2 E E架构下的服务器端程序的层次结构即servlet层、service层, 数据层, 建立具有接口层、业务逻辑处理层和数据层的框架结构:接口层用于实现W e b服务的调用接口;业务逻辑层处理业务逻辑分发请求;数据层是用于实现数据获取并处理基本的数据请求。仍旧以数据维护模块中的授权功能为例, 授权功能是指当数据被输入或者修改之后, 需要由上级用户进行验证, 如果数据有效则通过, 反之则拒绝。其主要步骤是: (1) 验证该请求是否为有效请求; (2) 从数据库读取修改前后的数据; (3) 对数据进行对比分析; (4) 调用第三方W e b服务进行判定并授权。我们会根据需求自上而下地定义以下流程, 一个与W S D L有映射关系的流程入口, 一个业务处理的主流程用于管理若干子流程的走向, 四个子流程分别实现业务逻辑的四步, 两个数据层的流程用于实现从数据库获取新老数据和调用外部接口获取授权信息。