5.2.11 Web服务器与Web应用服务器有什么区别
Web服务器是可以向发出请求的浏览器提供文档的程序。其主要功能是提供网上信息浏览服务；即接收浏览器的请求并把处理结果传回浏览器进行显示。Web服务器支持以HTTP的方法来访问，当Web服务器接收到一个HTTP请求时，它同样会以HTTP格式返回一个响应，这个响应可以是一个静态的HTML页面，也可以是结果处理的一个动态页面，还可以是音频、视频等信息。为了处理一个请求，Web服务器可以做出一个响应，并进行页面跳转，或者把动态响应的产生委托给一些其他程序，例如CHI脚本、JSP、Servlet或者一些其他的服务器端程序。Web服务器一般都使用了一些特有的机制(例如容错机制)来保证Web服务器有较好的扩展性，并能提供不间断的服务。常见的Web服务器有IIS和Apach。
应用服务器提供访问业务逻辑的途径以及客户端应用程序的使用。具体而言，它通过HTTP、TCP/IP、IIOP(Internet Inter-ORB Protocol，互联网内部对象请求代理协议)或JRMP(Java Remote Method Protocol,Java远程方法协议)等协议来提供业务逻辑接口。为了系统的可靠性，同样使用了一些可扩展性和容错性机制。除此之外，它还为应用的开发提供了许多服务，例如事务管理、安全管理、对象生命周期管理等。常见的应用服务器有BEA WebLogic Server、IBM WebSphere Application Server、IPlaner Application Server、JBoss和Tomcat等。
Web服务器一般是通用的，而应用服务器一般是专用的，例如Tomcat只处理Java应用程序而不能处理ASPX或PHP。需要注意的是，Web服务器与应用服务器是并列关系，二者不存在相互包容关系。在使用时，如果访问的页面只有HTML，用Web服务器就足够了，但是如果是JSP，此时就需要应用服务器了，因为只有应用服务器才能解析JSP里的Java代码，并将解析结果以HTML的格式返回给用户。
5.2.12 什么是Web Service
Web Service是一种基于网络的分布式模块化组件，它可以将可调用的功能发布到Web上以供应用程序访问(应用程序可以使用标准的Web协议和数据格式来访问它)。由于Web Service遵循一定的技术规范，使得它能够与其他组件或系统有很好的兼容性。
具体而言，Web Service是基于下面的一些协议来实现的。
1>可扩展可标记语言(eXtensible Maekup Language,XML)。它是实现Web Service的基础，非常适用于在网络上传输数据时使用。
2>Web服务描述语言(Web Service Description Language,WSDL)。它是采用XML语言来描述Web Service属性的语言。它将Web Service描述为可以进行消息交换的服务访问点的集合，具体定义了Web Service可以做什么，在哪里以及怎样去调用。
3>通用描述、发现与集成服务(Universal Description，Discovery and Integration，UDDI)。它是一种由OASIS(结构化信息标准促进组织)制定的规范，主要提供基于Web服务的注册和发现机制，为Web服务提供3个重要的技术支持：1)标准、透明、专门描述一个Web Service的机制；2)调用Web服务的机制；3）可以访问的Web服务注册中心。它维护了一个Web Service的全球目录，其中的信息描述格式也是基于XML格式的。UDDI的核心组件是UDDI商业注册，它使用XML文档来描述企业及其提供的Web Service。
4>简单对象存取协议(Simple Object Access Protocol,SOAP)。它是Web Service的通信协议，当用户通过UDDI找到对应的WSDL描述符后，就可以通过SOAP调用Web服务中的操作。SOAP也基于XML描述的方法调用规范。
调用Web Service时，服务提供者把所提供的服务发布到服务代理的一个目录上，然后服务请求者使用UDDI首先到服务代理提供的目录上搜索服务，得到如何调用该服务的信息(WSDL)，然后根据得到的调用信息使用SOAP调用服务提供者提供的服务，如下图：
Web Service的这种实现方式使其拥有很多优点，具体表现为如下几个方面：
1)完好的封装性。服务使用者只需要知道Web Service提供的功能列表，而不需要关心具体的实现。
2)松耦合。Web Service在不改变接口的情况下可以随意改变实现方式，而且不会影响到服务的使用者。也就是说，服务的提供者与使用者互不影响。
3)高度客户操作性。可以跨平台、跨语言进行调用。
4)动态性。可以自动发现服务并进行调用。
5.2.13 SOAP和REST有什么区别
SOAP是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成为机器可读的格式化数据，SOAP数据使用XML数据格式，定义了一整套复杂的标签，来描述调用的远程过程、参数、返回值和出错信息等内容。
REST(Representational State Treansfer，表述性状态转移)形式上为客户端通过申请资源来实现状态的转移，可以被看作是一台虚拟的状态机。需要注意的是，它只是一种软件架构风格，而不是一个具体的协议或标准，而且，它是面向资源的，甚至连服务也会被抽象成资源。
SOAP和REST的对比如下：
5.2.14 什么是XML
可扩展标记语言(eXtensible Markup Language,XML)是一套定义语义标记规则的语言，可以被用来描述业务数据、数学数据等。XML一个非常重要的用途就是实现了系统的解耦机制(例如，Web Service和JMS都大量使用了XML文件，实现了系统不同模块的解耦)。那么XML有哪些优点呢？相较于HTML。XML将用户界面与结构化数据分离开来，这种数据与显示的分离使得集成来自不同源的数据称为可能。除此之外，XML还有如下4个主要优点。
1>实用性强。由于XML是以文本而不是二进制的方式存储的，因此很容易对其进行修改和调试。此外，XML不仅可以用在数据量较小的场合(例如structs-config.xml、web.xml等一些配置文件)，同时也适用于存储大量的数据(例如基于XML存储的数据库)。
2>访问速度快。由于XML使用的是层次结构，因此可以非常方便、快速地通过深入到感兴趣的节点获取感兴趣的数据。
3>可扩展性好。XML不仅可以用来存储和显示数据，而且还能通过相关的属性标记数据的属性与类型，以便应用程序可以根据实际情况选取不同的数据。同时，由于XML中的标记可以由使用者自己定义，因此它具有很好的可扩展性。
4>跨平台性好。XML具有统一的标准语法，因此，大部分系统支持的XML文件都具有相同的语法结构，这就使得它具有很好的跨平台特性。
尽管XML有点出众，但其也存在不足之处。XML的主要缺点就是当数据量过大时，它的效率会变得很低，往往会比其他存储方式(例如CSV)占用更大的存储空间。因此，如果要在网络中通信的场合、带宽受限的情况下，一般不适合使用XML。
XML文档定义有两种形式：文档类型定义(Document Type Define,DTD)与Schema。他们一方面用于定义XML文档的结构，另一方面用于验证XML文档是否满足指定的结构。具体而言，DTD是一套标记的语法规则，一个XML DTD定义了XML文档的元素架构、元素标记和属性，规定了用户在DTD关联的XML文档中可以使用什么标记、各个标记出现的顺序以及标记的层次关系，并定义了实体。当建立XML文档时，通常需要按照DTD规范来进行，反过来也可以通过对文档进行DTD验证，检验XML文档建立的正确性。DTD不能定义一些必要的限制条件，例如元素出现的次数、数据类型(例如整型、浮点型、布尔型)等，因此DTD更适于以文档为中心的XML内容。而Schema与DTD不同，它本身基于XML，是用一套预先规定的XML元素的属性创建的，这些元素的属性定义了XML文档的结构和内容模式。XML Schema同时还支持命名空间，能够定义比DTD更复杂的数据类型和结构。XML Schema内置支持一系列的简单数据类型，例如字符串、小数和整数等，还可以定义元素出现的次数。除此之外，XML Scheman利用命名空间将文档中的特殊节点与Schema说明相联系，一个XML文件可以有多个Schema，而对于DTD，一个XML只能有一个相对应的DTD，因此XML Schema更适合以数据为中心的文档。所以，越来越多的应用偏向于采用XML Schema来定义和验证XML文档。
目前，对XML的解析最主要的方式有两种：DOM和SAX(Simple API for XML,即XML简单API)。DOM方式会根据给定的XML文件在内存中创建一个树形结构，因此，这种处理方式会占用比较多的内存，在处理大文件时效率会急剧下降。而且DOM必须在解析文件之前把整个文档装入内存，所以该方式主要适用于对XML的随机访问与频繁对XML中的内容进行修改的场合。而SAX是事件驱动型的XML解析方式，它不会在内存中存储XML文件的内容，只是把每次对数据的请求看作一个事件，通过遍历文件来获取用户所需的数据。当遇到像文件开头、文档结束或者标签开头与标签结束时，它会触发一个事件，用户通过在其回调时间中写入处理代码来处理XML文件。所以，它的使用场合一般为对XML的顺序访问、XML文件太大以至于在内存中放不下等情况。
5.2.16 J2EE开发有哪些调优的方法
当使用J2EE开发Web应用程序时，若只是考虑功能实现，一般不存在什么问题，但由于Web应用的分布式特性，在很多特定的场合下，并发数据量会变得非常大，如何才能保证此时系统还可以高效的运转，而且能够快速的响应用户的请求呢？
下面介绍一些常用的方法：
1>优化设计。例如，小心的使用继承。继承会导致递归，同时由于父类的构造器将会被遍历，继承嵌套的过深，会产生巨大的创建开销，因此推荐尽量使用组合方式来代替继承方式。除此之外，还有很多其他的方式：封装和重用常用的业务方法以及相关工具，避免在其他类中重复编写；简化类构造结构；面向接口编程；尽量使用主要类型；避免对象的过度使用，例如，不要为了使用一个方法就创建对象，应尽可能的使用静态方法或是使用将业务组件实例化后共享的方法等。
2>尽可能使用数据库连接池。建立数据库连接是一项必须但又非常耗时的工作，如果频繁的建立与数据库的连接将会导致系统的性能急剧下降。因此，在实际开发系统时，经常使用数据库连接池来提高系统性能。具体而言，就是使用应用服务器维护者数据库连接池，这样就不需要在每个事务开始时就创建一个连接了。此外，由于PreparedStatement有缓存功能，这使得其具有较高的效率，因此，在使用JDBC的方式访问数据库时，应尽可能使用PreparedStatement。
3>给Web容器配置合理的线程数量来处理客户端的HTTP请求。一般而言，最小的线程数量设置为容器处理请求的平均数(平均负载)，最大值设置为系统在高峰期处理的请求数，同时Web容器中线程的个数最好不要多于Web服务器中线程的个数。
4>根据实际情况设置Java虚拟机中堆空间的大小。合理的设置堆空间的大小能够使得垃圾回收器运行的时间间隔被控制在一个合理的范围内，从而减少许多不必要的系统开销。
5>使用框架(例如Hibernate)来提高系统的效率。
6>把一些经常被访问的Servlet或JSP缓存起来，能够减少响应时间和提高系统的性能。但需要注意的是，缓存并非越多越好，无规则的使用缓存也可能会导致系统的崩溃。
7>当在系统中使用EJB时，由于对EJB的调用是采用对象请求代理(Object Request Broker,ORB)的方式来完成，而ORB使用了线程来处理对EJB的请求，因此，应当合理配置线程池的大小以便它能够在平均负载和高峰期都能够很好地处理EJB的请求。
8>优化I/O性能。I/O使用不当将会造成资源竞争，降低系统的性能。所以，在实际应用时，尽可能少使用System.out打印调试信息，推荐使用缓冲。
9>优化查询。在模型设计时就应该考虑冗余相对不会变化的数据，如果设计大数据量，最好能够考虑分区设计。
10>对session进行合理管理与设置。根据实际情况对内存中可能存在的session个数设置一个合适的值。注意：尽量减少session的大小，以降低其对内存的使用。而且，除非是在必需情况下，否则尽量不要启用对session的持久化。同时，通过对session设置一个合理的超时时间来回收较长时间不使用的session，也可以有效的提高系统效率。