web服务架构（web应用广泛使用的是客户端服务器架构对吗）

本文目录

• web应用广泛使用的是客户端服务器架构对吗
• web架构中Session管理方法的优缺点
• 详细讲述SOA的发展历史与标准规范
• web的工作架构是什么
• 简述WEB系统的架构原理
• 什么是web服务体系结构web服务体系结构具有哪些特征

web应用广泛使用的是客户端服务器架构对吗

是。web应用广泛使用的是客户端。客户端是一个与服务器通信的软件,一些广泛使用的Web客户端是Firefox,Safari等浏览器,当要从服务器(通过URL)请求东西的时候,Web客户端负责创建一个请求并发送给服务器,然后解析服务器响应展示给用户。

web架构中Session管理方法的优缺点

做web开发的同学应该对session再熟悉不过，它是服务器分配给客户端的会话标识，浏览器每次请求会带上这个标识来告诉服务器我是谁，服务器会在内存中存储这些不同的会话信息，由此来分辨请求来自哪个会话。在单机部署的环境总，因为web服务器和session都是在同一台机器上，所以必然能找到对应的会话数据。但如果有2台web服务器(A和B)提供服务，假如第一次请求落到A上并创建了session，那么如何保证下次落到B的请求能读到session数据?

解决方案

有以下4中常见的解决方案。

1、SessionSticky

这是最简单粗暴的方法，核心思路就是让同一会话的请求都落地到同一台服务器上，这样处理起来就和单机一样了，我们可以在负载均衡上做一些身份识别并控制转发来达到这个目的。这样做的优势是能像单机一样简化对session处理，也方便做本地缓存，但缺点也是很明显的：

如果这台服务器宕机或重启了，那么所以的会话数据都会丢失，失去了分布式集群带来的高可用特性。

增加了负载均衡器的负担，使它变得有状态了，而且资源消耗会更大，容易成为性能瓶颈。

2、SessionReplication

顾名思义，这是一种session复制的方案，核心思路就是通过在服务器之间增加session同步机制来保证数据一致。

看起来比第一种简单了很多，也没有第一种带来的缺陷，但在某些应用场景下还是会有比较严重的问题：

服务器之间的数据同步带来了额外的网络消耗，随着机器数量和数据量的上升，网络带宽将会有很大的压力，也必然会带来延时问题。

每台服务器上都要存储所有的会话数据，如果会话数量很大会占用服务器大部分内存空间。

目前很多应用容器都支持这种同步方式，所以在集群规模和数据量比较小的时候还是一种很好的解决方案。

3、Session集中存储

这种方式的思路就是把所有的会话数据统一存储和管理，所有应用服务器需要对session进行读写都要通过session服务器来操作：

这种方案的好处是独立了session的管理，职责单一化，session服务器采用什么方式存储(内存、数据库、文档、NoSql等等)，什么方式对外提供服务都是透明的。不会给应用系统和负载均衡带来额外的开销，不需要进行数据同步就能保证一致性，看起来应该是非常完美了，不过也有自己的一些小缺陷：

对session读写需要网络操作，相比较session直接存储在web服务器的时候增加了时延和不稳定性，好在session服务器和web服务器一般是部署在局域网中，可以最大化减少这个问题。

session服务器出现问题将影响所有web服务，如果采用多机部署同时也会带来数据一致性问题。

每种方案带有它独特的优势，同时也会带来相应的新问题，正所谓没有十全十美，只有适合才是最好的。总体来说，这种方案在应用服务器和会话数据量都很大的时候还是非常有优势的。

4、CookieBase

这种方案是基于cookie的传输来实现的，核心思想很简单，就是把完整的会话数据经过处理后写入到客户端cookie，以后客户端每次请求都带上这个cookie，然后服务端通过解析cookie数据来获取会话信息。

这种方案简单明了，也没有前面几种方案带来的问题，但劣势也非常明显：

首先通过cookie来传递关键数据肯定是不安全的，即便是采用了特殊的加密手段。

如果客户端禁用了cookie，将直接导致服务不可用。

cookie的数据是有大小限制的，如果传递的数据超出限制大小，将会导致数据异常。

***隐藏网址***

