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接口，以便可以调用它。

2. 与上面相同，但在SOAP头中包含WS-addressing数据以通知对方端点地址的任一侧。

   基本上与第一个选项相同的问题/假设。 WS-addressing地址将帮助您智能地将SOAP消息路由到正确的URL地址，但不会再有更多。

3. 使用WS-通知

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

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

4. 使用消息队列解决方案（例如JMS），其流量封装在HTTP 这需要在客户端和服务器之间传递有效负载的专有设计，并在双方之间形成反向合约。一个优点是客户端可以是纯粹的客户端，当收到消息时在线程中调用消息监听器。

   问题/限制：（1）如上所述，它具有与通过防火墙的HTTP通知相同的问题。 （2）是自己动手实施的。 （3）使用更多技术，然后您目前使用。

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

如果您希望推送通知，您需要一些传递给客户端的通知合同，客户端需要充当SOA服务器，并且您需要为您的流量打开防火墙。大多数公司不允许HTTP请求离开服务器并传递给客户端 - 通常需要非常好的理由来打开防火墙端口，即使这样，许多公司也会禁止它...

如果您希望客户端轮询通知，您只需要服务器端的基本WSDL接口，客户端可以频繁地调用它。

期货期权：HTML5的Web套接字
如果你的客户是一个HTML5应用，则使服务器可以推动交通到Web浏览器的插座 - 并有一些机会的企业将打开防火墙。 SOAP消息可以通过HTTP Web套接字传递，使您能够推送通知。

Answer 2

异步客户端通过使用polling and callbacks支持基于WSDL的服务。在你的情况下，我认为这个要求比较复杂。

Oracle融合中间件doc page有一个概述，将帮助你。它详细介绍了一种方法，该方法允许客户端发送生成HTTP 202（接受）的请求，然后客户端等待消息队列的响应。在你的情况下，情况可以从下面显示的那个调整。

发起针对回调的每个类别几个响应队列。客户端可以通过为队列提供客户端和类别ID来过滤它们。这将作为每个客户端或每个客户端管理的进程的回调机制。MDB可以由文件存储或DB存储支持，以确保可靠性和一次性交付。

当然，您不需要Oracle Fusionware来实现这一点。您可以使用RabbitMQ或Redis（带交易）来确认客户端收到消息。如果您的客户希望取消注册，则拨打电话并停止监听队列。

我不知道任何符合您的方案的行业标准，但我相信这个解决方案应该适合您。

Answer 3

您是否考虑过使用消息产品的“pub-sub”更简单的方法？ （如MQ，EMS或ActiveMQ）

您描述的要求似乎不符合“经典”请求/应答同步/异步SOAP Web服务方案。

在Pub/Sub解决方案中，客户端一次订阅一个主题，而发布者（在您的情况下是服务器）可以向任何订阅者发布任意数量的相关消息。

作为奖励，大多数邮件产品都包含对“持久订阅者”的支持，因此客户端有时可以脱机并在重新连接后收到所有消息。

就你而言，服务器可以容纳一个（免费的）ActiveMQ服务器......提供你似乎寻求的大部分功能。

如果你这样做，我建议你选择支持.Net的符合JMS的产品。

Answer 4

对于那些从搜索引擎获得位置：

可以使用的Web API的时下网络挂接，为OP描述的基本工作。

例如，在REST中，客户端将拥有一个HTTP端点本身，专门用于从实际服务器接收POST事件/通知。客户端通过在其通知端点上为其注册一个URI来向实际服务器注册他的端点。从这一点开始，实际的服务器可以POST到客户端的通知端点。如果你熟悉异步术语，它本质上是一个复杂的回调。

也许Java或.Net现在已经为WebHooks提供了库。这就是说，SSE和Websockets标准提供了实际的推送和实时消息，同时与HTTP和大多数浏览器兼容。

过去也使用长轮询变体，现在有时称为彗星作为聚合体。