2 提供一些粗粒度的接口。在一个WS的调用周期中，SOAP中除去有效负载，光是SOAP头也是占用一定网络开销的，尤其是在有security的情况下。另外，client有可能网络带宽很小，比如只有几k【不是玩笑】。这个时候，让珍贵的网络去传输本质上没有意义的各种协议头就是极大的浪费。因此，可以在一个WS调用时多返回一些数据。
3 不要使用互通性不好的类做为接口的参数，比如List,Collection,当然数组是通用的。有些类在同一平台当然互通互联的非常好，但是WS的设计是要跨平台的使用，即使现在client和server在同一平台，并不代表以后在同一平台。需求总是变化的。
4 一个接口在语义上就是一个完整的service，不存在说调用Service A之前必须调用Service B。当应用security时比较特殊，但是security应该做为一种底层框架存在。对于服务编排，我的理解是小服务组合成大服务，而不是几个不完整的服务组合成一个完整的服务。
5 仔细定义服务的fault。和一般的Exception设计不太一样，边界上fault不宜设计的过于复杂。
6 当性能有问题时，可以考虑在SOAP上压缩。SOAP消息有时候是会很大的，几M，甚至10M+都是有可能的。而SOAP上一般为字符，字符的压缩比可是很高的。当有二进制文件传输时，可以考虑先转成字符串，比如Base64，然后压缩。
7 仔细考虑WS上的事务。全局性的事务在技术上相对是比较复杂的，有时只能通过自定义特定的rollback接口实现，增加了server和client的编程复杂性。
8 永远记着服务只有被调用才有价值，有时候是要用client的需求来驱动一下服务中接口定义的修改。一般先提供服务的一套最小接口集合，在理论上可以完成该服务的任何操作。后期根据client的需求，可以做一些接口级的修改，主要是加一些粗粒度的接口。虽然有可能破坏接口定义的整洁。但是还是那句话，服务只有被调用才有价值，client调用的舒服则更有价值。一般系统的client不会特别多的，这样做是值得的。当然，如果是开发通用的service平台，则更应该考虑service的设计，毕竟，不能为了讨一个客户的欢心，丢到其他所有人。
WS的接口设计就是一个多方面的考量后的妥协。好的程序员就是在种种考量后作出一个大家觉得都还不错的方案。
程序就是一门平衡的艺术。
摘自：http://zhang-xzhi-xjtu.iteye.com/blog/353874