似乎您希望实现一个通知工具来通知任意匿名客户端。
我建议您首先考虑如何使用 SOAP 消息传递信息。然后，您可以考虑如何使用 java - JAX-WS 或其他非标准库来实现此目的。关键是传输 SOAP 消息可能需要存在重大限制或假设。例如，防火墙可能会阻止您的HTTP消息，客户端可能“只是客户端”，无法以服务器角色接收SOAP通知请求
注： 异步回调机制在 JAX-WS 2.0 中定义，其中服务获取客户机的端点引用。这与Deepak Bala描述的WebLogic/Fusion专有解决方案提供的功能相同。Websphere 有一个类似的专有异步解决方案。这些都不符合您的要求，因为它们只允许每个请求一个响应。
SOAP 选项：
-
专有 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 接口，以便您可以调用它。
-
同上，但要在 SOAP 标头中包含 WS 寻址数据，以通知另一方的终结点地址。
基本上与第一个选项相同的问题/假设。WS 寻址地址将帮助您智能地将 SOAP 消息路由到正确的 URL 地址，但仅此而已。
-
使用 WS 通知
此规范是针对你的方案设计的。
WS-BaseNotification子标准将满足您的需求。它为通知生产者和使用者提供 WSDL 端口定义。它为从使用者到生产者的订阅以及从生产者到消费者的通知提供了符合 WS- 标准的解决方案。
问题/限制：（1）它没有定义通知有效负载的格式。通知负载是特定于应用程序域的（专有设计）。该标准不定义任何“标准”或“内置”通知情况或消息。（2）它与上面提到的通过防火墙的HTTP通知具有相同的问题。（3） WS-Notification 不是 Java EE/JAX-WS 的受支持标准（但是有很多开源和商业应用程序服务器支持它作为扩展）。
-
使用消息队列解决方案（例如JMS），其中流量封装在HTTP中 这需要专有设计在客户端和服务器之间传递的有效负载以及返回 - 在双方之间形成契约。一个优点是客户端可以是纯客户端，在收到消息时在线程中调用消息侦听器。
问题/限制：（1）它与上面提到的HTTP通知通过防火墙具有相同的问题。（2） 是一个自己动手实现的。（3）使用比您当前使用的更多的技术。
最终结果：
您至少需要部分解决方案是专有设计 - SOAP/WS 标准不能满足您的全部要求。从理论上讲，这种专有设计可以利用产品来提供大部分的跑腿工作，但是通知架构设计需要由您创建和集成。
如果你想推送通知，你需要某种契约来将通知传递给客户端，客户端需要充当SOA服务器，你需要为流量打开防火墙。大多数公司不允许HTTP请求离开服务器并传递到客户端 - 您通常需要一个非常好的理由来打开防火墙端口，即使这样，许多公司也会禁止它...
如果您希望客户端轮询通知，则只需要服务器端有一个可由客户端频繁调用的基本 WSDL 接口。
未来选项：HTML5 Web Sockets
如果您的客户端是HTML5应用程序，那么启用Web套接字的服务器可以将流量推送到浏览器 - 并且公司有可能打开防火墙。SOAP 消息可以通过 HTTP Web 套接字传输，使您能够推送通知。
