应用程序使用TCP套接字相互绑定.他们从彼此请求数据并将数据推送到彼此.哪个效果很好.
思想
因此,我们正在考虑将所有数据访问和TCP通信转换为Web服务.
该Web服务将设计为在公司安全的互联网站点上运行.我们的想法是,用户可以将他们的客户连接到家中的Web服务 – 当他们不在公司网络上时 – 或者在他们工作时.
客户端应用程序将使用Web服务向/从服务器端应用程序发送/接收消息.
客户端应用程序将使用Web服务检索和更新数据库中的数据.
题
我想知道人们的经验是通过Web服务(如果可能的话)进行双向通信(请求和推送)以及做这件事的想法.
将数据访问转换为Web服务似乎很简单 – 我可以预见一些性能问题,即在系统的某些部分检索大型数据集.
我正在浏览关于这个问题的各种阅读材料,因为我已经触及了Web服务(使用C#和ASP.NET).目前正在阅读“使用Java™构建Web服务：理解XML,SOAP,WSDL和UDDI”.我必须承认,我认为Web服务总是无状态,但只是读到它们不是！
谢谢,
Andez
解决方法
>这是面向请求/响应的
>使用会话(假设您有一个支持跨请求维护会话cookie的Web服务客户端),可以像使用网页一样有状态.
>所有请求最终归结为服务器中的旧式servlet端点
记住这些限制和功能,考虑您的要求以及它们如何相互映射.如果您需要真正的双向通信(推送),那么Web服务并不理想.它们是客户端/服务器,面向请求/响应.实现推送,您必须从客户端进行轮询.可能的替代方案可以是让“服务器”和“客户端”充当Web服务“服务器”.这意味着将一些轻量级servlet引擎与客户端(如jetty)捆绑在一起,这样“服务器”就可以将Web服务调用到“客户端”.另一种方法是查看双向RMI / IOOP.
另一种方法是保持今天的通信层.仅仅为了使用Web服务,重构Web服务没有固有的好处.如果他们没有增加任何好处,那只是浪费.正如您自己已经提到的,Web Service带来了额外的开销(详细协议,servlet引擎等),因此它确实需要平衡额外的成本和开发时间以及明显的好处.俗话说“如果没有破坏,就不要修理它”.正如你所说的当前解决方案“完美无缺”,我可能不会改变它.那只是我.
