Web服务与TCP/IP套接字（Java）+ SQL连接

Question

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

应用程序使用TCP套接字相互绑定。他们向彼此请求数据并将数据推送到彼此。这工作得很好。

思想

所以我们正在考虑所有的数据访问和TCP通信转换成Web服务。

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

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

问题

我只是想知道人民的经验是做与2路通信（请求和推）在Web服务（如果可能），什么心思都这样做这样的事情是什么。

将数据访问转换为Web服务看起来非常简单 - 我可以预见一些性能问题，即在系统某些部分检索大型数据集的情况。

由于我已经触及Web服务（使用C＃和ASP.NET），因此我正在浏览关于此问题的各种阅读材料。目前阅读“使用Java™构建Web服务：了解XML，SOAP，WSDL和UDDI”。我必须承认我认为网络服务始终是无国界的，但刚刚读到它们不是！

感谢，

Andez

Answer 1

它有助于想到的WebServices作为一样的传输层上的任何其他Web应用程序。它以相同的方式使用HTTP/HTTPS协议，它只是根据预定义的格式（SOAP）发送XML，而不是发送HTML。因此：

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

保持这些限制和功能考虑，想想你的需求，以及它们如何映射反目成仇。如果您需要真正的双向通信（推送），那么Web服务并不理想。他们是客户/服务器，请求/响应导向。实现推动，你将不得不从客户端投票。一种可能的选择是让“服务器”和“客户端”充当网络服务“服务器”。这意味着将一些轻量级servlet引擎与客户端（如码头）捆绑在一起，以便“服务器”可以向“客户端”发起Web服务调用。另一种方法是看双向RMI/IOOP。

还有另一种方法是保持今天的通信层。仅仅为了使用Web服务而对Web服务进行重构没有固有的收益。如果他们没有增加任何好处，那只是浪费。正如你自己已经提到的那样，Web服务带来了额外的开销（冗长的协议，servlet引擎等），所以它确实需要平衡额外成本和开发时间并获得明显的好处。正如俗话所说：“如果它没有坏掉，不要修理它”。正如你所说的目前的解决方案“工作得很好”，我可能不会改变它。这只是我而已。