详细讲述SOA的发展历史与标准规范

        1. soa发展回顾

    soa的概念最初由gartner公司提出，由于当时的技术水平和市场环境尚不具备真正实施soa的条件，因此当时soa并未引起人们的广泛关注，soa在当时沉寂了一段时间。伴随着互联网的浪潮，越来越多的企业将业务转移到互联网领域，带动了电子商务的蓬勃发展。为了能够将公司的业务打包成独立的、具有很强伸缩性的基于互联网的服务，人们提出了web服务的概念，这可以说是soa的发端。

    web服务开始流行以后，互联网迅速出现了大量的基于不同平台和语言开发的web服务组件。为了能够有效地对这些为数众多的组件进行管理，人们迫切需要找到一种新的面向服务的分布式web计算架构。该架构要能够使这些由不同组织开发的web服务能够相互学习和交互，保障安全以及兼顾复用性和可管理性。由此，人们重新找回面向服务的架构（service-oriented architecture，soa），并赋予其时代的特征。需求推动技术进步，正是这种强烈的市场需求，使得soa再次成为人们关注的焦点。回顾soa发展历程，我们把其大致分为了三个阶段。下面将分别介绍每个阶段的重要标准和规范。

    1.1 孕育阶段

    这一阶段以xml技术为标志，时间大致从上世纪九十年代末到本世纪初。虽然这段时期很少提到soa，但xml的出现无疑为soa的兴起奠定了稳固的基石。

    可扩展标记语言（extensibl markup language，xml）系w3c所创建，源自流行的标准通用标记语言（standard generalised markup language，sgml），它在上世纪60年代后期就已存在。这种广泛使用的元语言，允许组织定义文档的元数据，实现企业内部和企业之间的电子数据交换。由于sgml比较复杂，实施成本很高，因此很长时间里只用于大公司之间，限制了它的推广和普及。

    通过xml，开发人员摆脱了html语言的限制，可以将任何文档转换成xml格式，然后跨越互联网协议传输。借助xml转换语言（extensible stylesheet language transformation，xslt），接受方可以很容易地解析和抽取xml的数据。这使得企业既能够将数据能够以一种统一的格式描述和交换，同时又不必负担sgml那样高的成本。事实上，xml实施成本几乎和html一样。

    xml是soa的基石。xml规定了服务之间以及服务内部数据交换的格式和结构。xsd schemas 保障了消息数据的完整性和有效性，而xslt使得不同的数据表达能沟通过schema映射而互相通信。

    1.2 发轫之初

    2000年以后，人们普遍认识到基于公共——专有互联网之上的电子商务具有极大的发展潜力，因此需要创建一套全新的基于互联网的开放通信框架，以满足企业对电子商务中各分立系统之间通信的要求。于是，人们提出了web服务的概念，希望通过将企业对外服务封装为基于统一标准的web服务，实现异构系统之间的简单交互。这一时期，出现了三个著名的web服务标准和规范：

? 简单对象访问协议（simple object access protocal，soap）
? web服务描述语言（web services description language，wsdl）
? 通用服务发现和集成协议（universal discovery description and integration，uudi）

    这三个标准可谓web服务三剑客，极大地推动了web服务的普及和发展。短短几年之间，互联网上出现了大量的web服务，越来越多的网站和公司将其对外服务或业务接口封装成web服务，有力地推动了电子商务和互联网的发展。web服务也是互联网web 2.0时代的一项重要特征。

    1.3 成长阶段

    从2005年开始，soa推广和普及工作开始加速。不仅专家学者，几乎所有关心软件
行业发展的人士都开始把目光投向soa。一时间，soa频频出现在各种技术媒体、新产品发布会和技术交流会上。

    各大厂商也逐渐放弃成见，通过建立厂商间的协作组织共同努力制定中立的soa标准。这一努力最重要的成果体现在3个重量级规范上：sca/sdo/ws-policy。sca和sdo构成了soa编程模型的基础，而ws-policy建立了soa组件之间安全交互的规范。这三个规范的发布，标志着soa进入了实施阶段。

    从整体架构角度看，人们已经把关注点从简单的web服务拓展到面向服务体系架构的各个方面，包括安全、业务流程和事务处理等。 
     2. 标准与规范

    2.1 标准与规范的区别

    大多数人习惯上把“标准”与“规范”这两个术语交替使用，这样做基本没有问题。但严格地讲，二者还是有一定差异的。规范是标准的建议文档。这就意味着，标准一般是由业界公认的标准化组织制定和发布。而规范要灵活的多，多为厂商或非标准化组织发布。事实上，很多规范并不是标准，比如sdo和sca，而是由某些厂商或厂商联盟制定发布。但是凭借这些厂商强大的市场地位，这些规范往往会成为事实上的标准。

    我们大体上可以把soa标准分为xml标准集、web服务标准集和soa参考模型，下面我将分别介绍，为叙述方便，不再严格区分标准和规范，统一称作标准。

    2.2 xml标准集

    2001年10月，w3c发布了xml信息集（xml information set，xml infoset）。
