下面的部分试图提供一些我们为什么愿意忍受这个极限的原因。它的内容是用来展示这些好处，在哪些情况下克服这些缺点。

    客户端/小应用程序 通过广域网或互联网

    •企业内部网

    可能没有防火墙

    •客户端使用ISP(网络提供商)

    你的DMZ(开放主机)使用了两个防火墙，一个是在网络和你的DMZ之间，另一个在DMZ和你的企业内部网之间。如果你的应用服务器是在DMZ上，那么它就是一个，如果你的应用服务器在企业内部网上(这种可能性更大)，那么它就是两个。

    •企业客户

    这个和上面的很像，除了客户端没有直接连接到网络。它通过了它的企业防火墙，也很可能穿过了DMZ(两个防火墙)。那么，在这种情况下我们可能有4个防火墙。

    正常情况下，任何防火墙应该被配置来容许小应用程序向下载applet的服务器开启一个HTTP连接。你能在那个服务器上放置你的SOAP网关，因此，尽管在防火墙存在的情况下，你的小应用程序仍然能和应用服务器通信。防火墙和IIOP不能很好的融合。很少有防火墙会让IIOP端口为通信开放。这个意味着IIOP很可能被客户端和服务器之间的防火墙所堵塞。上面最坏的情况将意味着你需要说服这四个防火墙的管理员在两个不同的公司打开一组端口。

    •首先，为了使用你的应用，强制你的客户改变他们现有的基础安全架构，这成为它们不使用它的原因之一。

    •其次，这些人妄想在他们的防火墙上正当地打开任何出入的端口。

    这意味着它作为你的applet协议，不是一个好选择。为了使用IIOP，接下来，有一段代码需要你用applet下载。你将需要向你的applet打包你的EJB的运行时和beans的存根。这里可能有大量的代码。对Java1.1 JDK而言，你也需要RMI/IIOP的附件。但是这有一个
小问题。这需要本地化的代码库，ioser。 你又下载不了这个。即使你能，你也可能在Java1.1 RMI/IIOP和Java1.2 RMI/IIOP之间的互操作性上遇到些问题。RMI实际上是一种比纯RMI/IIOP更友好的小应用程序技术，因为它是100%纯Java的，可以轻松地下载到小应用程序中。尽管，在1.1和1.2(串行化)之间有些兼容性问题。这意味着给你选择RMI或有优势的RMI/IIOP的J2EE服务器或使用小应用程序时没有用到的。当然，如果你的J2EE服务器有个用于RMI/IIOP的100%的Java运行时，那这点没关系。你的EJB厂商也很可能没有提供一个1.1兼容的运行时。这意味着你的客户端需要在他们的浏览器上安装1.2桥。这也可能会有问题。