SOAP净化有线协议(一):SOAP基础知识

　　一、SOAP简介

　　SOAP用XML作为数据编码格式。用XML作为数据编码格式并非SOAP的原创，实际上这是一种相当自然的选择。XML-RPC和ebXML也同样使用XML。

　　请考虑下面的Java接口:

Listing 1

public interface Hello
{
public String sayHelloTo(String name);
}

　　客户程序在调用sayHelloTo()方法时提供了一个名字，它希望从服务器接收到一则个性化的“Hello”信息。现在，假定RMI、CORBA和DCOM都不存在，开发者必须负责串行化方法调用，并把消息发送给远程机器。几乎所有的人都会说“这该使用XML”，我同意。因此，让我们先从对服务器的请求格式开始。假设要模拟sayHelloTo("John")调用，我打算发送的请求是:

　　Listing 2

John

　　在这里，我把接口的名字作为根结点。另外，我还把方法名字和参数名字都当作节点。接下来，我们要把这个请求发送给服务器。我们不创建自己的TCP/IP消息，而是使用HTTP。因此，下面的步骤应该是把请求封装成HTTP POST请求格式，然后把它发送给服务器。实际创建该HTTP POST请求的详细过程在本文后面介绍，现在，我们先假定它已经创建完毕。服务器接收到了这个请求，解码XML，然后再以XML格式向客户程序发送应答。假设应答内容如下:

　　Listing 3

Hello John, How are you?

　　根节点仍然是接口的名字Hello。但这一次，原来对应着方法的节点名字不再是sayHelloTo，而是方法的名字加上“Response”字符串。客户程序知道自己调用了哪一个方法，要找出被调用方法的返回值，它只需查看名字为方法名字加上“Response”字符串的元素。

　　以上就是SOAP的根本思路。Listing 4显示了同一请求用SOAP XML编码之后的结果:

　　Listing 4

　　第二，注意Listing 4大量地应用了XML名称空间。SOAP-ENV映射到名称空间http://schemas.xmlsoap.org/soap/envelope/，xsi映射到http://www.w3.org/1999/XMLSchema-instance，而xsd映射到http://www.w3.org/1999/XMLSchema。这三者是所有SOAP文档都拥有的标准名称空间。

　　最后，在Listing 4中，接口名称(即Hello)不再象在Listing 2中那样成为节点的名字;相反，它引用了一个名称空间nsl。另外，参数的类型信息也随同参数的值一起发送给了服务器。注意信封(Envelope)encodingStyle属性的值。这个属性值设置成了http://schemas.xmlsoap.org/soap/encoding/。这个值告诉服务器用来编码(即串行化)方法的编码方式;服务器需要这个信息，以便正确地解除方法的串行化。对于服务器来说，SOAP文档的自我描述能力是相当完善的。

　　对于上面的SOAP请求，服务器的应答如下:

　　Listing 5

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-nstance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">

xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
Hello John, How are you doing?

　　Listing 5与Listing 4的请求消息类似。在上面的代码中，返回值(即个性化的“Hello”消息)包含在Body区。SOAP消息文档的格式非常灵活。例如，编码方式不固定，而是由客户程序指定。只要是客户程序和服务器都认可的编码方式，可以是任何合法的XML文档。

　　另外，分离调用环境信息意味着方法本身并不关心这类信息。在当前的市场上，主流应用服务器都遵从这一理念。早先，我曾经指出环境信息可以包含事务和安全方面的信息。事实上，环境可以涵盖几乎所有的东西。下面是一个SOAP消息头的例子，它带有一些事务方面的信息:

　　Listing 6

5

　　名称空间t映射到了与特定应用有关的URI。这里的5表示的是该方法从属于其中的事务ID。注意SOAP信封mustUnderstand属性的应用。这个属性被设置成了1，它表示服务器要么理解并按照要求处理该事务请求，要么表示无法处理该请求;这是SOAP规范所要求的。

　　二、错误处理

　　Listing 7

SOAP-ENV:Server
Server Error



Sorry, my silly constraint says that I cannot say hello on Tuesday.


1001

　　我们来分析一下http://schemas.xmlsoap.org/soap/envelope/名称空间定义的Fault元素。Fault元素总是Body元素的直接子元素，所有的SOAP服务器必须始终通过该元素报告所有错误情况。Fault元素必须包含faultcode和faultstring元素，不能有例外。faultcode是一个能够标识问题的代码;客户程序按照SOAP规范的要求利用faultcode进行算法处理。SOAP规范定义了一小组错误代码供用户使用。另一方面，faultstring是供人类阅读的错误信息。

　　Listing 7的代码还包含了一个detail元素。由于错误在处理SOAP消息的Body区时出现，detail元素必须出现。正如你将在本文后面看到的，如果错误在处理Header区时出现，detail元素不应出现。在Listing 7中，应用利用detail元素提供当前错误更详细、更自然的解释，即星期二不允许说Hello。SOAP还提供另外一个面向具体应用的错误代码，即半可选的faultfactor元素，但上面的错误信息中没有显示这个元素。之所以称这个元素是半可选的，是因为如果错误消息不是由请求最终处理点的服务器发送，即由一个中间服务器发送，则错误消息必须包含该元素。SOAP对faultcode元素不应出现的情形没有作任何规定。

　　在Listing 7中，错误起源于方法调用本身，处理该方法的应用导致了这个错误。现在，我们来看一下另一种类型的错误，这种错误由于服务器不能处理请求头信息而导致。举例来说，假设所有的Hello消息必须在一个事务环境之内生成，则请求类似于:

