本文从网络应用的结构分析了C/S和WEB应用的特征以及各自的优势和限制;讲述了WEB应用中数据处理过程;还讲述了WEB应用中各部分的功能划分;最后详尽分析了应用从C /S向WEB平台移植的步骤。
从90年代开始,客户机/服务器(Client/Server,以下简称为C/S)结构代替了原来的主机/终端(Host/Terminal)结构,并且在整个IT发展中发挥了巨大的作用。但随着Interne t的不断普及和应用的迅速升级,C/S的应用感到有些力不从心。
一、C/S结构的限制
网络应用绝大部分都可分为以下四个层次:表现层、事务层、数据逻辑层和数据存储层。在C/S结构中,表现层和事务层都放在客户端,而数据逻辑层和数据存储层则置于服务器端。这种组织安排带来诸多的限制:
1、客户端很庞大,以致于应用程序升级和维护时十分困难且耗资很大;
2、事务层不能与跨平台的客户端共享;
3、孤立了不同的逻辑组件;
4、没有统一的数据逻辑层来提供不同种类的数据存储层;
5、C/S组织结构不支持Internet。
做过C/S结构下的MIS开发和维护的人们对第1点体会颇深:对应用程序一个小小的改动,就必须通知或亲临每一个客户端去更新;新增或升级一台机器,都要把应用及其相关的文件安装在客户端上。如果整个系统有成千上万个客户端,可以想象维护的工作量有多大。 二、Web应用的解决方案
Web平台是一个调度任务集中的、以客户为中心的应用程序平台;它是一个分布式、开放、适用性强、高性能、端到端的平台;它使企业利用技术获取竞争优势。
1. 分布式
C/S技术的出现,给系统集成方案带来了集中的信息和本地的PC环境,但其数据的共享程度是很不够的,大家可以想想,在C/S应用中,有多少人能够得到你想发布的信息。当今的信息技术需要新的解决方案,它提供以客户为中心的用户界面和Web的分布结构,它带有IT环境的个人特征,如数据存取、安全性能等,这就是我们通常所说的三层结构。
2. Web结构的优势
在Web结构中,事务层和数据逻辑层放在中间组件层,这是关键,是与C/S结构的最大区别,它能解决以下几个问题:
(1) 客户端很瘦小,并且很容易在运行时自动升级;
(2) 事务层可在跨平台的客户端上共享;
(3) 不同逻辑组件的分离意味着图形设计人员、事务逻辑开发人员和数据库分析人员可以独立地设计他们各自的部分;
(4) 统一的、抽象的用户界面可使用户更有效地从同一数据源中存取数据;
(5) 这种结构可更有效地在企业内部网、国际互联网和外联网上运行。
中间组件层充当一个服务器,这就是通常所说的应用服务器。
3. 开放性
Web是一个开放的环境,应用由复用组件集成,通过标准语言汇编、跨平台的统一协议发布,用标准用户界面显示,它与硬件平台和操作系统无关。现在有三种组件模型:Activ eX、JavaBeans和CORBA,每一种模型有它自己的通信协议:ActiveX用COM和DCOM,JavaBea ns和CORBA用ⅡOP。但并不是每一种浏览器都支持动态的HTML,Java脚本的扩充至少支持三种模型:Active Server、LiveWire和PowerDynamo。
4. 适应性
一个可适应的开发环境是非常重要的,采用应用服务器的目的在于它支持多种组件模型,但在客户端和数据库服务器端需要有更强的适应性。
随着Web技术的介入,用户界面设计已发生了巨大的变化,因为在站点上,并没有类似迷惑用户的东西或用户手册。一个成功的站点应首先吸引用户,而后留住用户。而引入新的、面向图形化的和直觉的用户界面标准,就允许最终用户可以直接与它们交流。
三、Web结构中各部分的分工
1. Web发布部分
如上图,Web服务器仅仅是把要显示的内容从站点上以文件的形式读取,然后以静态的HTML格式送到客户端的浏览器;也可以Applet增强表现能力,但它仅仅是利用 ActiveX或JavaBeans通过页面或组件,并没有通过任何事务数据服务器。
2. Web数据处理部分
Web数据处理增强了标准Web站点存取数据的能力,包括许多数据类型。我们可根据数据的存取容量把数据分成两大组类:标准的在线事务处理(OLTP)程序将花费大量时间去检索和操作核心在线数据,这种数据需要连续读取和回写。而另一种辅助数据是只读的,如帮助文件、用户信息和文档等。Web数据处理主要集中在辅助数据,而Web OLTP主要集中在核心在线数据。
3. 客户端
客户端是表现逻辑层,执行含有各种扩展的HTML(包括动态HTML)页面,这些扩展既来自浏览器,也来自可视化JavaBeans和ActiveX组件。在任何情况下,我们至少需要一个HT ML页面,由此HTTP可从服务器端传至客户端,应用程序的其它部分可以是一个整体。因为大部分的Web应用都是为Internet编写的,对专业的IT应用而言,Web是一个成功的平台,用户可以在断开连接后继续工作,这就意味着远程象本地一样可存取事务和逻辑数据。这样不仅要分发应用程序,而且还要分发数据。
4. 应用和数据服务器端
Web结构中的剩余部分就是完成应用程序如何与数据协同工作。数据可分成两大类:事务逻辑和数据逻辑。数据逻辑驻在数据服务器中,而事务逻辑则置于应用服务器中。事务逻辑又可分为两类:事务组件和应用服务,事务组件定义了事务及其操作,而应用服务则是提供一般应用性能的组件,如菜单管理、主从数据格式等。
前面我们已介绍了Web发布、Web数据处理和Web OLTP。事实上,在一个完整的应用中,这三种方式往往同时存在。例如,对不存取任何数据的Web页面,传统的Web方法是很好的,由Web服务器从文件系统中读取页面,然后送给客户端。
四、移植的步骤 当我们确定移植顺序时,牢记以下几个因素:第一、要知道你能承受多大风险,由此决定每一步你做多大的修改;第二、尽管我们关注配置环境本身,但开发环境很关键,一个完整的Web解决方案应包括这两部分。下面详述从C/S移植到Web平台的五个步骤:
1. 为事务逻辑选定开发平台
首先,要为事务逻辑的开发及客户端与应用服务器间的通信选定组件模型,然后决定采用何种应用服务器来实现事务逻辑。对于事务逻辑,页面服务器是最简单的选择,但它是否采用动态数据对象(Active Da ta bjects,简称ADO)或JavaBeans,或两者都采用,这将取决于很多因素,如当前配置、开发工具和平台限制等。通常采用关联组件的通信模型,但并不需要选择支持多种组件的应用服务器,比较典型的是包含两类服务器:一类是基于HTTP的页面服务器,用来处理Web数据流程;而另一类则是事务服务器,用来处理Web在线事务处理(OLTP)。
如果当前是两层结构,为第三代语言开发环境,则不必考虑遗留的事务逻辑,因为当前并没有应用服务器;但若是两层结构、第四代语言开发的应用程序,则可利用它自身的应用服务器和事务逻辑扩展为三层结构的应用。PowerBuilder及其不可视对象提供了一个很好的开发环境。现存的三层结构应用,无论是第三代或第四代应用都有应用服务器的形式,你可选用旧服务器,也可转到新的服务器。
2. 为表现逻辑选定开发平台
选择客户端的开发环境要求比较谨慎,因为带宽和功能间的协调在不同应用之间差异很大。无论如何,要选择可视化的组件和你所期望能支持的浏览器,若两种浏览器都要求支持,则需要自己编写一些通用的程序。对于应用服务器,ActiveX和JavaBeans之间的选择完全取决于开发经验、策略以及市场上可用的组件。
关心当前应用程序,就象关心表现逻辑一样,看它是两层结构还是三层结构,尽管两层结构的应用是肥客户端,必须分开,但真正的技术却不需要改变。仅需要至少一个HTML来启动页面,重新配置表现逻辑,并允许HTTP机制存取它。
3. 选定开发环境
选择好的开发环境是移植至Web平台的关键,因为开发工具有助于开发进程。可以选择符合工业标准的组件模型,它将为你生成事务逻辑,然后不必修改源程序而生成这些组件。有些工具可生成多样的表现层次,如 JavaScript、Java或ActiveX组件等。
在此描述的开发环境是第四代语言的范围,这类工具可在统一的、集成的环境中创建一个完整的应用,所有的表现和事务逻辑都用同一种语言来编写。在配置阶段,根据运行平台生成不同的组件和语言模型。
4. 统一并构建事务逻辑
在此必须有一个关于开发和配置环境的详细图表,重新规划现有的编码。可以先忽略改变语言和组件模型的细节,而仅重视逻辑本身。从事务逻辑中分离表现逻辑,然后在把事务逻辑从应用服务器中分离出来。一旦定义好事务逻辑,就可配置应用服务器。组织事务逻辑有两种比较好的方法:从数据模型或客户端应用中提取逻辑。有些数据逻辑存放在当前的应用中,所以要把它当成组件重新生成。
5.为Web应用重新配置表现逻辑
必须重新配置表现逻辑才能适应浏览器环境,这一过程相当严格,因为浏览器环境把客户端组件送至用户,有许多可选方案。如果开发环境支持一般的技术,而又想在这种技术下使用最好的策略,例如PowerBuilder支持由数据窗(DataWindow)生成HTML,但又计划将来生成更完整的应用程序,在这种情况下,符合Java的数据窗是可以考虑的。
当表现逻辑改成Web环境时,需要开发一些新的组件。如果没有生成任何新的页面,则C/S应用与Web应用的用户界面可以完全一样。
文章来源于领测软件测试网 https://www.ltesting.net/