infoset是一个抽象的数据模型，它兼容基于文本的xml 1.0，也是所有最新xml规范（xml schema、xml query和xslt 2.0）的基础。由于web服务架构是以xml infoset为基础，而不是以某一特定的表现形式为基础，使得该架构及其核心协议组件可与各种编码技术兼容。

    除了基于纯文本的infoset编码技术以外，web服务架构还需要支持另外一种编码技术——即允许不透明的二进制数据与传统的基于文本的标记交织在一起。由于xml infoset仅支持基于文本的xml，w3c于2005年初发布了xml二进制优化封装协议（xml-binary optimized packaging，xop）。xop格式使用mime将原始二进制数据引入到xml 1.0文档中，而不采用base64编码。通过其配套规范——soap 消息（transmission optimization method，mtom）实现将二进制xop格式绑定到soap。xop和mtom是将原始二进制数据与基于文本的xml混合在一起的首选方法，它们取代了目前普遍遭到反对的soap with attachments（swa）和ws-attachments/dime。

    2.3 web服务标准集

    经过几年的努力，web服务标准集已经初具规模，内容涵盖传输层、消息机制、编程模型、服务发现和描述、可靠性、事务处理、安全和管理等方面。尽管其中部分内容还处于规范级别，但由于受到广泛的关注和支持，成为正式标准只是时间上的问题。

        2.4 soa参考模型

    soa参考模型由结构化信息标准促进组织制定和发布。事实上，它并不是一个标准，而是soa架构的一个抽象框架，统一了soa相关术语用法并且定义了这些术语的涵义，同时还明确定义了soa各组件之间的关系。soa架构师或系统设计人员可以根据这个模型指导自己的soa实践，下图说明了soa参考模型与soa实践之间的关系。

        从上图可以看出，参考模型位于抽象级别的顶部，也就是说参考模型提供了soa实现的抽象基础。每个soa架构设计者都要考虑参考架构、模式、模型以及由参考架构派生出的概念架构，审慎思考实际环境（需求、动机和目标等）对实现架构的影响，同时利用已有的标准和协议，这样就形成了一个比较完整的soa设计方法论。总而言之，soa参考模型使得我们能够系统地考虑soa架构的实现，并给出最基本的概念和设计模式。

   3. 标准化组织对标准的贡献

    3.1结构化信息标准促进组织（organization for the advancement of structured information standards，oasis）

    oasis是一个非赢利的国际协会，致力于电子商务相关标准的制定和推广，也是目前制定web服务标准最多的一个组织。除了制定通用的电子商务、web服务和安全标准之外，oasis还制定了很多针对行业的电子标准。oasis理事会成员几乎全部来自微软、ibm、bea system、oracle、sun、sap ag、诺基亚等业界大公司。

    oasis为soa专门成立了六个技术委员会（technical committees），分别负责制定电子商务、web service开发和部署、服务质量以及面向服务架构等方面的标准。

    3.2 开放soa合作组织（open soa collaboration，osoa）

    osoa是一个非正式的厂商联盟，使得各厂商能够共同开发一个语言中立的编程模型。该编程模型帮助企业软件开发人员能够最大限度的发挥soa架构的特性和优势。目前加入osoa的厂商包括ibm、bea、sap、oracle等。尽管osoa不是一个标准化组织，但由于有ibm、bea等业界厂商的支持，它制定的规范很可能会成为事实上的标准。因此，我们可以把它看作一个准标准化组织。osoa成立了两个项目组，分别负责制定sca和sdo规范。

    3.3万维网联盟（world wide web consortium，w3c）

    w3c成立于1994年，主要负责制定web相关标准和规范，比如html、css等。w3c专门成立了web服务专区，下辖六个工作组，负责制定web服务相关的标准。w3c对web服务的发展可谓功不可没，像非常著名的soap和wsdl皆出自于w3c。

    3.4 web服务互操作组织（web services interoperability organization，ws-i）

    ws-i是一个开放的厂商联盟，鼓励任何对web服务有兴趣的厂商加盟并贡献自己的力量。 它主要致力于提升web服务基于平台、操作系统和编程语言中立的互操作能力，其成员几乎覆盖了所有重量级厂商，如ibm、微软、sun、oracle和bea等。

    3.5 互联网工程任务组(internet engineering task force，ietf)

    the ietf（因特网工程工作小组）是定义标准因特网操作协议（像tcp/ip）的团体，ietf接受国际互联网协会internet架构委员会（internet architecture board，iab）的监督管理。ietf的成员分别来自于互联网协会的个人或者组织成员。

     4.厂商之间的博弈

    谁控制了标准，谁就控制了游戏规则，就能够在未来的软件行业立于不败之地。因此，几乎当前所有的主要工具供应商和平台提供商都参与了soa标准的制定，包括微软、ibm、bea、oracle、sun、sap ag、诺基亚、iona、xcalia、zend 、sonic software。

    表面上，标准化组织都声称自己独立于任何厂商，强调其独立性和自主性。但如果观察这些组织理事会的成员构成，就会发现大部分成员都来自上面提到的业界寡头，来自欧美发达国家，可以说是“大国俱乐部”和“大厂俱乐部”。

    在参与制定标准的同时，各大厂还开始并购优秀的行业soa解决方案提供商，积累针对特定行业标准的实施经验，以期获取竞争优势。2006年8月，ibm宣布成功收购了一家专门提供面向行业的 soa软件与服务的私有企业——webify解决方案公司。webify公司专注于提供帮助企业加速开发和部署应用的软件产品，以及数以百计的针对特定行业的基于标准的预置加速器、工具和框架，用于解决特定行业的业务问题，如帮助医疗保健行业符合《健康保险便携性及责任性法案》（hipaa）的要求、帮助保险行业满足《国际保险业数据标准》（acord）等。此次收购将进一步增强ibm在soa领域的领导地位。 webify在语义方面的专业技术与ibm在开放标准开发利用丰富经验的结合，能够更好地解决特定垂直行业的常见业务问题。

     5.标准的发展趋势

    2007年将有三个重量级的标准问世，它们目前都属于规范级别。它们就是sca、sdo、ws-policy。sca和sdo构成了soa组件开发的核心，而ws-policy则成为soa组件间安全通讯的标准，其作用类似于安全套接层在浏览器与服务器通讯中的重用。事实上，ws-policy的基本原理与ssl是一致的。

    今后标准开发将具有一个共同的特点，就是标准与soa架构的协调性。也就是说，无论是已有的标准还是正在开发的标准，都必须符合soa架构的要求，同时要考虑单个标准与其它soa标准之间的协调一致。

    2007年将会有许多soa的规范升级为标准。sca和sdo计划于2007年由oasis审核通过，而ws-policy也将于2007年8月正式成为w3c标准。

    基于市场的强劲需求，各标准化组织将继续加大在制定soa相关标准上的投入力度，标准的制定和发布周期将大大缩短。比如对ws-policy，w3c制定了精密的时间表。目前ws-policy的发布时间表是这样安排的，2007年3月发布候选推荐版本(candidate recommendation drafts)，2007年7月发布提议推荐版本(proposed recommendation drafts)，2007年8月发布w3c推荐版本(w3c recommendations)。w3c历来以严谨和审慎著称，发布一个标准平均需要3至5年的时间。但就ws-policy而言，从2006年4月 ibm和微软公司将ws-policy规范提交给w3c算起，按照目前的时间表，整个标准发布周期仅为16个月。

