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

Web Service vs TCP/IP Sockets (Java) + SQL Connections

提问by Andez

We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.

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

The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.

应用程序使用 TCP 套接字相互绑定。它们相互请求数据和推送数据。哪个工作得很好。

Thought

想法

So we are looking at converting all data access and TCP communication to a web service.

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

The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.

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

The client applications would send/recieve the messages to/from the server side applications using the web service. The client applications would retrieve and update data in the database using the web service.

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

Question

问题

I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.

我只想知道人们在通过 Web 服务（如果可能）进行 2 路通信（请求和推送）时的体验是什么，以及关于这样做的想法是什么。

Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.

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

I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java?: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!

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

Thanks,

谢谢，

Andez

安德斯

回答by pap

It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:

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

• It's Request/response oriented
• Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
• All requests eventually boil down to good old-fashioned servlet endpoints in the server

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

Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.

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

Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.

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