　　Listing 8

　　Listing 9

SOAP-ENV:MustUnderstand
SOAP Must Understand
Error

　　上面的代码类似Listing 7显示的错误信息。但应该注意的是，detail元素不再出现。正如我在前面指出的:SOAP规范规定，如果错误在处理Header区的时候出现，则错误消息中不应包含detail元素。事实上，我们可以根据detail元素是否出现，迅速判定错误是在处理Body区还是在处理Header区时出现。

　　三、SOAP与HTTP

　　在第一个例子中，我通过HTTP把定制的XML请求发送给服务器，但没有详细介绍这么做涉及到了哪些操作。现在我们回过头来看那个问题。怎样才能把一个SOAP请求(而不是定制的XML)通过HTTP发送给服务器?SOAP很自然地遵循了HTTP的请求/应答消息模型。这个模型在HTTP请求中提供SOAP请求参数，在HTTP应答中提供SOAP应答参数。实际上，SOAP 1.0特别指明HTTP作为它的传输协议。SOAP 1.1略有放松。虽然SOAP 1.1仍旧可以使用HTTP，但它也可以使用其他协议，比如SMTP。在这个系列的文章中，我只讨论通过HTTP使用SOAP的情形。

　　让我们返回Hello示例。如果我们通过HTTP把SOAP请求发送给服务器，则代码应该类似于:

　　Listing 10

　　第四行是SOAP特有的，而且它是必不可少的。SOAPAction HTTP请求头指明了SOAP HTTP请求的目标，它的值是一个标识目标的URI。SOAP不对该URI的格式作任何限制，实际上，这个URI甚至不必对应某个实际的位置。

　　SOAPAction的一个可能的应用是，防火墙检查该请求头的值，决定是否允许请求通过防火墙。

　　一旦服务器处理完请求，它将向客户返回一个应答。应答的内容如Listing 11所示(假设没有出现错误):

　　Listing 11

HTTP/1.0 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: 615
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">

xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
Hello John, How are
you doing?

　　这个SOAP应答与Listing 5所显示的一样，但前面加上了一些HTTP特有的代码。由于没有出现错误，第一行代码显示应答状态是200。在HTTP协议中，200应答状态代码表示“一切正常”。如果在处理SOAP消息(Header区或者Body区)的时候出现了任何错误，则返回的状态代码将是500。在HTTP中，500状态代码表示“internal server error”。此时，上述SOAP应答的第一行代码将是:

HTTP 500 Internal Server Error

　　四、HTTP扩充框架

　　许多应用对服务的需求超过了传统HTTP提供的服务。其结果就是，这类应用扩充了传统的HTTP协议。然而，这种扩充是应用本身私有的。HTTP扩充框架试图确立一个通用的HTTP扩充机制，从而解决这个问题。HTTP扩充框架的扩充之一是增加了一个M-POST方法，其中的M表示Mandatory(必须遵循的，强制的)。如果一个HTTP请求包含至少一个强制的扩充声明，那么这个请求就称为强制的请求。引入强制的扩充声明通过Man或者C-Man头进行。强制请求的请求方法名字必须带有“M-”前缀，例如，强制的POST方法称为M-POST。

　　SOAP 1.0要求客户程序首先发送一个HTTP POST请求，只有当服务器返回错误510时才发送M-POST请求。SOAP 1.1不再对客户作这种限制，也就是说，SOAP 1.1允许客户从发送任何一种类型的请求开始。下面的请求就是迄今为止我们一直在讨论的那个请求，但它现在是M-POST格式:

　　Listing 12

　　一旦服务器处理完该请求，它将返回一个应答给客户。应答内容类如(假设没有出现错误):

　　Listing 13

HTTP/1.0 200 OK
Ext:
Content-Type: text/xml; charset="utf-8"
Content-Length: 615
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">

xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
Hello John, How are
you doing?

　　同样地，Listing 13显示的应答类似于对普通POST请求的应答(如Listing 11所示)，两者的不同之处在于Ext域。

　　在通过HTTP使用SOAP的过程中，我们欣喜地看到，实际的SOAP消息(SOAP信封和它里面的所有内容)总是保持不变，就如消息尚未加载HTTP协议时一样。根据这一事实可以推断出，HTTP不是能够与SOAP协作的唯一协议。例如，SOAP可以方便地和SMTP协议或者其他定制的私有协议一起运行。唯一的要求是两者——客户端和服务器端——都理解该协议。

　　五、SOAP的特点:简单

　　至此为止，我们讨论了SOAP定义的方方面面，但有许多领域的问题SOAP没有定义。SOAP规范的创立者明确地排除了一些关系密切的领域，比如构造对象模型，还有其他许多已经确立的标准。

　　造成这种现象的原因可以从分析SOAP的目标理解。SOAP的目标除了扩展性之外，另一个主要的设计目标是简单。为了保持SOAP简单，SOAP规范的创立者决定，只定义那些对于创建一个轻型协议来说绝对必须的东西。例如，SOAP没有定义/指定任何有关分布式垃圾收集、类型安全或版本控制、双向HTTP通信、消息盒(Message-box)运输或管道处理、对象激活等方面的内容。SOAP的目标就是成为一种简单的协议——一种在任何操作系统上，单个开发者能够用任何语言化数天时间实现的协议。考虑到这一点，SOAP在许多方面没有作出明确定义实际上是一件好事，因为在构造分布式系统时，所有现有的技术都可以方便地采用SOAP，即使不同技术之间的差异象CORBA和DCOM的差异那样明显。