我从来都不是 SOAP 的拥护着。甚至，我对 xml 都会有一种天生的恐惧。别问我为啥，我也不知道。性情如此吧。
这个故事是我看过的最搞笑，也最命中 SOAP 的要害的段子。看完之后，我突然明白我为啥不那么喜欢 SOAP、WSDL、UDDI之类的了。

翻译至此，大家一起乐乐。

原文在此：http://harmful.cat-v.org/software/xml/soap/simple

———-翻译分割线———-

S意味着Simple

Pete Lacey 编撰

在 Burton 团体的应用平台服务组内，支持 REST 的人和支持 SOAP 的人已经进行了很久的论战。在大多数情况下这只是外部论战的一个缩影。在最近的一次交锋中，当讨论到 SOAP 和 web 服务的复杂性时，SOAP 的一方这样说到“在之前的 WS 情形下，SOAP 确实是简单的。这也就是 S 所代表的东西。”

那么现在是历史课时间。这是 2000 年，一个倍受折磨的开发者遇到了一个问题……

开发者：好吧，我的老板这个周末正在打高尔夫，而现在我必须“括起，闭合”这个 SOAP 驱动的企业，但是我不知道 SOAP 是什么。你们能帮助我吗，SOAP 达人？

SOAP 达人：没问题。首先，SOAP 表示 Simple Object Access Protocol（简单对象访问协议）。

开：那么它简单吗？

S达：就像星期天一样简单，我的朋友。

开：太好了，跟我讲讲。

S达: 那么，就像它的名字说的那样，SOAP 用于访问远程对象。

开：就像 CORBA？

S达：跟 CORBA 像极了，只是更简单。为了代替那些不能穿过防火墙的复杂的传输协议，我们使用 HTTP。同时使用 XML 来代替二进制消息格式。

开：我很有兴趣。给我展示一下它是如何工作的。

S达：没问题。首先是 SOAP 封装。它非常简单。只是由头部和内容组成的 XML 文档。而在内容里可以构造你的 RPC 调用。

开：那么这些全部都是关于 RPC 的？

S达：当然。就像我说过的，你通过在内容中设定方法名和其参数来构造 RPC。方法名是外部元素，而每个子元素作为参数。而所有的参数可以由格式说明书第 5 章定义的类型来定义。

开：（阅读了第 5 章）好吧，这并不太糟。

S达：现在，当你的服务部署了以后，你定义这个端点。

开：端点？

S达：端点，服务的地址。你 POST SOAP 封装到端点的 URL。

开：那么如果我 GET 端点的 URL 会发生什么？

S达：不知道。GET 的使用是没有定义的。

开：呃。那么如果我将服务移到不同的端点会发生什么？我会收到 301 返回吗？

S达：不。SOAP 并不使用 HTTP 返回码。

开：那么，当你说 SOAP 使用 HTTP，就是说 SOAP 通过 HTTP 隧道传出。

S达：好吧，‘隧道’是个丑陋的词汇。我们更喜欢说 SOAP 是传输层透明的。

开：但是 HTTP 不是传输层的。它是应用层协议。不管怎么样，SOAP 支持其他什么“传输层”？

S达：好吧，官方来说没有。不过理论上支持任何方法。而有许多平台已经支持 JMS、FTP 和 SMTP。

开：有任何人实际在使用其他这些传输层吗？

S达：唔，不。不过关键是你可以这么做。

开: 当然。SOAPAction HTTP 头又如何，它代表什么？

S达：诚实来说，没有人真正确定。

开：还有这些‘actor’和‘mustUnderstand’属性，有人使用吗？

S达：不。这些没准备好。忽略它们吧。

开：好的，让我浏览一下。

（时间飞逝……）

开：好吧，这个基本上能够工作起来了，不过仅仅是一个点调用一个 SOAP 栈。同时，我不能说我喜欢这个远程过程调用和序列化对象的主意。

S达：远程过程调用！序列化对象！你从哪里得到的印象说 SOAP 是关于 RPC 的？SOAP 全部是关于基于文档的消息传递，我的朋友。

开：但是你刚才说——

S达：忘掉我说过的吧。从这里开始我们将围绕粗粒度消息——你喜欢那个名词“粗粒度”吗？消息匹配一个 XML Schema。我们将新的叫做 Document/Literal 模式，而旧的是 RPC/Encoded 模式。

开：XML Schema？

S达：哦，如今这个很流行。下一个爆发。看看吧。

开：（阅读了 XML Schema 说明书）我的天啊！亚历山大大帝也不能弄明白这个。

