Java 远程技术的优点 - Web 服务替代方案？
作为一名初级开发人员，我曾多次设计、实现和使用 Web 服务。但我越来越怀疑用于通过网络传输数据的底层 SOAP\XML。鉴于此，我一直想了解其他一些远程技术，例如 RPC 和 REST。 我对网络服务的替代方案知之甚少 - 但我已经开始学习。最后，我们在组织中所做的任何 Web 服务都不会在我们的网络之外进行通信 - 它们主要用作服务端点。
考虑到所有这些，Web 服务的替代方案是否可行？我可能还缺少其他东西吗？
谢谢！
As a junior developer I've designed, implemented and consumed web services quite a few times. But I am growing increasingly suspect of the underlying SOAP\XML used to transport data over the wire. Given this, I've been wondering about a few other remote technologies such as RPC and REST. I know little about alternatives to webservices - but I've been starting to learn . Finally, none of the webservices that we do in our organization talk outside of our network - they are mainly used as service endpoints.
With all of this in mind, are the alternatives to webservices viable solutions? Is there something else I might be missing?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简短的回答：
替代方案比当前的 SOAP/XML 混乱更糟糕。是的，可以做到，但并不漂亮。
长答案：
我写过 COM/DCOM、CORBA、RPC、EJB，甚至套接字，从我的角度来看，您所质疑的方法可能有粗糙的边缘，但仍然轻而易举地击败了旧技术。
使用 SOAP/XML/WSDL 等的 Web 服务蓬勃发展是有原因的。它们在多个方面减少了管理它们的痛苦。
能够以声明方式定义服务，然后拥有所有生成的管道并不新鲜，RPC 也有可以做到这一点的工具。然而，即使有了这些工具，RPC 仍然需要大量的手动编码来连接客户端和服务器端之间的所有管道。更不用说 RPC 确实没有解决如何定位服务的问题。
这些较旧的技术都可以以自己的方式完成任务，但由于开发困难、维护脆弱以及没有提供服务位置的标准方法，它们都没有真正提供完整的解决方案。
Short Answer:
The alternatives are worse than the current SOAP/XML mess. Yes it could be done but it wasn't pretty.
Long Answer:
I've written COM/DCOM, CORBA, RPC, EJB, even sockets, and from my perspective, the approach you are questioning may have rough edges but still beats the older techniques hands down.
There is a reason for the boom in web services using SOAP/XML/WSDL/etc. They reduce the pain of managing them in several dimensions.
Being able to declaratively define a service and then having all the plumbing generated isn't new, RPC has tools that can do that as well. Even with those tools, though, RPC still requires a lot of manual coding to connect all the plumbing between the client and server ends. Not to mention that RPC really doesn't address how you locate the service.
Those older technologies could all get it done in their own way, but between being difficult to develop, brittle to maintain, and not having a standard way to providing service location, none of them really provided a complete solution.