其实，现在我要迁移到Web Service遇到的主要问题，我想隔离客户端和服务器端的真实协议。
就是说，现在我使用Remoting的时候，是基于接口的。把服务器提供的Service定义成Interface，Remoting Object实现这些Interface，然后把Interface部署到客户端，客户端UI访问服务器时，通过我的RemotObjectHelper实例化一个接口。这样做的好处就是，服务器的组件不需要部署到客户端，客户端只需要DataSet，Interface和自己的UI代码就行了。
而对于Web Service ，当然使用WSDL.EXE来直接生成代理，挺方便的。但是就和上面的基于接口编程方式有所不同了。当然，我还是实现了自己的WSProxy（继承于RealProxy），来动态的调用Web Service，而不生成代理的CODE。我以前看过一个人的解决方式是：使用CODEDOM动态生成Web Service代理的代码。
不知道，我这种基于接口的客户端调用方式，对于Web Service来说是否恰当？
不过使用基于接口的模式来调用服务器组件的好处是，UI可以完全不必在乎服务器是Remoting还是Web Service；只需要知道Interface，如果使用RemoteObjectHelper来实例化Interface（最终是以什么方式来调用服务器组件或者说服务，是根据配置来决定的）
“DTO是SOA不考虑的东西，J2EE有，ESP提到它.
Services expose Schema and Contract, not Object and Type ”
这个我也看过，也理解；但是在快速开发中，使用DataSet来绑定控件是最方便的。
那，我应该如何来平衡理论和现实呢？那我自定义的一些Type怎么办呢？比如，我自定义Principal对象怎么暴露给（传给）客户端呢？
还有一个问题就是，性能优化的问题。现在的Remoting使用是说的Surrogate方式来优化确实比Web Service快5倍左右。DataSet能这样优化的原因就是，DataSet默认情况下（就算是Binary的Formartter）也是按XML的方式来序列化的；结果包装后，DataSet的数据就能真正按Binary来序列化了。
如果在Web Service要这样优化，除了使用WSE的附件，还有什么方法呢？