|
Web
应用程序构架
Web
应用程序的基本构架包括浏览器、一个网络和一个
Web 服务器。浏览器向服务器请求"Web 页"。每一页都是内容和以
HTML
表达的格式指令的组合。一些页包括客户端脚本，它们由浏览器解释。这些脚本为显示的页定义了其他动态行为，而且它们经常与浏览器、页内容和页中包含的其他控件（Applet、ActiveX
控件和插件）交互。用户查看页中的内容，并与其交互。有时，用户在页的字段元素中输入信息，并提交给服务器处理。用户还可以通过超链接导航到系统的其他页，与系统进行交互。无论是哪种情况，用户都在向系统提供输入，这样就可能改变系统?quot;业务状态"。
从客户端来看，Web 页总是一个采用 HTML
格式的文档。然而在服务器端，"Web 页"可表现为多种形式。在最早的
Web 应用程序中，动态 Web 页用公共网关接口 (CGI)
构建。CGI
定义了一个供脚本和已编译模块使用的接口，它们通过该接口访问与页请求一起传递的信息。在基于
CGI 的系统中，通常在 Web
服务器上配置一个特殊的目录，以便针对页请求来执行脚本。在请求
CGI 脚本时，服务器会用解译器（通常是一个 PERL
shell）处理或执行相应的文件，以流的形式将输出返回给发出请求的客户机，而不仅仅是返回文件内容（就像处理
HTML 格式的文件时一样）。处理的最终结果是 HTML
格式的流，它会被返回给发出请求的客户机。业务逻辑在处理文件的同时在系统中执行。在这段时间内，它能够与服务器端资源（如数据库和中间层构件）交互。
目前的 Web
服务器已经在这个基本设计上有所改进。它们现在已非常注重安全性，而且包含了一些特性：如在服务器端的客户机状态管理、事务处理集成、远程管理、资源共享等，这里只列举了其中的几种。总的来说，最新一代
Web
服务器处理的都是那些对构架设计师来说非常重要的问题，它们关系到任务至上、可缩放和强壮的应用程序。
根据 CGI 脚本的作用，可以将现今的 Web
服务器分为三大类：脚本页、编译页，以及两者的混合体。在第一类中，客户机浏览器能请求的每一个
Web 页在 Web
服务器的文件系统中都用一个脚本文件来表示。这个文件一般是
HTML 和其他一些脚本语言的混合。对页发出请求后，Web
服务器委派一个可识别该页的引擎对其进行处理，最终结果以格式为
HTML 的流的形式返回给发出请求的客户机。Microsoft
的 Active Server Pages、Java Server Pages 和 Cold Fusion
都属于这一类。
在第二类中，Web
服务器加载并执行一个二进制构件。这个构件和脚本页一样，有权访问与页请求一起发送的所有信息（表单字段值和参数）。经过编译的代码利用请求的详细信息，并通常要访问服务器端的资源，以生成
HTML
流并返回给客户机。编译页包含的功能往往比脚本页大，尽管并未明确这一规律。通过向编译页请求传递不同的参数，可获得不同的功能。任何一个编译构件实际都可以包含整个目录脚本页的所有功能。Microsoft
的 ISAPI 和 Netscape 的 NSAPI
就是表示这种构架类型的技术。
第三类指的是那些一旦发出请求即进行编译的脚本页，以后的所有请求都使用编译过的页。
Web 页建模
Web
页，不管是脚本页还是编译页，都一对一地映射到
UML 中的构件。构件是系统的"物理"可更换部件。模型的实施视图（构件视图）描述了系统的构件及它们之间的关系。在
Web 应用程序中，这个视图描述了系统的所有 Web
页及它们彼此之间的关系（如超链接）。在一定程度上，Web
系统的构件图就相当于站点图。
由于构件仅仅代表了接口的物理打包方式，它们并不适用于对页内部的协作关系建模。这一抽象级别仍需要成为模型的组成部分，而且对设计员和实施员而言极其重要。为引入正题，我们可以说每个Web
页在模型的设计视图（逻辑视图）中都是一个UML类，它与其他页的关系（关联关系）即代表了超链接。但如果考虑到任何
Web页都可能既代表一组只存在于服务器上的功能和协作，同时又代表只存在于客户机上的一组完全不同的功能和协作，那么这种抽象就不成立了。举例来说，使用动态HTML（客户端脚本）作为部分输出的所有服务器
Web脚本页都是这样的页。对这个问题的直接反应可能就是为类中的每个属性或操作设计原型，指明它是在服务器端还是在客户端有效。至此，运用模型倒让问题变得复杂了，而我们的初衷是要简化问题。
一个更好的解决方案是"分别考虑"。从逻辑上讲，服务器端的
Web
页行为与客户端是完全不同的。在服务器上执行时，页有权访问服务器端资源（中间层构件、数据库、文件系统等），即与这些资源具有某些关系。同一页（或者是该页的
HTML
流输出）在客户端有完全不同的行为和关系集。在客户端，脚本页与浏览器本身（通过文档对象模型，即
DOM），以及该页指定的所有 Java Applet、ActiveX
控件或插件相关。对于认真的设计员而言，页还可能与客户机上在另一个
HTML 框架或浏览器实例出现的其他“活动”页相关。
通过分别考虑，我们就可以用一个类为 Web
页的服务器端建模，用另一个类为客户端建模。我们采用
UML 扩展机制为两者分别定义构造型和图标“server
page” 和“client page”，以此来区分两者。UML
中的构造型允许我们为建模元素定义新的语义。已指定构造型的类在
UML 图中可用定制图标表示，或者仅仅用 ("")之间的构造型名称说明。图标对概述图很有用，在概述图中，最好使用简单的标记对显示出的类属性和操作进行标注。
对于 Web 页，构造型指出了类是客户机或服务器上
Web
页逻辑行为的抽象。两种抽象通过两者之间的定向关系相互关联关系。这种关联关系的构造型为："build"，因为可以说服务器页构建了客户机页（图
1）。每个动态 Web
页（即页内容在运行时才能决定的页）都用一个服务器页构建。每个客户机页至多只能用一个服务器页构建，而一个服务器页可以构建多个客户机页。
图 1. 服务器页构建客户机页
Web页之间通过超链接建立公共关系。Web应用程序中的超链接代表系统的一条导航路径。这种关系在模型中用一个构造型为“link”的关联关系表示。关联关系总是从客户机页出发，指向另一个客户机页或服务器页。
上一页 下一页 |