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引擎等），所以它確實需要平衡額外成本和開發時間並獲得明顯的好處。正如俗話所說：「如果它沒有壞掉，不要修理它」。正如你所說的目前的解決方案「工作得很好」，我可能不會改變它。這只是我而已。