SOAP基本是一种RPC的XML编组机制。尽管多数情况下它是和HTTP一起广泛使用，但它并没有指定某个传输协议。它也可以通过一个简单的TCP/IP接口或JMS消息来编码一个RPC调用。

    人们总是倾向于使用最新的技术，除了“只是因为”没有别的原因。这篇文章告诉了我们SOAP将适合与会话bean互相协调，以及什么时候使用它是没有意义的。

　　操作的的基本知识概览

　　你在服务端需要一个分配器。这个分配器从传输层收到一个SOAP包。一个SOAP包就是一个对需求服务编码的XML文档，关于那个服务的方法和这个方法的输入参数。然后它解码“包”并调用SOAP服务底层真正的java方法。它不必一定是java，但在这篇文章中，我将用java作为服务器语言。这个解码和执行java方法通常使用像IBM 可利用的SOAP4J包——来自他们alphaworks网站的现成组件。

　　底层代码随后执行并返回到SOAP运行时。它捕捉任何异常，返回对象以及输出参数。然后将这些东西编码后写入响应XML的文档，用传输协议将这个文档传送给客户端，像HTTP响应就用HTTP协议传输。基本情况就是那样。所以，SOAP运行时为请求的解析提供所有编码，调用一个适配器然后编排响应信息包。我们提供了代表调用底层真实对象的适配器。IBM 的SOAP运行时引用HTTP传输代码。但是，你自由使用你想用的传输协议，对它来说所有的钩子都能用来展现。所以，SOAP基本上给我们一种简单的RPC机制。它可以用来替代RMI/IIOP，但有一些东西必须记住。确实，微软的 .NET 正沿着这条路走，但我认为这是盲目使用造成的错误，支持可插入协议堆栈的能力（允许DCE或IIOP或其他某些东西）将是微软的事，或确实是J2EE厂商，应该规定给开发者更多性能选择。

　　我想说下面的叙述通常情况下适用于SOAP实现。

• 　　SOAP在管道上将比RMI/IIOP消耗更多的带宽。这是理所当然的。它是基于XML的，所以它将比像CDR或XDR这样的二进制编组更大。
•     SOAP在编组上比RMI/IIOP开销更多。
  　　由于跟RMI/IIOP比它更大所以有更多的字节推向管道。这是个ASCII协议，因此数据需要被转化成字符串而不是以二机制形式传输。这两种都消耗宝贵的服务器运行周期。
•     它要求更多的内存。
  　　构建这些字符串和解析它们将使用更多的内存，并且和IIOP ORB使用的垃圾比很可能留下更多的垃圾。
•     它不是一个原生的EJB协议。
  　　与仅仅使用免费的RMI/IIOP相比，在你那边它要求更多的工作。

　　那么，有了以上所有这些，我希望它比盲目地使用SOAP/HTTP替代的RPC机制RMI/IIOP的更清楚，这种RPC将比支持更多资源，开发起来更复杂的服务器端让系统变得更慢。它还要求你写将SOAP运行时和你的对象连接起来的代码。现在没有可用的工具来生成这部分代码。我期待这些代码出现，但至今还没有，所以你需要写一个生成器或手工编写这个代码。如果你有更复杂的接口，这个代码量会很大。