Web服务框架与基于HTTP协议的自定义XML？

Question

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

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

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

Answer 1

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

IMO，如果您没有工具-两种方法似乎都需要很高的维护。 选择最短的路径。 如果您有工具支持，请走WS路线，让工具承担繁重的工作。

Answer 2

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

Answer 3

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

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

无论如何（至少在.NET世界中）描述符文件应从服务器处理。

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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