S达：别担心。你的工具会为你创建 schema。真的，全部都是关于工具化的。

开：那么这些工具会如何做呢？

S达：好吧，它们会反射你的代码（如果可能）并且自动生成一个兼容的 schema。

开：对我的代码进行反射？我之前认为它是关于文档的，而不是序列化对象。

S达：你没听我说吗？这全部都是工具的工作。不管怎么样，我们并没有期望你能够手写 XML Schema 和 WSDL。 除此之外，这都是底层建筑。你无需关注它。

开：哇哦，等等，那个词是什么？胃死兜？

S达：哦，我没有提过 WSDL？W-S-D-L。Web Services Description Language（Web 服务描述语言）。它是关于你如何定义数据类型、参数列表、操作名称、传输绑定和端点 URI 的，这样客户端开发者就可一访问你的服务。了解一下吧。

开：（阅读 WSDL 说明书）我相信编写这个的那个家伙已经被干掉了。这个甚至在内部都不一致。而且 HTTP GET 绑定做了什么。我想 GET 并没有定义。

S达：别担心那个。没人用那个。无论如何，你的工具会生成 WSDL，而在 WSDL 里会有 schema。

开：但是没有其他办法绕过去吗？难道不应该是我先设计好约束条件，然后生成代码吗？

S达: 好吧，当然，我想这听起来在原则上是对的。但这并不容易做到，而几乎没有 SOAP 栈支持先进行 WSDL 的开发。只让工具来承担这些好了。

开：还有一个问题。如果现在传递一个 XML Schema 兼容的消息，在哪可以指定操作名称？

S达：好吧，还记得 SOAPAction HTTP 头部吗？大多数人将其放到了这里。

开：大多数人？

S达：好吧，这个新模式实际上还没有在任何地方使用。

开：我同时注意到你们整个行业都建立在模棱两可之上的，有时有错误，还有一些定义的说明不是那么标准。事实上，SOAP 和 WSDL 说明书都还只是 W3C 记录，连工作草案都算不上。

S达：我们正在为此努力。

开：这能给我提供我之前所承诺过的互通性吗？

S达：当然。

开：我尝试一下。

（时间飞逝……）

开：现在变得丑陋了。我搭档的工具不能处理我的工具生成的 WSDL。不仅如此，它生成的 schema 是令人费解而且不可重用的。并且看起来没有工具认同如何处理 SOAPAction 头部是最佳的。

S达：听到这个真遗憾，伙计。从好的地方着想，没人再用 Doc/Lit 模式了。为了让无依赖传输回来，现在我们全都使用了 wrapped-doc/lit。这听起来很酷吧：wrapped-doc/lit？

开：这是什么？

S达：好吧，这和 Doc/Lit 类似，只是你取得整个消息并且将其包裹到有着相同名字的元素中作为操作。这样操作名称就回到消息中它应该在的地方。

开：好的，关于这些的说明在哪里？

S达：哦，这个没有说明。只是微软这么做而已。看起来是个不错的主意，所以现在所有酷毙了的小子们都这么做。然而，有一个关于此的新东西。我想你可能会喜欢它。称为 Web 服务互通性小组，或者叫做 WS-I。他们要做的工作就是从 SOAP 和 WSDL 说明书中移除那些模凌两可的东西。我知道你相当中意说明书。

开：所以，换句话说，这个说明书糟糕到你们需要一个标准化实体来对标准进行标准化。天啊。好吧，这能解决我的互通性问题吗？

S达：哦，当然。只要你使用 WS-I 兼容的 SOAP 栈，避免使用 8/10ths 的 XML Schema，不要使用任何不寻常的数据类型，并且不要按照 WebSphere 和 Apache Axis 来工作。

开：那么就使用 wrapped-doc/lit 来解释它？

S达：呃，不。不过也没问题。你的工具明白它（有些心虚）。大多数情况下，不管怎么说。

开：让我总结一下。SOAP 的定义总是在不断变化，不管怎么样 SOAP 是简单的，并且不再意味着对象访问——虽然这是工具仍然在做的事情。

S达：差不多是这样，但是我们总是带领着你在这条路上前进。我们已经抨击过 SOAP 缩写的含义了。

开：真的！那么它现在到底什么意思啊？

S达：什么意思都没有。

开： （眨巴着大眼睛）

S达：让我告诉你关于 UDDI 吧。

———-翻译分割线———-

现在知道 REST 和 json 的魅力了吧？那些坚持使用 SOAP 的同学们，得有一种什么样的探索精神啊！