我正在寻找有关何时使用Web Services框架以及文档详尽的自定义协议(该文档使用HTTP上的XML进行通信)的特定指南。

我不关心性能，而关心客户端和服务器端代码的可维护性和易于开发。例如，我可以开发一个自定义协议，该协议可以与XML通讯，而无需编写大量Web服务框架似乎需要的描述符文件。

请列出Web服务带来的特定功能。

解决方案

RESTful Web服务的礼仪很低。如果像Atom Publishing Protocol这样的东西对我们有用，那就是我要采取的方法。

WS的好处通常来自工具支持以生成客户端，服务器存根和描述符，以及管道的好处，例如安全性，加密和其他可扩展性。没有工具，滚动和处理WS请求的负担就很大，结果的价值也就相对较低。

IMO如果我们没有工具，那么这两种方法的维护成本似乎都很高。选择最短的路径。如果我们有工具支持，请走WS路线，让工具承担繁重的工作。

如果我们没有性能-问题或者其他怀疑WS无法胜任的工作，我们为什么考虑重新发明轮子呢？

对于客户而言，这(在大多数情况下)将是使用服务的最简单方法。

无论如何(至少在.NET世界中)，描述符文件应从服务器进行处理。

这是经典的构建与购买问题。即使该框架是免费的，也需要在学习和配置上进行投资。购置框架具有规模经济性，因为它会从维护它的实体那里得到增强，但是我们并没有推动这一过程。它可能会添加我们想要的功能，或者破坏代码的功能，我们无法事先告知。建立自己意味着启动时间和以后的维护。取决于员工，专家可能会继续前进，并且随着代码的陈旧，维护它的知识也将不断更新。这个问题有很多利弊，在选择方向之前，我们应该考虑所有这些利弊。

我想说，设计业务逻辑并在以后插入不同的访问方法或者框架是一个好主意。有不同的最终用户想要/要求不同的访问方法(比如SOAP，REST或者尚未发明的其他技术)，这并非闻所未闻。

我们在生产系统之间大量使用内部Web服务，它们都是基于HTTP的原始XML，看不到SOAP。我们发现，WS堆栈的繁琐本质，甚至是XFire等更好的堆栈也不值得。

我之前曾是Web服务的客户端，该服务只是通过HTTP发送的XML。我发现使用它非常简单。我使用JiBX从Java对象创建我的XML请求，并且也使用JiBX将XML响应解压缩到Java对象。