Web 服务与 TCP/IP 套接字 (Java) + SQL 连接

Question

我们目前正处于产品生命周期的某个阶段，我们正在考虑迁移到 Web 服务。我们的系统是用 Java 编写的，它由许多客户端和服务器应用程序组成，它们通过 TCP 套接字相互通信，并且还具有内联 SQL 来执行数据检索和更新（yuk！我知道），它使用我们自己的 SQL Connection 类然后使用 java.sql.Connection 使用 Microsoft JDBC 驱动程序连接到 SQL Server 数据库。

应用程序使用 TCP 套接字相互绑定。它们相互请求数据并相互推送数据。效果很好。

思想

因此，我们正在考虑将所有数据访问和 TCP 通信转换为 Web 服务。

Web 服务将设计为在公司安全的互联网站点上运行。这个想法是，用户可以在家中将他们的客户连接到 Web 服务——当他们不在公司网络上时——或者在工作时，当他们在时。

客户端应用程序将使用 Web 服务向/从服务器端应用程序发送/接收消息。 客户端应用程序将使用 Web 服务检索和更新数据库中的数据。

问题

我只想知道人们在通过 Web 服务（如果可能的话）使用 2 路通信（请求和推送）做任何事情时的经验，以及这样做的想法。

将数据访问转换为 Web 服务似乎很简单 - 我可以预见在系统的某些部分检索大型数据集时会出现一些性能问题。

我正在浏览有关此问题的各种阅读材料，因为我接触 Web 服务（使用 C# 和 ASP.NET）已经有一段时间了。目前正在阅读“使用 Java™ 构建 Web 服务：理解 XML、SOAP、WSDL 和 UDDI”。我必须承认，我认为 Web 服务始终是无状态的，但刚刚读到它们不是！

谢谢，

安德斯

Answer 1

将 WebServices 视为与传输层上的任何其他 Web 应用程序相同会有所帮助。它以相同的方式使用 HTTP/HTTPS 协议，只是它不是发送 HTML，而是根据预定义的格式 (SOAP) 发送 XML。因此：

• 它是面向请求/响应的
• 可以有状态，就像网页可以有状态一样，使用会话（假设您有一个支持跨请求维护会话 cookie 的 Web 服务客户端）
• 所有请求最终都归结为服务器中良好的老式 servlet 端点

牢记这些限制和功能，考虑您的要求以及它们如何相互映射。如果您需要真正的双向通信（推送），那么 Web 服务并不理想。它们是客户端/服务器，面向请求/响应。实现推送，你将不得不从客户端轮询。一种可能的替代方法是让“服务器”和“客户端”都充当 Web 服务“服务器”。这意味着将一些轻量级 servlet 引擎与客户端（如码头）捆绑在一起，以便“服务器”可以对“客户端”进行 Web 服务调用。另一种方法是查看双向 RMI/IOOP。

另一种方法是保持通信层与现在一样。仅仅为了使用 Web 服务而重构为 Web 服务并没有内在的好处。如果他们不增加任何好处，那只是浪费。正如您自己已经提到的那样，Web 服务带来了额外的开销（详细协议、servlet 引擎等），因此它确实需要平衡额外的成本和开发时间以及明显的好处。俗话说“不破不修”。正如您所说，当前的解决方案“效果很好”，我可能不会改变它。但这只是我。