企业内部网的胖客户端

  　如果你确定客户端不会使上面的例子退化，我在这就不用它。如果你确定使用它不会发生，那么就使用RMI/IIOP，这是最简单的。否则，无论如何要使用RMI/IIOP，但是在你的服务器和客户端之间保持一个很简单的请求/答复交互。那样，在不需要重写你应用的情况下，应该能够随后切换到SOAP方式。为什么是一个简单的请求/响应接口？对我来说这有三个层次的接口。

• 　　细粒度分布

    一个非常细的接口在任何情况下都是个坏主意。从局域网(LAN)和服务器端，你会招致很多天花板效应，你会发现你花更多的CPU周期在容器存根上，作为你业务逻辑的比率，从你的应用中抢走周期。如果在这种情境下剖析你的应用，那么你将很可能找到CPU时间的大百分比，就是比你的代码花费更多时间的EJB运行时。你需要用粗糙的方法平衡这种开销。

• 　　中等粒度

    一个中等粒度的接口作为还不错的用途，通常由内部网应用推荐，但在企业内部网上工作还不错。这里一个企业内部网是个局域网或相关的敏捷的企业广域网。

• 　　粗粒度

    你用这个类型的接口或另一种你能轻松地将中等粒度接口转变为相应的粗粒度接口构建服务器端代码，通过使用会话beans作为现有中等接口的门面。这些会话beans应该有很简单的接口，能被用JMS或SOAP包装。

　　非java客户端

　　有时RMI/IIOP同意和非java语言互操作性伴随一些限制性。

    客户端真正需要Corba2.3 ORB

　　否则，在接口签名方面会遇到一些限制。没有值的对象，没有容器，没有数组等等。

　　有限的安全性支持。

　　你几乎失去安全性。这是非常严肃的问题。通常，通过在和EJB服务器同样的厂商中使用ORB是获得安全性的唯一方式。这里的问题是很多EJB服务器没有提供单独的ORB（BEA和IBM）。 Lona/Visigenic确实提供了一个单独的ORB，但我不确定只靠这些厂商是否有可能。

　　SOAP为这些客户端提供了一个好的解决方案。HTTP是个实现起来非常简单的协议，并且你可能找到一个用来实现它的库。SOAP协议的上层实现起来没有那么困难，所以你可能会找到现成的SOAP。微软在Windows平台上提供了这个。关于HTTP的问题是安全性将发挥作用，并且和由你应用服务器提供的安全机制集成在一起。在服务器端实现了你的请求分配器的servlet容器强制HTTP验证。客户端能轻松地处理返回的代码并成功验证。

　　基于证书的验证

　　如果你需要基于证书的验证，你也可以使用HTTP/SSL和证书。你只需要一个支持证书的客户端SSL实现。这在WebSphere V3.5中是新的特性。在WebSphere V3.2中它不起作用。但是，对于胖客户端基于证书的验证WebSphere V3.5是不支持的。如果你想证书验证那么HTTP或HTTPS是你唯一的选择。

　　这很划算。你现在用java和非java 客户端能有很强的安全机制（验证和加密）。

    本文为系列文章，如有疑问请继续阅读：

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

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

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