毕业设计（论文）-Web服务器的构建.doc

XX 学 院毕业设计(论文)说明书题 目： Web服务器的构建 作 者： 学 号： 系 (院)： 专 业： 指导者： (姓 名) (专业技术职务)评阅者： (姓 名) (专业技术职务) 2008 年 6 月 目录第一章 前言31.1 Web系统31.2 Web服务架构41.2.1 Web服务架构中的角色41.2.2 Web服务协议栈的组成41.2.3重要的结构模型面向消息的模型面向服务的模型面向资源的模型面向规则的模型面向管理的模型111.2.4支持Web服务的技术体系11第二章HTTP和TCP/IP相关协议分析132.1 HTTP协议概述132.1.1 HTTP协议的发展132.1.2 HTTP协议的特点142.2 HTTP协议的传输过程152.3 HTTP协议的主要内容162.3.1 客户端请求(Request)162.3.2 服务器端响应（Response）17第三章TCP/IP相关协议分析203.1 TCP/IP协议概述203.2 IP协议分析203.3 TCP协议分析21第四章 Web服务引擎的设计244.1 Web服务的实现样式244.1.1 XML-RPC244.1.2 SOAP样式254.1.3文档样式254.1.4 Filter样式264.2 Filter样式Web服务的实现264.2.1 URL映射264.2.2Web服务的服务实现264.2.3对SOAP的兼容性264.2.4 Web服务的部署工具274.2.5利用Web服务引擎的方式27第五章 XML应用开发环境285.1以XML为中心的应用系统285.2 XML应用开发环境28参考文献29Web服务器的构建摘要：本文简单介绍了HTTP协议和TCP/IP标准协议，重点对利用XML技术作为基础，提出了开发应用系统的新的软件架构，并利用这个架构设计和实现了XML数据库的Web服务器的构建。关键词：HTTP；标准协议；Web服务器Abstract: This paper briefly introduced the HTTP protocol and TCP / IP standard protocols, focusing on the use of XML technology as a basis for the proposed development and application of the new system software architecture and use of this framework design and implementation of the XML database, Web server Construction. Key words: HTTP; Standard protocol; Web server第一章 前言1.1 Web系统目前的Web系统和Web服务架构是SOA的典型实例，Web系统巨大而稳定的特点与它的结构特点有关。Web系统通过资源，代理，XML等方式实现了它的基本结构。资源与URI 在Web系统中所有重要的资源都被要求定义一个标识符，这些标识符成为URI，通过URI可以链接到或者查找出一个资源，这是Web系统用户使用Web系统的基础保障，这里的URI可能是一个网站的地址，一个电子邮件的链接，新闻组或者是FTP站点等，利用URI可以获取各种类型的资源。Web代理 Web代理为每个请求提供所需的资源，根据请求的信息来选择资源返回给请求这个资源的代理，Web代理还可以处理一个安全控制和资源缓冲的功能，都是为更好的实现提供资源的服务。用户代理 用户代理实现了通过URI找到资源的能力，用户的使用都要通过代理来实现，用户代理是系统中的重要工具，借助用户代理各种表现形式被转化为用户可以理解的形式，如HTML, CSS, RDF, XML等。Web方法 通过一些Web方法，可以执行各种类型的资源操作，如:get， post put， delete等，方法的种类是有限的，但却可以实现各种各样的应用，简化的web方法类型，使Web系统比较简单却很强大。数据格式 在Web系统中存在着多种数据的格式，符合格式的数据可以被代理的理解和解释，数据通过例如MIME的格式被组织起来形成符合特定规范的数据，在Web系统中传递，包括表现形式，文字，声音，图像等。XML基础 Web上的表现方式是以XML为基础的形式，符合和不安全符合XML规范的数据用于描述资源的形式，对在Web系统中充分的使用，这使得Web系统可以兼容不同的实现方式，广泛的被利用和实现。1.2 Web服务架构Web服务架构5( Web服务Architecture，简称WSA)是由W3C的Web服务架构工作组(Web服务Architecture Working Group)正在开发过程中的Web服务架构标准。Web服务架构描述了Web服务标准的基本架构，是Web服务系列标准的核心，在Web服务架构中规定了Web服务的基本思想，Web服务实现体系的基本结构模型。1.2.1 Web服务架构中的角色WSA标准定义了什么是Web服务，Web服务应该具有什么，组成Web服务的各种基本感念，在Web服务中充当着不同的角色。代理和服务 服务是一组功能操作，由服务代理负责实现。Web服务系统的工作方式要求通过代理来实现服务，通过代理来请求和提供服务。但是服务的实现并不依赖与某个代理，服务可以经常更换代理，但是服务本身却没有变化。请求者和提供者 服务建立之后，由服务的提供者负责提供服务，服务的请求者可以向提供者发出请求来获取服务，这个请求和提供的过程需要在服务代理和请求代理之间通过消息系统进行信息交互，以完成整个服务的过程。服务的描述服务的描述是Web服务的一个接口，它定义了消息的格式，数据的类型和传输协议等内容，通过服务的描述使服务的请求者了解关于服务的信息，以便于调用服务。1.2.2 Web服务协议栈的组成目前WAS将Web服务协议划分为几个层次，层次之间的关系如下图所示:图1-1 Web服务协议栈 不同的标准和协议在Web服务架构中起到不同的作用，结合在一起构成了整个Web服务技术标准的协议栈。1.2.3重要的结构模型WSA为Web服务系统规定了5种比较重要的结构模型，下面将介绍这5种结构类型，重点介绍面向消息的模型和面向服务的模型。面向消息的模型 面向消息的模型(Message Oriented Model，简称MOM)，规定了在整个Web服务架构中关于消息的内容。MOM描述的重点是消息的内容，消息之间的关系，消息发送者和接收者之间的关系以及其他与消息有关的处理过程。消息的概念 Web服务是一个松散藕合的架构，在这个架构中存在的每个服务都是分布式的存在于若干个提供服务的系统中的，但是这些服务仍然需要信息交换，更普遍的一种情况是服务请求者向服务提供者提出对某个服务的请求的过程，所有类似的交互过程需要一种手段来完成，在Web服务架构中实现这一手段的方式就是消息，围绕有关消息的内容建立的模型就是MOM，即面向消息的模型。因此，消息就是Web服务架构中的信息交互层，消息这一层的内容抽象于具体的通信协议或面向通信的中间件系统，例如，通过Java消息中间件为基础可以实现MOM，利用HTTP的请求和响应也可以实现MOM, MOM与具体的实现机制无关。组成面向消息模型的元素面向消息的模型(Message Oriented Model，简称MOM)是由一组概念组成的，这些概念是组成MOM的必要元素。(1)消息的相关性 如果要使一个MOM的系统中的消息可以被规范地组织起来，那么维护消息的相关性是很重要的，相关性是指消息和Web服务上下文之间的关联，例如，依靠相关性，我们来判断收到的一个响应消息是前面发出的某个请求消息的响应，从而把这两个消息联系起来。所以相关性是MOM中的一个要素。(2)消息中介一个消息除了拥有一个消息的发送者，一个消息的接收者，之外还可能在交换过程中存在一个中介，这个中介对象既是消息的发送者，也是消息的接收者，在整个消息路径中起到转发的作用，消息中介使在消息路径中添加一些附加处理过程成为可能，例如可以利用消息中介来实现安全控制。(3)消息 消息是软件代理之间一次信息交互的数据单元，它描述了发送者和接收者之间所传递的数据的结构。一个消息由消息头，消息信封和消息数据组成。消息头中的内容是要用来扩展Web服务的应用的，通过在消息头中添加一些字段可以扩展Web服务的功能，例如把安全认证的信息放在消息头中可以使Web服务具备认证的功能，消息信封中包含了一些传递消息时需要的信息，如接收者的地址。消息数据是消息所要传递的数据，在这个可以直接包含需要传递的数据，也可以只包含一个指向实际数据的URI。实现消息的方式很多，每种方式都可以实现消息，但是支持的功能特性不同。最简单的实现方式是使用HTTP的GET请求方式，此时消息头由HTTP报头来实现，数据内容可以包含在URL内的参数中，但是HTTP的报头无法被Web服务利用来扩展其功能。另一种简单的方式是直接传送XML数据，但这种方式也无法支持Web服务的功能扩展。SOAP实现的方式比前两者要复杂一点，SOAP提供了对头信息和SOAP信封的支持，借助SOAP的信息头部分，可以支持Web服务的功能扩展。(4)消息信封消息信封确实就如同装着消息内容的信封一样，信封上面包含地址信息，消息传输者就依靠这个消息信封上的地址信息，将消息送达指定的地址，而且对于消息传输者来说它只需要消息信封上的信息就足够了。消息信封的另外一个作用就是消息内容封装这一层次上提供一些扩展的功能，例如将消息内容进行加密操作，可以在消息信封这个层次内完成。(5)消息交换模式 消息交换模式是软件代理之间传递消息的模式，它与应用之间的通信内容无关，只是定义那些支撑消息交换的通用方式，消息交换模式与通讯协议无关，但是必须与一种协议相互绑定，以soap方式的消息系统为例，消息模式定义了soap在消息的请求和响应过程中的交换模式。(6)消息头消息头的内容，在前面已经提到过，消息头为Web服务通过头信息进行功能的扩展提供了支持。(7)消息描述语言 消息描述语言可以用来描述发送者发送的消息，接收者需要接收的消息，主要描述消息的结构，使交互信息的双方可以规范化消息格式。(8)消息标识 消息标识是一个消息的唯一标识，每个消息都需要有一个唯一的消息标识。(9)消息路径 消息路径是从消息的发送者开始到消息的预定接收者之间的软件代理序列。消息路径表达了处理一个消息经过的顺序，同时也包括那些在消息路径上的消息中介。(10)消息接收者 消息接收者是接收消息的软件代理。一个消息可以有多个消息接收者，发送者在发送消息时也不需要了解所有的接收者的情况。(11)消息发送者 消息发送者是发送消息的软件代理。消息被发送后，在消息路径上的软件代理都会收到这个消息。(12)消息传输 消息传输机制是消息实际传输的机制，通常建立在已有的一些传输机制之上，如HTTP,SOAP, RMI等。(13)可靠的消息 消息的可靠性是面向消息的模型的一种特性，消息的可靠性直接影响Web服务的可靠性。面向消息的模型结构面向消息模型的整体结构可以由下图所示:图1-2面向消息模型的结构面向消息模型中的各个元素之间的关系构成了面向消息模型的基本结构，各个元素通过相互之间的配合形成了面向消息模型的体系结构，从这个结构中可以看出Web服务消息模型的工作模式。面向服务的模型 面向服务的模型(Service Oriented Mode1,SOM)的主要目的是描述软件代理与其所提供和请求的服务之间的关系。Web服务是面向服务(SOA)的架构，服务的概念在Web服务中很重要，SOM提供了针对服务描述，服务调用，服务任务，服务动作等内容的抽象描述。面向服务的模型(Service Oriented Mode1,SOM)在Web服务架构中并不是孤立的，它是建立在面向消息的模型(Message Oriented Model，简称MOM)基础之上的。不管是提供服务还是请求服务都离不开消息的交换，SOM不关心消息层的内容，而是完全借助MOM来实现它的消息的需要。面向服务模型中的服务 面向服务模型中的服务对于服务提供者和请求者是一些操作的集合，面向服务的模型建立了以服务为中心的交换体系。组成面向服务模型的元素 面向服务的模型(Service Oriented Mode1,SOM)也是由一组概念组成的，这些概念的组合构成了SOM的结构。(1)动作 动作是SOM中的重要概念，动作是由软件代理执行的一个过程，例如，发送一个消息，接收一个消息等。对于服务的提供者来说，执行一个动作实际上是运行一段，SOM不关心动作如何具体执行，而只是在抽象的层次上来定义动作的模式。(2)代理 代理是一个软件程序，它来执行人们需要的行为。例如，在互联网上代理帮助用来检索互联网上的信息。(3)服务场景 一个服务场景定义了旨在完成某项功能的相互协作的Web服务之间交互信息的顺序和条件。一个软件代理需要遵循某个服务场景的顺序才能达到它需要的目的。(4)服务场景描述语言服务场景描述语言是用来描述一个特定服务场景的语言，这种语言是程序之间可以相互交流的规范化的语言。(5)服务 服务对于服务提供者和请求者来说是一组动作。一个服务包含一些与之相关联的任务，而且每个服务都有一个标识符，这个标识符是一个URI。服务可以被请求者请求，由提供者负责提供，请求者和提供者之间依靠服务接口来交换信息。(6)服务描述服务描述是描述服务接口的一些文档，例如，一个完备的XML文档就可以作为一个服务描述。(7)服务末端 一个服务的末端是实现这个服务的服务接口的网络地址。(8)服务接口 一个服务接口中描述了这个服务所发送和接收的消息，服务接口由服务末端提供实现。(9)服务操作 服务操作定义了调用服务的每个任务时发送和接收的消息。(10)服务提供者 服务提供者是一个代理，这个代理执行与服务有关的动作，一个服务可以由多个代理所提供，反过来一个服务提供者也可以提供多个服务。(11)服务请求者 一个服务请求者负责向一个服务提供者请求一个服务。(12)服务语义一个服务的语义是服务提供者和服务请求者之间的约定。语义与服务中封装的任务有关。(13)服务任务服务任务是与一个服务相关的事务单元，服务任务由一个服务目的和一个动作组成，目的用来描述任务会达到的目的效果，动作描述了达到这个目的的处理过程。面向服务模型的结构面向服务模型中的各个元素之间的关系如下图所示:图1-3面向服务模型的结构 面向服务模型中的各个元素之间的关系构成了面向服务模型的基本结构，各个元素通过相互之间的配合形成了面向服务模型的体系结构。面向资源的模型WSA中定义了面向资源的模型，这个模型从资源的角度描述了Web服务的结构。在WSA中只要拥有一个描述符的定义，就可以称之为一个资源。WSA为资源提供了定义和使用的模型，代理可以通过PUT, GET, DELETE等操作来改变资源的状态，资源也可以通过一些表现方式显示出来，同时资源也可以被描述和发现。面向规则的模型WSA中定义了面向规则的模型，规则是对代理行为的约束，在WSA中通过控制规则实现对代理的某些行为的允许和禁止。规则模型的建立为Web服务的安全控制提供了基础。WSA中定义了面向规则的模型，规则是对代理行为的约束，在WSA中通过控制规则实现对代理的某些行为的允许和禁止。规则模型的建立为Web服务的安全控制提供了基础。面向管理的模型WAS中还定义了面向管理的模型，管理模型的建立是为了对Web服务资源进行有效的管理，为开发者提供了在分布式系统中管理Web服务的方法。1.2.4支持Web服务的技术体系目前Web服务技术体系的实现主要依靠以XML,SOAP, WSDL等技术为基础的一系列标准，这些标准在不同的方面支持了Web服务的架构实现。 XML与Web服务XML是Web服务技术体系中最基础的标准，Web服务的一切都建立在XML技术的基础之上，包括Web服务的消息，描述，服务实现的各个环节。XML是Web服务实现跨实现结构方式的基础，利用XML Web服务的服务提供者和请求者可以利用不同的开发语言协作完成服务调用的过程。XML是Web服务技术体系中的很多标准建立的基础。 SOAP与Web服务SOAP是简单对象访问协议，它的出现为Web服务提供了一种实现的方式，目前已经得到广泛的应用，而且基于SOAP的许多扩展标准正在逐渐完善，以SOAP为基础的Web服务技术体系正在不断的扩大。 WSDL与Web服务 WSDL是与soap相结合使用的Web服务描述语言，通过WSDL可以描述一个服务的信息。这些信息使不了解这个服务的开发者可以建立调用这个服务的客户端代码，或者通过WSDL帮助生成实现它的基本代码结构。WSDL在Web服务的实际开发过程中起着重要的作用。第二章HTTP和TCP/IP相关协议分析2.1 HTTP协议概述Web服务器使用的主要协议是HTTP 协议，即超文体传输协议。HTTP是应用级协议，它适应了分布式超媒体协作系统对灵活性及速度的要求。它是一个无状态、无连接、基于Client/Server模式的协议。2.1.1 HTTP协议的发展 HTTP协议的版本经历了HTTP0.9, HTTP1.0, HTTP1.1三个版本。HTTP0.9是HTTP第一次出现时制定的原始协议。它是目前使用的HTTP1.1的子集。该协议描述了客户端和服务器间请求和响应过程:客户端在特定地址向服务器请求连接，然后调用GET请求，访问服务器端对象，服务器在终止连接前将该对象或一个错误消息返回给客户端，结束响应过程。HTTP1.0以HTTP0.9为基础。在HTTP0.9中，客户端和服务器的相互作用只能直接进行，HTTP1.0对此进行了扩充，允许通过中间实体，如代理进行连接。HTTP 1.0用MIME描述对象的数据类型，既可以处理简单的纯文本Html，也可以处理更复杂的多媒体信息，如声音、图像和视频等。改进之处主要有: 1.增加请求类型。如:HEAD, POST请求。2.请求和响应消息的协议版本。如:响应消息第一行以HTTP/1.0，表示服务器使用HTTP 1.0协议。3.服务器响应码，表示请求、响应消息是否成功。如:响应消息第一行以2000K结束，表示请求成功。4.用MIME格式的消息头字段和消息体格式来描述访问对象的数据类型和附加在后面的元信息。如:头字段Content-Type text/html，表示响应消息实体为Html文件。5.用询问/响应实现访问认证。如:在访问某些主页时要求客户端输入用户名和口令。HTTP 1.1是HTTP1.0的一次飞跃，它主要强调解决后者的性能、安全、数据类型处理和缓冲等方面的缺陷。HTTP1.1主要改进包括:1.使用永久连接作为缺省连接，提高性能。2.使用摘要认证，提高安全性，克服基本认证方法中“显式”传递用户名和密码的缺陷。3.使用内容防商机制允许客户端和服务器以最佳方式描述对象。HTTP1.1提出在服务器方缓冲对象，通过一种客户端/服务器协议操作缓冲对象进一步提高性能的思想，目的是减少请求、往返次数，并且是在确实需要时才返回完整的响应。另外，HTTP 1.1突破了HTTP1.0中服务器和IP一对一的限制，允许使用Host标题字段服务器的名字来决定由哪个服务器对请求进行服务，而不用IP地址来决定。2.1.2 HTTP协议的特点HTTP协议设计简单灵活、无状态、无连接、基于Client/Server模式并支持元信息，其特点主要如下:1.以Client/Server模型为基础:HTTP支持客户与服务器之间通信及相互传送数据，一个服务器可以为分布在世界各地的许多客户服务。2.简单快速:HTTP被设计成一个非常简单的协议，使得Web服务器能高效地处理大量请求，客户机要连接到服务器，只需发送请求方式和URL路径等少量信息。HTTP规范定义了七种请求方式，最常用的有三种:GET, HEAD和POST。由于HTTP协议简单，HTTP的通信与FTP, Telnet等协议的通信相比，速度快而且开销小。3.灵活:HTTP允许传输任意类型的数据对象。4.无连接:HTTP是无连接的协议。这里的“无连接”是建立在TCP/IP-协议之上的，与建立在UDP协议之上的无连接不同。客户要建立连接需先发出请求，收到响应，然后断开连接。采用这种“无连接协议，在没有请求提出时，服务器就不会在那里空闲等待。完成一个请求之后，服务器不会继续为这个请求负责，从而不用为保留历史请求而耗费宝贵的资源。5.无状态:HTTP是无状态的协议，这既是优点也是缺点。一方面，由于缺少状态使得HTTP累赘少，系统运行效率高，服务器应答快;另一方面，由于没有状态，协议对事务处理没有记忆能力，若后续事务处理需要有关前面处理的信息，那么这些信息必须在协议外面保存;另外，缺少状态意味着所需的前面信息必须重现，导致每次连接需要传送较多的信息。6.元信息:元信息被定义为“关于信息的信息”，元信息允许服务器提供所发送数据的信息，例如，HTTP可以提供所发送的对象的语言和类型。2.2 HTTP协议的传输过程图2-1 HTTP传输过程 1.建立连接 连接的建立是通过中请套接字实现的。客户打开一个套接字并把它约束在一个端口上，如果成功，就相当于建立了一个虚拟文件。以后就可以在该虚拟文件上进行读写。 2.发送请求 打开一个连接后，客户机把请求消息送到服务器的连接端口上，完成提出请求动作。 3.发送响应 服务器在处理完客户的请求之后，向客户机发送响应消息。 4.关闭连接客户和服务器双方都可以通过关闭套接字来结束对话，一般情况下服务器发送完客户端请求的文件后会主动关闭套接字。2.3 HTTP协议的主要内容请求和响应是HTTP协议的核心，客户端和服务器之间的信息传递是通过消息来进行的，请求消息是客户端向服务器发送的用于请求服务器提供服务的消息。响应消息是服务器接到客户端请求后返回给客户端的消息。2.3.1 客户端请求(Request)请求消息格式请求行格式:方法 请求URI HTTP版本号CRLF头字段格式:用冒号分割的name-value对，每个对没有顺序之分，一个name可能有用逗号分开的多个value。请求消息格式实例如下:GET/HTTP/1 .1rnAccept: image/gif, image/xx-bitmap, image/jpeg, image/pjpegrnAcceptLanguage: zhcnrnAcceptEncoding: gzip, deflaternUser-Agent: Mozilla/4 .0rnHost:0:8080rnrn方法(Method) 方法描述了对给定资源应作的处理。在HTTP/1.1下，请求的合法方法有:OPTIONS, GET, HEAD, PUT, POST, TRACE和DELETE，其中最常用的是GET, HEAD和POST。 GET:用于向服务器请求资源对象。如果对象是文档或文件，GET将请求其内容;如果对象是程序，GET将请求程序的运行结果;如果对象是数据库查询，GET将请求查询的结果。 HEAD:用于向服务器请求对象的元信息。使用高速缓存的客户经常使用HEAD请求来取得文档最近的修改时间，与缓存中文档的修改时间进行对比，HEAD方法的请求速度要快得多，因为它不需要传送整个文件。 POST:用于向服务器传送数据。POST方法用于客户端向服务器提交表单。表2-1 常见方法头字段(Header Fields） 头字段一般用于传送除请求外的其他附加信息。表2-2 常见头字段2.3.2 服务器端响应（Response）响应消息格式状态行格式:HTTP版本号 状态码 Reason-Phrase CRLF 头字段HTML主体实例如下:HTTP/1 .0 200 OKrnServer: Smart WebrnConnection: closernContent-Length:272rnContentType: text/ html rnDate: Sun, 04 Dec 2005 07:34:32rnSmart Web ServerSmart Web Server introduction About Author 状态码状态码表示服务器是否成功地满足了客户的请求，状态码由一个三位整数和解释装态码含义的正文短语组成。状态码大致分类如下:表2-3状态码头字段与请求消息相同，头字段一般用于传送除请求外的其他附加信息。表2-4 常见头字段第三章TCP/IP相关协议分析3.1 TCP/IP协议概述 TCP/IP是一个防议集合，其核心功能是寻址和路由选择以及传输控制。TCP/IP协议是HTTP协议的基础，HTTP实现客户与服务器之间的请求和响应，而TCP/IP实现了底层的数据传输。TCP/IP协议体系结构模型如图3-1所示。图3-1 TCP/IP协议模型 物理层和链路层:处理终端与网络之间的接口细节，包括操作系统的设备驱动程序、网片等。 网络层:网络层包括IP协议.ICMP协议3 , IGMP协议4、ARP协议5 , RARP协议。其中IP协议是不可靠(unreliable）、无连接(connectionless)的数据报协议，为其他高层协议提供最基本的数据传输功能。 传输层:传输层包括TCP和UDP两个著名的协议，二者均使用IP网络层协议，为两台主机上的应用程序提供端到端的通信。TCP虽然使用不可靠的IP服务，但却为主机提供面向连接的、可靠的传输层数据通信服务。UDP为主机提供无连接的、不可靠的数据通信。虽然UDP提供不可靠的服务，但这种协议的开销很小，因此也有着广泛的应用。 应用层:负责处理应用程序细节，这一层有许多协议，如HTTP, FTP,TELNET等。3.2 IP协议分析 IP协议是TCP/IP协议中最为核心的协议，TCP, UDP数据都以IP数据报格式传输。IP协议是不可靠，无连接的数据报协议，为其它高层协议提供最基本的数据传输功能。IP报头格式如图3-2所示。图3-2 IP报头格式 TTL: 8字节TTL表示数据报生存时间，即数据报最多可以经过的路由数。 total length:整个IP数据报的长度，以字节为单位。由于该字段长16位，故IP数据报的最大长度可达21665535字节protocol:表示封装在IP数据报里的上层l办议，通常有6(TCP), 17(UDP)等。IPv4 address: 4个字节的32位IP地址。以字节序传输。3.3 TCP协议分析TCP协议以IP协议为基础，提供面向连接的、可靠的字节流服务。TCP数据被封装在IP数据报中，如图3-3所示，其报头格式如图3-4 。图3-3 TCP数据封装在IP数据报图3-4 sequence number: TCP是流式传输，为了保证顺序，发送的数据报应编号。 port number:每个TCP段都包含一个原端口号和目的端口号，这两个端口号加上IP首部的源IP地址和目的IP地址唯一确定一个TCP连接(socket) 。 URG:紧急标志有效。 ACK:确认标志。大多数情况下该标志位是置位的。确认编号为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。 PSH:推标志。该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。 RST:复位标志。用于复位相应的TCP连接。 SYN:同步标志。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。FIN:结束标志由于TCP是面向连接的协议，故双方进行通信之前需要三次握手建立连接。图3-5三次握手完成通信之后需四次挥手结束。图3-6四次挥手第四章 Web服务引擎的设计4.1 Web服务的实现样式Web服务的产生是源于开发者对原有复杂且不能统一的各种分布式计算方式的不满，希望建立一种新的简单易用，又可以将各种平台，各种语言开发的分布式应用同一在一起的计算方式。这种新的方式被一致认为应该在Web的成功基础上开发，1998年2月27日，Dave Wine:写了一篇题为“RPC over HTTP via XML的文章，提出在HTTP协议基础上运用XML技术实现远程过程调用的方式了解决混乱而复杂的分布式计算问题，这种方式目前已经被多种不同的开发语言所实现，并且可以相互协作。Apache组织技术领袖:Roy Thomas Fielding提出了REST(REpresentation State Transfer)结构模型，为设计Web服务的实现方式提供了理论指南，成为W3C组织开发Web服务架构标准的参考。 从XML-RPC到目前被使用的最多的SOAP协议方式，已经有多种样式的Web服务在被使用，但它们多数仍限于远程过程调用的模式，随Web服务复杂程度的提高，实现的难度和复杂程度也不断的提高，仍然表象出面向对象技术的特点。本文提出了基于XML-Pipe-Filter架构的Web服务实现样式，这种样式不仅使复杂的Web服务可以由简单的Web服务简单装配而成，而且可以被利用来实现更广泛的应用，成为实现应用系统的基础技术，本文第5章就利用了这种方式实现了门户服务器产品。4.1.1 XML-RPC XML-RPC技术的实质就是利用XML来描述你所需要的远程调用方法，并且通过HTTP来传送这些XML数据。XML-RPC的实质仍然是远程过程调用的方法，但是XML的产生使XML-RPC可以利用XML来描述调用的过程，通过XML-RPC与一种通信协议绑定的方式将带有特定意义的XML数据在客户端和服务器端之间交互，使调用过程可以以一种依赖于XML的方式进行。对于不同的实现方式来说，在与其它系统进行交互的过程中，只有XML是作为接口出现的，这使得不同实现之间的区别被XML包装起来，成为对于其它系统来说透明的实现，所以XML-RPC可以实现跨平台的分布式计算，将不同语言，不同技术所实现的系统连接器来。XML-RPC将XML用于远程过程调用，并且借助HTTP协议进行网络通信的方式对于需要简单调用服务端过程的应用系统来说是很有效的。对于开发者来说，XML-RPC是一个客户端和服务器之间通过XML交互的过程。如图4-1所示:图4-1 XML-RPC技术无论是客户端还是服务器端都将数据编码为XML的形式发送，为了使不同的XML-RPC实现之间可以达成一致，需要制定统一的XML标准，这就是XML-RPC标准。4.1.2 SOAP样式 SOAP是以XML-RPC为基础而实现的Web服务实现样式，SOAP将RPC的过程用详细和复杂的SOAP标准描述，甚至包括自定义的数据类型，集合参数的传送等方面的信息。与XML-RPC相比SOAP的标准化程度高，功能更加强大，但是SOAP的实质仍然是通过RPC模式调用服务器端的组件对象。4.1.3文档样式文档样式的Web服务比SOAP和XML-RPC方式更加的开放，客户端和服务器端利用XML文档对象之间进行交互，利用对两端都了解的XML数据进行处理完成客户端请求的服务，不足之处是文档样式目前并没有对服务器端处理文档的应用模式作进一步的约定，还缺乏进一步的完善。4.1.4 Filter样式Filter样式是本文提出的Web服务样式，利用XML-Pipe-Filter架构在服务器端建立管道了过滤器的模式，每个Web服务以管道的形式开发和部署，这使得Web服务可以相互组合，客户端在请求了服务之后，经过一系列过滤器的作用完成服务的任务，返回给客户端，利用XML数据建立消息模型，利用过滤器结构实现服务模型，在此基础上可以通过开发特殊Web服务的方式实现Web服务的高级管理模型，策略模型，安全模型等，完成整个Web服务的技术体系。Filter样式的好处是所有过滤器之间只是利用XML SAX事件相结合，Web服务的扩大和累积并不会使Web服务的实现变得更复杂。4.2 Filter样式Web服务的实现由于Web服务是一个XML的应用系统，客户端请求是通过XML传递的，返回客户端的响应数据也是以XML数据返回的，Filter样式Web服务的实现实际上是在XPipe的基础上添加了与Web服务有关的特殊Filter，组成实现Web服务的特殊Pipe而实现的。4.2.1 URL映射客户端请求的Web服务需要指向一个服务的地址，这个地址是Web服务的URL，服务器端将每个URL与特定的Web服务向绑定，例如，http:/localhost:8080/ws/services/hello是指向hello这个服务的URL 。4.2.2Web服务的服务实现在这里完全使用Pipe来一对一的实现一个Web服务的服务，而不是象SOAP样式那样指定一个服务的类和方法，然后用RPC的方式调用。这里的Web服务服务对象是一个或者多个过滤器组成的Pipe。4.2.3对SOAP的兼容性Filter与SOAP,XML-RPC和文档样式相比较更加接近文档样式的方式，但是Filter所依靠的XML-Pipe-Filter架构比简单的文档样式复杂，而且强大。利用Filter结构不仅能够实现Filter样式的Web服务，还可以实现其它类型的几种Web服务，例如实现SOAP样式的方法只需要在Pipe的Filter的序列中添加一个SOAP的适配器就可以实现，如果客户端发送的是SOAP请求，那么作为SOAP适配器的Filter直接可以响应SOAP消息中的SAX事件，实施SOAP方式的Web服务调用过程。如果客户端发送的不是SOAP消息，那么作为SOAP适配器的Filter就不会起到任何作用。4.2.4 Web服务的部署工具本文设计了面向Web服务的部署XAR压缩包和部署工具，在XAR压缩包中包含实现Web服务服务的class文件，pipe的配置文件，Web服务的名称和URL的配置信息，将XAR压缩包部署到服务器之后，所需的class会被加载到正在运行的服务器中，备置文件也会被部署和设置到服务的配置文件中，升级Web服务的服务。4.2.5利用Web服务引擎的方式实现的Web服务引擎直接可以被用于作为Web服务的服务器使用，还可以作为利用Web服务方式开发应用系统的基础结构。本文下一章介绍利用Web服务引擎所实现的XML Portal平台。第五章 XML应用开发环境5.1以XML为中心的应用系统那些主要的业务处理过程可以被设计或转化为接收XML数据并返回XML数据的应用系统，称为以XML为中心的应用系统。基于对以XML为中心的应用系统的实现技术支持，XML Native的所有交互过程都是XML数据形式，Web服务技术更是以XML技术为基础的系统，包括XForms的实现，XML Portal的设计，这些项目的实现都是依赖于本文针对以XML为中心的应用系统而设计的XML-Pipe-Filter架构而实现的。5.2 XML应用开发环境以XML-Pipe-Filter架构为基础，整合本文的所有实现项目，可以形成了面向XML的数据持久性，消息通信机制，Portal表现层工具实现，Web服务实现引擎等结合在一起的一个XML应用开发环境，即Web服务器。参 考 文 献1aspectj project /aspectj/2Hao He“What is Service-Oriented Architecture”3World Wide Web Consortium(W3C)“Naming and Addressing”/Addressing/4World Wide Web Consortium(W3C)“Extensible Markup Language”/XML/5World Wide Web Consortium(W3C)“Web Services Architecture” /TR/ws-arch/6World Wide Web Consortium(W3C)“SOAP Version 1.2”/2000/xp/Group/7World Wide Web Consortium(W3C)“Web Services Description Language”/TR/wsdl/8JBoss project 9Java Management Extensions /products/JavaManagement/10Apache Group“XIndice Native XML Database”/Xindice/11Portlet Specification/aboutJava/communityprocess/review/jsr168/12Roy Thomas Fielding“Architectural Styles and the Design of