[
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应用的用户界面可以完全一样。
[本文共有 2 页，当前是第 2 页] <<上一页 下一页>>
]
您的位置：
