Web Service调用方式的烦脑

根据客户的要求，新项目要采用智能客户端的架构，如果客户端与服务端，都用的是.net，可以考虑用.remoting、WCF之类的，如果都是java（服务端SSH，客户端Swing），则可考虑使用JMS，但客户与本公司技术总监讨论后，要采用服务端java(SSH+Xfire)，客户端C#+WinForm的框架，客户端与服务端的通讯方式要求采用Web Service。

现在有两种方式实现客户端与服务端的通讯：

1、采用多个Web Service接口，即一个应用层对象对应一个Web Service接口，一个应用层方法对应一个Web Service方法，参数与返回值根据业务需求做成简单对象（VO之类的），例如Book  BookStore.addBook(Book book)；

2、所有向外发布的应用层服务采用一个统一的Web Service接口，即在应用层上再加一个消息层，此层只有一个Web Service接口，例如：String sendMsg(String msgCode,String xmlDoc)，在消息层里根据客户端传来的msgCode，将xmlDoc中的内容根据系统对各个结点标签的定义（例如预先定义好<book>标签及其子结点）拼装成VO，然后选择合适的业务层方法调用，并将返回消息也封闭成XML，返回给客户端解析并进行后续处理。对于上面的addBook方法，可以定义一个msgCode="addBook"，将Book对象序列化在在xmlDoc中，如<book><bookname>Java编程经典</bookname><author>John</author></book>之类的。

第一方式比较正规，应用服务器容器内的调用与跨平台的远程调用可以使用相同的API，开发人员使用与理解比较方便。但对于不同语言与不同Web Service实现框架间的交流不是很方便（遵循Web Service规范的严谨程度不是太统一），比较复杂的对象可能会在解析时出错。特别是在传递对象数组与List对象之类时，对于比较古老与古怪的语言与Web Service实现可能有点麻烦。

第二种方式实际上是对Web Service的一种退化使用，SOAP被弃用了，只是挂了个Web Service的名字，实际上是将Web Service作为一种字符串通讯协议在使用。在服务端，使用这种方式还要加上一个消息处理层，要进行消息代码到应用层接口方法的判断及XML文档到VO的转换，会降低处理效率、并且容易出错（当然可以写个通用方法来处理）。但其长处就在于方便简单，一方面只需要给客户端程序员（无论是公司内部，还是第三方公司的）一个接口方法senMsg()就行了、一个各种应用层服务的方法的消息代码列表、以及消息XML格式的消息体即可，客户端程序员不需要有很“重”的Web Service实现框架即可访问服务端；另一方面双方只要实现能传递字符串的Web Service就行了，以避免文档格式太复杂，造成解析出错的问题，也就是兼容性很好啦。安全方面的认证、加密和防篡改也可以直接从字符串下手，不用复杂沉重的Web Service安全机制，实在不想操心，也可以直接上个SSL万事大吉。

第二种方法还有一个好处，就是不用频繁发布Web Service接口，在客户端要实现实现一个接口还是要费一番手脚 的。做好一个，封装好，所有客户端开发人员都可以直接用，只是消息参数有不一样罢了。对于xmlDoc参数，可以花点时间做一个好点的工具方法，将C#的VO通过反射直接转换成xmlDoc了。

对于Web Service接口，加上访问频率与访问量的限制很重要，怕客户端的“刷机”呀！要规定一分钟内某一客户端（用IP地址？怕有网关吧，还是用客户端ID或者用户ID来判断？）访问次数，还有一天内合计访问次数限制，访问情况要保存在服务端的系统日志数据库内或者session内，在消息层就进行判断与处理。