在本系列文章的《哪些情况下适用SOAP实现之非java客户端》中，我们介绍了企业内网胖客户端以及非JAVA客户端的应用，下面我们将继续为您介绍VB和COM客户端中SOAP的实现。VB和COM客户端

    你能尝试使用COM-Corba或COM-EJB桥或Sun的ActiveX/Bean桥，但当你使用微软类型的客户端，假定你能从微软那获得一个很好的SOAP/HTTP实现，那就不要费力气。在服务器端实现一个SOAP适配器并在这两者间使用SOAP。所有的微软办公软件和VB类型的应用将支持SOAP。另外，你不需要在客户端安装任何软件，它应该是内置的。这意味着如果我们向服务器链接一个Excel文档，任何安装了Excel的人都能打开并使用这个服务器。用自身的HTTP和XML构建的非SOAP RPC机制实现这个。如果你实现了一个能嵌入到电子表格纯VB SOAP运行时，只要微软向办公软件加入对SOAP的支持，那么你应该同样能做到这一点。

　　未来

　　现在，我想EJB服务器准备利用SOAP但是在轻松使用前它可能还需6个月的时间。这是因为我只是看到了厂商所采取的RMI/IIOP的尾端方案。如果你想支持SOAP，那么你将需要手写或生成一个将穿过的桥请求。这意味着你只需像IIOP一样接收并解析请求，在返回的路径上反之亦然。因此，你可能两次编组，这会降低性能。

　　LONA提前想到了一个厂商。他们的EJB服务器是基于其出色的ART ORB，它的突出特点是可插拔的协议栈。这意味着它们可能收到SOAP请求，并直接分配它到bean的实现中，因此避免IIOP完全分离。在桥方法方面这可能给其一个性能优势。但是，其他厂商可能只是简化了他们的容器，也来为SOAP做同样的事情，并获得同样的效率, 也就是他们的容器将同时监听IIOP和HTTP请求，并直接向你的bean分配这些请求。

  　总结

  　那么，现在这是我将考虑使用SOAP和EJB服务器的情景：

  　如果你的客户端是windows类型的客户端或在广域网或互联网的另一端。
  　如果你有非Java或微软的客户端。
    你需要安全性和/或用非java客户端加密。

    由于同样的原因，在我的系统中，我不会使用SOAP作为的通信方式。我也不会在子系统内部的边界使用XML。因为它比RMI/IIOP或比串行化java对象的更庞大，需要更多开销来处理。当然，理论上，为了保持前卫你能这么做，但我恐怕你现在在实践中应该明白，它不会分的这么清楚。

    本文章为系列文章，如果您有任何疑问，请阅读：

    哪些情况下适用SOAP实现？（一）

    哪些情况下适用SOAP实现？（二）

    哪些情况下适用SOAP实现？（三）

    哪些情况下适用SOAP实现之非java客户端