HTTP作为一个更好的RPC

　　在服务器群落中使用DCOM  和CORBA  是通用的做法，但客户机则使用HTTP进入服务器群落。HTTP与RPC的协议很相似，它简单、配置广泛，并且对防火墙比其它协议更容易发挥作用。HTTP请求一般由Web服务器软件（如IIS和Apache）来处理，但越来越多的应用服务器产品正在支持HTTP作为除DCOM和IIOP外的又一个协议。 

　　象DCOM和IIOP一样，HTTP层通过TCP/IP进行请求/响应通信。一个HTTP的客户端用TCP连接到HTTP服务器。在HTTP中使用的标准端口号是80，但任何其它端口也能被使用。在建立TCP连接后，客户端可以发送一个请求消息到服务器端。服务器在处理请求后发回一个HTTP响应消息到客户端。请求和响应消息都可以包含任意的传输体的信息，通常用Content-Length和Content-Type的  HTTP  头来标记。下面是一个合法的HTTP请求消息： 

POST  /foobar  HTTP/1.1 
Host:  209.110.197.12 
Content-Type:  text/plain 
Content-Length:  12 
Hello,  World 

　　你可能已经注意到HTTP头只是一般文本。这使得用包检查程序或基于文本的Internet工具（如telnet）来诊断HTTP问题变得更容易。HTTP基于文本的属性也使得HTTP更容易适用于在Web开发中流行的低技术水平的编程环境。 

　　HTTP请求的第一行包含三个组件：HTTP方法，请求-URI，协议版本。在前面的例子中，这些分别对应于POST,  /foobar,  和  HTTP/1.1。Internet工程任务组(IETF)已经标准化了数量固定的HTTP方法。GET是HTTP用来访问Web的方法。  POST是建立应用程序的最常用的HTTP方法。和GET不一样，POST允许任意数据从客户端发送到服务器端。请求URI （Uniform  Resource  Identifier）是一个HTTP服务器端软件，它用来识别请求的目标的简单的标识符（它更象一个IIOP/GIOP  object_key  或一个DCOM  IPID）。在这个例子中协议的版本是HTTP/1.1，  它表示遵守RFC  2616的规则。HTTP/1.1比HTTP/1.0多增加了几个特性，包括对大块数据传输的支持以及对在几个HTTP请求之间保持TCP连接的支持。 

　　请求的第三行和第四行指定了请求体的尺寸和类型。Content-Length  头指定了体信息的比特数。Content-Type类型标识符指定MIME类型为体信息的语法。HTTP(象DCE一样)允许服务器和客户端协商用于编制信息的传输语法。大多数DCE应用采用NDR.。大多数Web应用采用text/html  或其它基于文本的语法。 

　　注意在上面样例中Content-Length头与请求体之间的空行。不同的HTTP头被carriage-return/行码序列划定界限。这些头与体之间用另外的carriage-return/行码序列来划定界限。请求接着包括原始字节，这些字节的语法和长度由Content-Length和Content-Type  HTTP  头来识别。在这个例子中，内容是十二字节的普通文本字符串“Hello   World”。 

　　在处理了请求之后，HTTP服务器被期望发回一个HTTP响应到客户端。响应必须包括一个状态代码来表示请求的结果。响应也可以包含任意的体信息。下面是一个HTTP响应消息： 

200  OK 
Content-Type:  text/plain 
Content-Length:  12 
dlroW  ,olleH 

　　在这个例子中，服务器返回状态代码200，它是HTTP中标准的成功代码。如果服务器端不能破解请求代码，它将返回下列的响应： 

400  Bad  Request 
Content-Length:  0 

如果HTTP服务器决定到目标URI的请求应该临时转向另外的一个不同的URI，下列响将被返回： 

307  Temporarily  Moved 
Location:  http://209.110.197.44/foobar 
Content-Length:  0 

　　这个响应告知客户，请求将能够通过重新传递它到在Location头中指定的地址来被满足。 

　　所有的标准状态码和头都在RFC  2616中被描述。它们中很少的内容与SOAP用户直接相关，但有一个明显的例外。在HTTP/1.1，底层的TCP连接在多个请求/响应对之间重用。HTTP  Connection头允许客户端或服务器中任何一方关闭底层的连接。通过增加下列HTTP头到请求或响应中，双方都会要求在处理请求后关闭它们的TCP连接： 

Connection:  close 

