网络工程毕业设计论文外文翻译-一个基于组件和推技术体系的ajax应用

网络工程毕业设计论文外文翻译-一个基于组件和推技术体系的ajax应用内容摘要：

虽然这种 限制可以提高可扩展性，但对于权衡网络性能和用户的交互性来说，更重要的是设计一个 AJAX 架构。 是以缓存为基础，同时促进 AJAX 的实时数据检索。 ，每一个反应必须立即产生，每个请求只能产生一个响应（ Khare 和 Taylor， 2020 年）。 Comet 需要一个使数据从服务器到客户端推动的模式。 这些不匹配的条件呼吁制定新的架构风格来满足所需的属性。 表 1： REST 提供的机制和 Ajax 所需应用的对比 4 架构属性 一个软件体系结构的架构性质包括系统中获得的功能 特性和非功能特性，功能特性通常被称为质量属性（ Bass 等， 2020 年。 Offutt， 2020 年）。 因为构架一个系统需要一个必要的理解，所以这些属性也可以作为一些要求。 下面，我们讨论了一些有关 AJAX 本质的架构属性。 其他属性，如可扩展性和安全性，可能是任何系统所需要的，但都没有直接采用 AJAX 技术去影响决定，所以不考虑在内。 请注意，下面讨论的性质是有相互关联的：例如，用户交互性影响用户感知延迟，而这又同时影响了网络性能。 用户交互性 在人机交互学上的定义是在某种程度上通信过程的参与者可以控制的交互性 ，并存在相互交流的话语角色。 用户的交互性是密切相关的可用性（ Folmer， 2020 年），这个词是在文献中使用的软件架构。 张志贤等（ 2020 年）提供了用户交互性并在一个商业网络应用上进行深入研究。 他们的研究结果表明，交互程度的增加对用户的感知满意度，效能，效率，价值和对一个网站的整体态度事有正面影响的。 改善这种网络上的特性已成为 AJAX 进步的主要动力。 用户感知延迟 用户感知延迟是指用户发出请求和从系统响应的第一个迹象之间的时期。 一般来说，有两种主要方式来改善用户感知性能。 首先，通过减少往返时 间，时间定为消息从浏览器传到服务器，然后再返回，第二，允许用户与系统进行异步交互。 这是所有带客户端的分布式应用中的一个重要特性。 网络性能 网络性能受吞吐量的影响，吞吐量即在网络和带宽上数据传输的速率，即最高可传输的数据吞吐量，是一个度量衡。 网络性能可以通过减少传输数据的数量和粒度来提升。 简易性 简易或发展工作是指需要去了解，设计，实施，保持和发展一个 Web 应用工作。 这是影响任何一个新方法使用和接受的重要因素。 可伸缩性 在分布式环境中的可扩展性是由一个系统 对越来越多组件处理能力的程度决定的。 在网络工程中，系统的可扩展性是确定的，例如，客户可以被不同的服务器服务而不影响结果的程度。 可伸缩的 Web 体系结构可以轻松配置，以服务越来越多的客户要求。 可移植性 可在不同环境中使用的软件被称为是可移植的。 在网络上，能够使用 Web 浏览器而不需要用户的任何额外操作，例如，下载插件导致产生了可移植的特性。 可见度 可见性（ Fielding， 2020 年）是由外部调解员理解两部分相互作用的程度决定的，即调解员越容易理解其相互作用，两个组件之间的互动就越明显。 从当前 AJAX框架的实行来看，可见度在客户端服务器中的相互作用较低，因为它们是以各自的协议为基础的。 虽然高层次的可见度使互动更被理解，但相应的高观测性也会对安全问题产生负面影响。 因此，低可见度不是本身的劣势特点，而是依赖于特性与权衡所构成的期望的系统。 可靠性 可靠性是指正确服务的连续性（ Avizienis 等， 2020 年）。 任何软件系统的成功 很大程度上取决于它的可靠性。 在互联网上，依赖于不可靠软件和恶劣工作的网络应用，就会失去客户（ Offutt， 2020 年）。 测试（测试自动化，单位测试和 回归测试）资源可以提高一个应用程序的可靠性水平。 但是，跟传统的桌面应用程序相比， Web应用通常没有作出很好的测试。 除了短时间内对市场的压力，多页互动式网页也使其很难检验。 采用单页基于组件的 Web 应用开发方式可以提高系统的可测试性和结果的可靠性。 数据一致性 网络数据对实时事件通知的一个重要方面是对数据一致性的修复，这些数据在事件发生时就要尽快地告知用户，如股票价格（ Bhide 等， 2020 年）。 如果服务器上的数据和客户端是同步的，那么这个数据就被定义为是一致的。 在坚持 HTTP 协议的 Web应用中，客户端 需要频繁地拉基于预定间隔的数据。 相比之下，采用推性能的服务器维护了客户的有关资料，并且当发生变化时把其通知给用户。 这两种技术在取得的数据一致性方面有不同的属性（ Bozdag 等， 2020 年）。 适应性 适应性是指便于系统或该系统部件适应不断变化的环境的特性。 在 Web 应用中，一个允许在服务器上变化的架构被传播到客户端即称为适应性。 我们用代码的动态概念（ Fuggetta 等， 1998 年）来比较不同 AJAX 架构行为方面的变性和适应性。 移动代码，一般来说，是软件代码，它从远程服务器获得，通过网络传输， 然后下载并执行在未明确安装或由收件人执行的客户端上。 5 SPIAR 的建筑原理 根据 Fielding， Perry 和 Wolf， SPAIR 的建筑原理主要分成三类，即数据处理（组件），数据和连接组件。 关于组件的概貌在图 1 中展现。 在这一章节，我们对组件进行解释，而在下一章节，我们将讨论他们之间的相互影响。 图 1：一个基于 SPIAR架构方式的处理 处理组件 处理元素是那些在数据元素上提供转换处理的组件。 客户浏览器提供一系列标准支持，如超文本传送协议，超文本制标语言，层叠网络文稿， JAVA 描述语言以及文档对象模型。 通过对代表性模型的网页进行处理产生用户界面。 用户交互可以建立在一个独立的用户界面模型上。 所有的视觉渐变及效果都通过这个界面展现给用户。 就像桌面客户应用程序，它由一个独立并带有别的部件的主要页面组成。 这些部件的性质可被独立操作，而不要求刷新页面去改变。 AJAX 系统是一个客户系统，它在客户浏览器中装入运行。 网络应用及运行不需要插件程序。 然而，下载系统要向用户产生初始等待时间，这将由更小的数据传送来补偿。 此系统负责代表性模型的初始化和操作。 从图 1 可以看出，系统通过用户处理事件的初始 化响应，与服务器进行通信以及执行客户端数据处理。 服务器应用程序依附于服务器，通过接受来自网络的 HTTP 响应请求进行运作，向请求者提供应答。 所有的服务器端功能依附在服务器应用程序数据处理组件上。 服务供应商代表服务器的逻辑引擎处理状态变化及用户请求动作。 它可以存储任意需要执行动作的资源（比如数据库，网络服务）。 服务供应商的功能是由事件监听器调用，由组件附属，通过引用请求初始的 Delta 编码 /编码程序输出 /输入 Delta信息。 基于这一点，用户与服务器之间的通信协议被定义和隐藏在一个接口上。 此组件支持用户与服务 器之间的 Delta 通信，这个服务器提高了用户觉察的等待时间以及网络性能。 UI 组件由一系列服务器端的 UI 组件构成。 这个在服务器上的组件模型可以着色用户的代表性模型。 每个服务器端组件包含了数据以及部分依附于客户端部件的性能，此部件与状态变化相关；何时及怎样着色客户端的 UI 密码有不同的途径。 比如，GWT 着色整个来自服务器端 Java 组件的客户端 UI 密码编译时间。 在另一方面，拥有一个真实基于组件的架构命令着色在运行时间的组件，并保持同在客户端和服务器端的组件。 这些 UI 组件有事件接听项，这些事件接听项可以依附于客户端 用户初始事件，比如点击按钮。 这个组件通过提供位物变数组件而建立网络应用系统来提高单一性。 服务器依附于一个在服务器应用系统上的独立模块。 此数据处理组件有能力开启从服务器到用户的数据入栈的 HTTP 连接。 服务器供应商可以发布给此组件新的数据（状态改变）。 推送客户组件依附于客户端内。 它可以是一个独立的模块或是 AJAX引擎的一部分。 此组件可以描述为在推送服务器组件上一个特别的通道，接收来自服务器发布的实时数据。 数据组件 数据组件包含通过由数据处理组件使用和转换的信息。 表征组件包括任意媒体形式，比如 REST。 HTML、 CSS 以及图象都是这个数据组件的组成部分。 代表性模块是一个运行时间的抽象性，它表明 UI 怎样在客户端浏览器上显现。 浏览器内的文档对象模型在 AJAX 应用系统中有着非常重要的作用。 它主要通过操作这个代表性模块产生丰富的效果。 一些构架比如 Backbase， 运用特别域语言来定义结构及代表性模块的性能。 其他像 GWT 则用一个直接的途径，即运用 JAVA 描述语言。 Delta 通信信息形成了客户及服务器之间的 Delta 通信协议方式。 SPIAR 对客户端 Delta 数据和服务器端 Delta 数据作了区别。 前者由客户创 造，代表客户端状态改变的相应命令引起这些变化，而后者响应是在服务器组件上命令的结果。 此 Delta通信的数据建立在各种当前的格式上，比如 XML。 JavaScript Object Notation 或者完全的 Java 描述语言。 客户端 Delta 消息包含了服务器所需的信息，例如知道这些行动必须执行的组成部分。 作为一个例子，图 2 显示了在 Echo2 中的 Delta 通信。 用户点击一个组件（按钮ID 为 c_7）后，客户端引擎检测并将它传到服务器端，显示在图 2 的 REQUEST 块中。 然后服务器使用在 Delta 的客户端信息，响应一 个服务器端 XML 格式的 Delta。 在这种情况下，是由行动，组件 ID 和事件类型组成的。 可以看出， Delta 服务器告诉客户端引擎到底如何与新的风格和文字内容，特别是与 ID c_35_content 的父组件来更新 DOM 状态。 图 2： Echo2中 Delta 通信的一个例子 我们区分三种代码，可以改变客户端的状态：表象代码，功能代码和文本数据。 表象代码顾名思义是对视觉风格和应用演示方面有影响，例如， CSS 或 HTML 格式。 文本数据是单纯的数据。 功能代码可以执行在客户端，例如， JavaScript 代码，或 XML 格式的命令（例如，在图 2 中的 DOM 添加）。 Delta 服务器可以组成任意这些三种类型的代码。 这三种类型的代码可以影响到客户端的应用代表性模型（ DOM），它是运行时代码的表象抽象，被执行的功能代码和文本数据的结合。 GWT 使用 Delta 服务器主要是由文本数据组成的 RPC 样式的服务，而在 Backbase公司和 Echo2 中一个基于组件的方法实施调用事件监听器，是混合在一个表象和功能的代码中的。 连接组件 连接元素作为粘合剂，担当了使它们能够结合起来的作用。 时间构成了在 SPIAR 中交互模型的基础。 一个事件是由每个发起的对接口传播到用户操作的引擎。 根据事件的种类，一个请求到服务器，或一次接口的部分更新都是可能需要的。 如果需要，该事件可以异步处理，在这种情况下，控制立即返回给用户。 在服务器上，会请求由事件发起调用的服务。 这项服务可以直接或通过调用相应的用户界面组件的事件监听器来实现。 Delta 连接器是轻量级的，用通信媒体连接引擎和服务器使用请求 /响应机制来结束 HTTP。 Delta 更新用于更新客户端和组件模型在服务器上的代表性模式，以反映状态的变化。 当一个代表性模式的增量更新在直接 的用户界面并且有一个直接明显的结果，那么说明一个组件模型的更新引起了适当的听众。 这些更新通常是通过程序调用的方法实现的。 渠道是在基于推的消费者和生产商之间连接的元素。 一个消费者（接收器）订阅了一个渠道，通过握手的程序，并接收任何由生产者（信息来源）从 Delta 推动服务器通道发送的信息。 6 架构观点 由于加工，数据和连接的因素，我们可以使用不同的架构观点来描述元素，形成一个共同的结构。 在这里，我们利用两个处理意见，在某些方面集中数据流和与各方面的数据处理单元连接（ Fielding， 2020 年）。 这种观点适 合在组件和连接器视图类型中讨论，（ Clements 等 ,2020 年）。 我们谈论一个对基于组件的 AJAX 解决方案的处理意见，一个是一种基于 RPC 的 AJAX 应用，一个是查看基于推的变形。 AJAX 方式 图 1 描述了一个以 SPIAR 为基础的处理方式，在体系结构上翻译了运行时的组件，例如， Echo2。 该视图显示了一些在最初的页面请求中组件相互作用的时间（引擎是在客户端上运行）。 用户接口关闭一个事件上的用户活动，表示了某种组件定义的行动是授权给AJAX 引擎的。 如果在服务器侦听端上的组件已注册到事件本身，发 动机会作出 Delta的相应事件来改变当前状态的客户端邮件，并将其发送到服务器。 在服务器上，解码器将转换信息，确定并通知组件树中有关的组成部分。 更改后的组件最终将调用服务提供者的事件监听器。 服务供应商处理之后的行动，将更新的对应组件由编码器回报到新的状态。 之后，呈现的增量服务邮件，送回到将用于更新的代表性模型，并最终显示在接口。 如果服务器还是没有需要，引擎也有直接在事件以后更新代表模型往返的能力。 在运行时处理的 GWT 框架图描述如图 3。 可以看出， GWT 不维护服务器端的组件树。 相反，服务器端。