web的工作架构是什么

web的工作架构：

1、浏览器的作用：用户提交请求给服务器，将服务器返回的响应解析出来

2、web服务器：接受用户请求，并给用户做出响应，Windows下有IIS，Linux下有Apache、Nginx

3、web应用：用php、jsp、asp、aspx等开发语言开发一个web应用程序（博客、购物网站等）。运行在服务器上

4、数据库：存储数据，数据库有一个接口，在应用程序中指定连接数据库的账户密码

5、中间件：举个例子，在Linux环境下，用Apache作为服务器想要运行一个Java程序，还需要Tomcat环境的支持，Tomcat就是一个中间件。目前Apache等服务器和中间件的区分越来越少，可以广泛理解为中间件是Apache、IIS、Nginx、Tomcat、Jboss的统称。

简述WEB系统的架构原理

简述WEB系统的架构原理

这个话题太大了。
一般来说，WEB系统，主要是指后端，前端就是各种浏览器了。
那么简单来讲，只要是能与浏览器通过网路互动的系统，都可以算是WEB系统。最简洁的就是用NODEJS写一个echo,就是客户端发什么内容，就回什么内容。
而在实际应用中，WEB系统的架构，一般有这么几个部分：负载均衡、授权验证（可选）、静态内容服务、动态内容服务（业务逻辑）、资料库、运维后台。
1）负载均衡是为了改善使用者体验、充分利用伺服器资源，主要功能是将新的请求转发到不那么忙的伺服器进行处理。
2）授权验证，是在对浏览器发起的请求进行授权校验，如果不是合法的请求，就予以拒绝或者重定向至登入页面。
3）静态内容服务，是指图片、CSS等不会根据不同使用者而变化的静态内容，将其直接返回给使用者。因为不需要进行逻辑判断，效能主要取决于I/O读写，响应可以非常快。超大型网站，也会把一部分动态内容，例如对访问量大的新闻页，做静态处理，以提升响应速度。静态内容服务的典型是CDN。
4）动态内容服务，是根据使用者请求的不同，而进行响应的业务逻辑处理。比如对使用者资料的CRUD(增删查改）。这是绝大多数WEB系统的核心所在，一般会呼叫资料库和资料快取。具体实现会根据业务需要而变化，也可以变得非常复杂。
5）资料库，是资料所在，既有经典的关系型传统资料库系统，也有为了提升访问效能、减轻的记忆体资料库。
6）运维后台，是为了方便监控执行状态、升级维护系统，不直接参与对外服务。
先写这么多吧。有具体的问题了，可以再问。

简述tn系统的基本保护原理

TN系统是电源系统有一点直接接地，负载装置的外露导电部分通过保护导体连线到此接地点的系统，即采用接零措施的系统。
工作原理
在TN系统中，所有电气装置的外露可导电部分均接到保护线上，并与电源的接地点相连，这个接地点通常是配电系统的中性点。
TN系统的电力系统有一点直接接地，电气装置的外露可导电部分通过保护导体与该点连线。
TN系统通常是一个中性点接地的三相电网系统。其特点是电气装置的外露可导电部分直接与系统接地点相连，当发生碰壳短路时，短路电流即经金属导线构成闭合回路。形成金属性单相短路，从而产生足够大的短路电流，使保护装置能可靠动作，将故障切除。
如果将工作零线N重复接地，碰壳短路时，一部分电流就可能分流于重复接地点，会使保护装置不能可靠动作或拒动，使故障扩大化。
在TN系统中，也就是三相五线制中，因N线与PE线是分开敷设，并且是相互绝缘的，同时与用电装置外壳相连线的是PE线而不是N线。因此我们所关心的最主要的是PE线的电位，而不是N线的电位，所以在TN-S系统中重复接地不是对N线的重复接地。如果将PE线和N线共同接地，由于PE线与N线在重复接地处相接，重复接地点与配电变压器工作接地点之间的接线已无PE线和N线的区别，原由N线承担的中性线电流变为由N线和PE线共同承担，并有部分电流通过重复接地点分流。由于这样可以认为重复接地点前侧已不存在PE线，只有由原PE线及N线并联共同组成的PEN线，原TN-S系统所具有的优点将丧失，所以不能将PE线和N线共同接地。
由于上述原因在有关规程中明确提出，中性线(即N线)除电源中性点外，不应重复接地。

简述SPOOLing系统的基本原理

SPOOLing技术的特点: (1)提高了I/O速度.从对低速I/O装置进行的I/O操作变为对输入井或输出井的操作,如同离线操作一样,提高了I/O速度,缓和了CPU与低速I/O装置速度不匹配的矛盾. (2)装置并没有分配给任何程序.在输入井或输出井中,分配给程序的是一储存区和建立一张I/O请求表. (3)实现了虚拟装置功能.多个程序同时使用一独享装置,而对每一程序而言,都认为自己独占这一装置,不过,该装置是逻辑上的装置.

微机原理 简述你对8086系统的认识

8086 释出年份 1986 电晶体数 2.9万个,
主频4.77(MHZ) 资料汇流排宽度(16位)
外部汇流排 16位 地址汇流排20位 定址空间1M
快取记忆体 无
暂存器组 可见的
通用暂存器 专用暂存器 段暂存器
通用暂存器中 AX 累加器
BX 经常用作基址暂存器
CX 作为通用暂存器使用
DX 一般和AX组合用.DX 用来存放高位
SP 堆叠指标 BP 基址指标 DI 目的指标 SI 源变址
专用暂存器 有FLAGS标志
与资料相关的定址方式
立即定址 暂存器具 直接 暂存器间接 暂存器相对
基址变址 相对基址 比例变址 基址变址 相对基址比例变址
指令系统分为以下6组
资料传送指令串处理指令算术指令控制转移指令逻辑指令处理机控制指令
具体的指令,太多了,\
好像回答不对题,算了,

简述牵引供电系统的供电原理.

牵引供电是指拖动车辆运输所需电能的供电方式。牵引供电系统是指铁路从地方引入220（110）KV电源，通过牵引变电所降压到27.5KV送至电力机车的整个供电系统。
例如城市电车，地铁等，我们主要研究的内容是电气化铁道牵引供电系统。在我们这里简称牵引供电系统。
牵引供电方式：
直接供电方式(TR)
直接供电方式较为简单，是将牵引变电所输出的电能直接供给电力机车的一种供电方式，主要装置有牵引变压器、断路器、隔离开关、所用变、电压互感器、电流互感器、母线、接地系统、交流盘、直流盘、矽整流盘、控制盘、保护盘等装置。
直供方式的优点：结构简单、投资省
缺点：由于牵引供电系统为单相负荷，该供电方式的牵引回流为钢轨，是不平衡的供电方式，对通讯线路产生感应影响大。
回路电阻大，供电距离短（十几公里） 。
BT（吸流变压器）供电方式
这种供电方式，在接触网上每隔一段距离装一台吸流变压器（变比为1:1），其原边串入接触网，次边串入回流线（简称NF线，架在接触网支柱田野侧，与接触悬挂等高），每两台吸流变压器之间有一根吸上线，将回流线与钢轨连线，其作用是将钢轨中的回流“吸上”去，经回流线返回牵引变电所，起到防干扰效果。
由于大地回流及所谓的“半段效应”，BT供电方式的防护效果并不理想，加之“吸——回”装置造成接触网结构复杂，机车受流条件恶化，近年来已很少采用。
AT（自耦变压器）供电方式
采用AT供电方式时，牵引变电所主变输出电压为55kV，经AT（自耦变压器，变比2:1）向接触网供电，一端接接触网，另一端接正馈线（简称AF线，亦架在田野侧，与接触悬挂等高），其中点抽头则与钢轨相连。AF线的作用同BT供电方式中的NF线一样，起到防干扰功能，但效果较前者为好。此外，在AF线下方还架有一条保护（PW）线，当接触网绝缘破坏时起到保护跳闸作用，同时亦兼有防干扰及防雷效果。
显然，AT供电方式接触网结构也比较复杂，田野侧挂有两组附加导线，AF线电压与接触网电压相等，PW线也有一定电位（约几百伏），增加故障机率。当接触网发生故障，尤其是断杆事故时，更是麻烦，抢修恢复困难，对运输干扰极大。但由于牵引变电所馈出电压高，所间距可增加一倍，并可适当提高末端网压，在电力系统网路比较薄弱的地区有其优越性。
直供+回流（DN）供电方式（TRNF）
带回流线的直接供电方式取消BT供电方式中的吸流变压器，保留了回流线，利用接触网与回流线之间的互感作用，使钢轨中的回流尽可能地由回流线流回牵引变电所，因而部分抵消接触网对临近通讯线路的干扰，其防干扰效果不如BT供电方式，通常在对通讯线防干扰要求不高的区段采用。这种供电方式装置简单，因此供电装置的可靠性得到了提高；由于取消了吸流变压器，只保留了回流线，因此牵引网阻抗比直供方式低一些，供电效能好一些，造价也不太高，所以这种供电方式在我国电气化铁路上得到了广泛应用。
这种供电方式实际上就是带回流线的直接供电方式，NF线每隔一定距离与钢轨相连，既起到防干扰作用，又兼有PW线特性。由于没有吸流变压器，改善了网压，接触网结构简单可靠。近年来得到广泛应用。
同轴电力电缆供电方式
同轴电力电缆供电方式是在牵引网中沿铁路埋设同轴电力电缆,其内部导体作为馈电线与接触网并联,外部导体作为回流线与钢轨并联的供电方式。
这种供电方式由于投资大，一般不采用。

简述动态web应用系统的实现原理和工作流程？

webwork工作流程与原理
关键字: webwork
首先浏览器按照web.xml中指定的格式（比如：以.do结尾的请求）发起请求，servlet接收请求后从url中解析出action名称，同时遍历HttpServletRequest、HttpSession、ServletContext 中的资料，并将其复制到
Webwork的Map实现中，至此之后，所有资料操作均在此Map结构中进行，从而将内部结构与Servlet API相分离。
接着ActionProxyFactory建立对应的ActionProxy例项。ActionProxyFactory 将根据Xwork 配置档案（xwork.xml）中的设定，建立ActionProxy例项，ActionProxy中包含了Action的配置资讯（包括Action名称，
对应实现类等等）。ActionProxy建立对应的Action例项，并根据配置进行一系列的处理程式。包括执行相应的预处理程式（如通过Interceptor 将Map 中的请求资料转换为Action所需要的Java 输入资料物件等），以及对Action 执行结果进行后处理
是不是这个？

请简述动态web应用系统的实现原理和工作流程

客户端传送请求（POST/GET）-----伺服器端接受响应-----伺服器端处理请求-----返回处理结果-----客户端接受结果并处理（比如显示在网页上等）

请简述汽车电控系统的控制原理。

所谓的ESP（电子稳定程式，简称：ESP），电子稳定控制系统，旨在提高车辆的操控效能，而当汽车达到其动态范围失控的系统或程式有效地防止已知的。资讯的轮的运动，传递给电子分析系统。那么汽车四个车轮可以调整。是一种先进的技术。防止滑脱有很大帮助控制。由于ABSF
我想你指的是ABS防抱系统吧，它是一种ESP的，是防止刹车，车轮与地面打滑失控。

简述GPS导航系统的基本原理

GPS定位系统的工作原理是由地面主控站收集各监测站的观测资料和气象资讯,计算各卫星的星历表及卫星钟改正数,按规定的格式导航电文,通过地面上的注入站向GPS卫星注入这些资讯。测量定位时,使用者可以利用接收机的储存星历得到各个卫星的粗略位置。根据这些资料和自身位置,由计算机选择卫星与使用者联线之间张角较大的四颗卫星作为观测物件。观测时,接收机利用码发生器生成的资讯与卫星接收的讯号进行相关处理,并根据导航电文的时间标和子帧计数测量使用者和卫星之间的伪距。将修正后的伪距及输入的初始资料及四颗卫星的观测值列出3个观测方程式,即可解出接收机的位置,并转换所需要的座标系统,以达到定位目的。 GPS定位系统又叫GPRS,简单来说GPS定位系统是靠你的车载终端中内建一张手机卡,通过手机讯号传输到后台,来实现定位,GPS终端就是这个后台,可以帮你实现一键导航、后台服务、等各种人 *** 。GPS定位系统随着社会的发展被应用到越来越多的行业,它起到前期监督,后期管理的作用,统一分配,便于管理,提高我们的工作效率,降低成本

简述档案系统的结构

这与具体的作业系统有关系。
档案的组成结构一般分为物理结构和逻辑结构。物理结构是指档案在磁碟上的储存方式，而逻辑结构是指档案资讯的逻辑结构。象我们常提到的FAT,FAT32,NTFS等等都是档案的物理结构，它规定了档案资讯在磁碟上的储存方式，与具体的档案无关。而档案的逻辑结构则不同，它规定的是具体的一类档案中资讯的组织方式，象记录式档案和流档案等等。档案的逻辑结构多种多样，几乎每个种类的档案都有自己特殊的结构，比如WORD文件，比如BMP档案，比如MP3等

什么是web服务体系结构web服务体系结构具有哪些特征

Web Services体系结构是面向对象分析与设计（OOAD）的一种合理发展（logical evolution），同时也是电子商务解决方案中，面向体系结构、设计、实现与部署而采用的组件化的合理发展（logical evolution of components geared towards the architecture, design, implementation, and deployment of e-business solutions）。这两种方式在复杂的大型系统中经受住了考验。和面向对象系统一样，封装、消息传递、动态绑定、服务描述和查询也是Web Services中的基本概念，而且，Web Services另外一个基本概念就是：所有东西都是服务，这些服务发布一个API供网络中的其他服务使用，并且封装了实现细节。
具体见：
***隐藏网址***