　　当与HTTP/1.0软件交互时，为了保持TCP连接，建议发送方加入下列HTTP头到每个请求或响应中： 

Connection:  Keep-Alive 

　　这个头使缺省的HTTP/1.0协议在每次响应后重新开始TCP连接的行为无法使用。 

　　HTTP的一个优点是它正被广泛的使用和接受。

#include  <stdio.h> 
int  main(int  argc,  char  **argv)  { 
char  buf[4096]; 
int  cb  =  read(0,  buf,  sizeof(buf)); 
buf[cb]  =  0; 
strrev(buf); 
printf("200  OK\r\n");p> 
printf("Content-Type:  text/plain\r\n"); 
printf("Content-Length:  %d\r\n",  cb); 
printf("\r\n"); 
printf(buf); 
return  0; 

　　一般来说CGI是花费代价最小的写HTTP服务器端代码的方法。实际上，每一个HTTP服务器端产品都提供了一个更有效的机制来让你的代码处理一个HTTP请求。IIS提供了ASP和ISAPI作为写HTTP代码的机制。Apache允许你用运行在Apache后台程序中的  C或Perl来写模块。大多数应用服务器软件允许你写Java  servlet，COM组件，EJB  Session  beans或基于可携带对象适配器（POA）接口的CORBA  servants。 

　　XML  作为一个更好的网络数据表达方式（NDR） 

　　HTTP是一个相当有用的RPC协议，它提供了IIOP或DCOM在组帧、连接管理以及序列化对象应用等方面大部分功能的支持。（  而且URLs与IORs和OBJREFs在功能上令人惊叹的接近）。HTTP所缺少的是用单一的标准格式来表达一个RPC调用中的参数。这则正是XML的用武之地。 

　　象NDR和CDR，XML是一个与平台无关的中性的数据表达协议。XML允许数据被序列化成一个可以传递的形式，使得它容易地在任何平台上被解码。XML有以下不同于NDR和CDR的特点： 

有大量XML编码和解码软件存在于每个编程环境和平台上 
XML基于文本，相当容易用低技术水平的编程环境来处理 
XML是特别灵活的格式，它容易用一致的方式来被扩展 

为支持可扩展性，在XML中每一个元素和属性有一个名域URI与它相联系，这个URI用xmlns属性来指定。 

考虑下面的XML文档： 
<reverse_string  xmlns="urn:schemas-develop-com:StringProcs"> 
<string1>Hello,  World</string1> 
<comment  xmlns=''http://foo.com/documentation''> 
This  is  a  comment!! 
</comment> 
</reverse_string> 

　　元素<reverse_string>和<string1>的名域URI是urn:schemas-develop-com:StringProcs。元素<comment>的名域URI是http://foo.com/documentation。第二个URI也是一个URL的事实是不重要的。在这两种情况下，URI简单地被用来消除元素<reverse_string>，<string1>，<comment>和任何碰巧有同样标记名的其它元素间的歧义。 

　　为了方便，XML允许名域URIs被映射为局部唯一的前缀。这意味着下面的XML文档在语义上等同于上面的文档： 
<sp:reverse_string 
xmlns:sp="urn:schemas-develop-com:StringProcs" 
xmlns:doc=''http://foo.com/documentation'' 
> 
<sp:string1>Hello,  World</sp:string1> 
<doc:comment> 
This  is  a  comment!! 
</doc:comment> 
</sp:reverse_string> 

　　后面的形式对作者来说更容易，尤其是如果有许多名域URIs在使用时。 

　　XML也支持带类型的数据表达。正在推出的XML  Schema规范为描述XML数据类型标准化了一个词汇集。下面是一个元素
<reverse_string>的XML  Schema的描述： 

<schema 
xmlns=''http://www.w3.org/1999/XMLSchema'' 
targetNamespace=''urn:schemas-develop-com:StringProcs'' 
> 
<element  name=''reverse_string''> 
<type> 
<element  name=''string1''  type=''string''  /> 
<any  minOccurs=''0''  maxOccurs=''*''/> 
</type> 
</element> 
</schema> 

　　这个XML  Schema定义阐述了XML名域urn:schemas-develop-com:StringProcs包含了一个名为<reverse_string>的元素，这个元素包含了一个名为string1的子元素（类型为string），它被0个或更多没有指定的元素所遵守。 

　　XML  Schema  规范还定义了一组内置的原始数据类型和建立一个XML文档中元素的类型的机制。下面的XML文档用XML  Schema类型属性来把元素和类型名联系在一起： 

<customer 
xmlns=''http://customer.is.king.com'' 
xmlns:xsd=''http://www.w3.org/1999/XMLSchema'' 
> 
<name  xsd:type=''string''>Don  Box</name> 
<age  xsd:type=''float''>23.5</name> 
</customer> 

连接XML文档事例到XML  Schema描述的新的一个机制在本文写作的时候正在标准化过程中。 

HTTP  +  XML  =  SOAP 

　　SOAP把XML的使用代码化为请求和响应参数编码模式，并用HTTP作传输。这似乎有点抽象。具体地讲，一个SOAP方法可以简单地看作遵循SOAP编码规则的HTTP请求和响应。一个SOAP终端则可以看作一个基于HTTP的URL，它用来识别方法调用的目标。象CORBA/IIOP一样，SOAP不需要具体的对象被绑定到一个给定的终端，而是由具体实现程序来决定怎样把对象终端标识符映射到服务器端的对象。 

　　SOAP请求是一个HTTP  POST请求。SOAP请求的content-type必须用text/xml。而且它必须包含一个请求-URI。服务器怎样解释这个请求-URI是与实现相关的，但是许多实现中可能用它来映射到一个类或者一个对象。一个SOAP请求也必须用SOAPMethodName  HTTP头来指明将被调用的方法。简单地讲，SOAPMethodName头是被URI指定范围的应用相关的方法名，它是用#符作为分隔符将方法名与URI分割开： 

SOAPMethodName:  urn:strings-com:IString#reverse 

　　这个头表明方法名是reverse，范围URI是urn:strings-com:Istring。  在SOAP中，规定方法名范围的名域URI在功能上等同于在DCOM  或  IIOP中规定方法名范围的接口ID。 

　　简单的说，一个SOAP请求的HTTP体是一个XML文档，它包含方法中[in]和[in,out]参数的值。这些值被编码成为一个显著的调用元素的子元素，这个调用元素具有SOAPMethodName  HTTP头的方法名和名域URI。调用元素必须出现在标准的SOAP  <Envelope>和<Body>元素内（后面会更多讨论这两个元素）。下面是一个最简单的SOAP方法请求： 

POST  /string_server/Object17  HTTP/1.1 
Host:  209.110.197.2 
Content-Type:  text/xml 
Content-Length:  152 
SOAPMethodName:  urn:strings-com:IString#reverse 
<Envelope> 
<Body> 
<m:reverse  xmlns:m=''urn:strings-com:IString''> 
<theString>Hello,  World</theString> 
</m:reverse> 
</Body> 
</Envelope> 

　　SOAPMethodName头必须与<Body>下的第一个子元素相匹配，否则调用将被拒绝。这允许防火墙管理员在不解析XML的情况下有效地过滤对一个具体方法的调用。 

　　SOAP响应的格式类似于请求格式。响应体包含方法的[out]和  [in,out]参数，这个方法被编码为一个显著的响应元素的子元素。这个元素的名字与请求的调用元素的名字相同，但以Response后缀来连接。下面是对前面的SOAP请求的SOAP响应： 

200  OK 
Content-Type:  text/xml 
Content-Length:  162 
<Envelope> 
<Body> 
<m:reverseResponse  xmlns:m=''urn:strings-com:IString''> 
<result>dlroW  ,olleH</result> 
</m:reverseResponse> 
</Body> 
</Envelope> 

　　这里响应元素被命名为reverseResponse，它是方法名紧跟Response后缀。要注意的是这里是没有SOAPMethodName  HTTP头的。这个头只在请求消息中需要，在响应消息中并不需要。 

　　让许多SOAP新手困惑的是SOAP中没有关于SOAP服务器怎样使用请求头来分发请求的要求；这被留为一个实现上的细节。一些SOAP服务器将映射请求-URIs到类名，并分派调用到静态方法或到在请求持续期内存活的类的实例。其它SOAP服务器则将请求-URIs映射到始终存活的对象，经常是用查询字符串来编码一个用来定位在服务器进程中的对象关键字。还有一些其它的SOAP服务器用HTTP  cookies来编码一个对象关键字，这个关键字可被用来在每次方法请求中恢复对象的状态。重要的是客户对这些区别并不知道。客户软件只是简单遵循HTTP和XML的规则来形成SOAP请求，让服务器自由以它认为最合适的方式来为请求服务。