SOAP Web服务回调体系结构？

Question

我是Web服务，JAX-WS等的新手，所以也许是菜鸟问题…

因此，我想实现一个Web服务以使两个系统通信。“客户端”系统对在“服务器”系统上生成的事件感兴趣。但是“客户端系统”本​​身就是用于其他应用程序的服务器。服务器是Java（tomcat中的WAR）。客户端是.Net。

应该只有一个客户端系统，但是客户端系统内部应该有几个客户端进程，每个进程都对不同类别的事件感兴趣。

我将实现服务器端和一个测试客户端。其他人将实现.Net代码。

运行顺序应该沿着这条线：

1. 服务器正在运行…
2. 客户端发起对话，“注册”到服务器，并请求一些初始数据。
3. 服务器保留已注册客户端端点的列表
4. 在服务器中，有一个侦听器，在发生某些事件时会收到通知。然后它将遍历已注册的客户列表，并将事件转发给每个客户
5. 在某个时候，客户端可以“取消注册”，而无需通知服务器它不再想要接收事件。

首先，听起来像是合理可行的事情？

并且是否存在使用SOAP的标准内置机制（服务器上的JAX-WS，客户端的.Net中可用的任何东西）-服务器可以用来从客户端获取回调端点吗？

例如，我使用RMI做过非常类似的事情，在这种情况下，客户端可以只向自身发送远程引用，服务器可以在以后存储ant引用。

最后，是否有一个标准库来存储端点引用，进行（集合）回调，并可能使列表保持最新状态，从而删除不响应的客户端，从而进行一些“ ping”调用？

为了清楚起见，请注意：我不仅需要带有回调的异步方法：来自客户端的一条消息将在服务器到客户端之间生成许多回调消息。

Answer 1

似乎您希望实现一种通知功能来通知任意匿名客户端。

我建议您首先考虑如何使用SOAP消息传递信息。然后，您可以考虑如何使用java-JAX-
WS或其他非标准库来实现此目的。关键是传输SOAP消息可能需要很大的限制或假设。例如，防火墙可能会阻止您的HTTP消息，客户端可能只是“客户端”而无法充当服务器角色来接收SOAP通知请求

注意：在JAX-WS 2.0中定义了异步回调机制，其中服务获得客户端的端点引用。这与Deepak Bala描述的WebLogic /
Fusion专有解决方案提供的功能相同。Websphere具有类似的专有异步解决方案。这些都不满足您的要求，因为它们仅允许每个请求一个响应。

SOAP选项：

1. 专有SOAP消息-“ 100％自己动手选择”

您可以设计完整的SOAP有效负载模式和消息交换模式。

如果知道客户端的SOAP端点地址，则可以将通知从服务器推送到客户端。客户端可以在原始SOAP请求有效负载内传输其SOAP端点地址。稍后，服务器可以将SOAP请求发送到客户端。

问题/假设：（1）从服务器到客户端的请求需要SOAP / HTTP通讯路径-当存在防火墙时不能保证；（2）客户端需要了解您的通知模式-
实际上，客户端需要充当服务端点来接收SOAP通知请求。如果您要支持任意匿名客户端，则这是两个主要的假设-
SOAP“不仅仅支持”两端都不需要详细设计所有这些东西。实际上，为了以服务类型安全的方式执行此操作，客户端应该实际声明其自己的服务WSDL接口，以便您可以调用它。（3）如前所述，许多客户端只是“客户端”，它们可能没有HTTP服务器来接受SOAP请求。

因此，要使专有的“推送”通知起作用，双方都需要服务器，并且都需要发布其SOA接口。

或者，您可以将通知拉到客户端。客户端可以使用对服务器的阻止或轮询通知请求。服务器可以用通知响应，或者不响应或不响应。

问题/假设：（1）HTTP服务器（即SOAP服务器）通常不支持阻止请求，这意味着您必须进行轮询；（2）客户端需要了解您的通知模式-
实际上，客户端需要充当服务端点来接收SOAP通知请求。对于任意的匿名客户机，这是两个非常大的假设-
SOAP“不仅仅支持”两端都不需要详细设计所有这些东西。实际上，为了以服务类型安全的方式执行此操作，客户端应该实际声明其自己的服务WSDL接口，以便您可以调用它。

1. 与上述相同，但在SOAP标头中包含WS-addressing数据，以告知另一端的端点地址。

基本上与第一个选项相同的“问题/假设”。WS寻址地址将帮助您智能地将SOAP消息路由到正确的URL地址，但仅此而已。

1. 使用WS通知

该规范是针对您的情况而设计的。
WS-BaseNotification子标准将满足您的需求。它为通知生产者和使用者提供了WSDL端口定义。它提供了一个符合WS-
standards的解决方案，用于从消费者到生产者的订阅，以及从生产者到消费者的通知。

问题/局限性：（1）它没有定义通知有效载荷的格式。通知有效负载是特定于应用程序域的（专有设计）。该标准未定义任何“标准”或“内置”通知情况或消息。（2）与通过防火墙的HTTP通知存在同样的问题。（3）WS-
Notification不是Java EE / JAX-WS的受支持标准（但是有很多应用服务器，包括开源和商业应用服务器，都支持它作为扩展）。

1. 使用消息队列解决方案（例如JMS），将通信封装在HTTP中。这需要在客户端和服务器之间传递的有效负载进行专有设计，并在双方之间回传合同。优点是客户端可以是纯客户端，在收到消息时在线程中调用消息侦听器。

问题/局限性：（1）与通过防火墙的HTTP通知一样，存在同样的问题。（2）是一个自己动手的实现。（3）使用比您当前使用的技术更多的技术。

最终结果：
您至少需要将解决方案的一部分做为专有设计-SOAP /
WS标准不能满足您的全部要求。从理论上讲，这种专有设计可以利用产品来提供很多功能，但是通知模式设计需要由您创建和集成。

如果您希望推送通知，则需要 某种
形式的通知传递给客户端的合同，客户端需要充当SOA服务器，并且需要为流量打开防火墙。大多数公司都禁止HTTP请求离开服务器并传递给客户端-
您通常需要一个非常好的理由来打开防火墙端口，即使如此，许多公司仍会禁止它…

如果您希望让客户端轮询通知，则只需在服务器端使用一个基本的WSDL接口即可被客户端频繁调用。

将来的选择：HTML5 Web套接字
如果您的客户端是HTML5应用程序，则启用了Web套接字的服务器可以将流量推送到浏览器-公司很有可能会打开防火墙。SOAP消息可以通过HTTP
Web套接字传输，使您能够推送通知。