SOAP Web 服务回调架构? [英] SOAP web service callback architecture?

问题描述

我对 Web 服务、JAX-WS 等很陌生，所以也许是菜鸟问题...

所以，我想实现一个 Web 服务来让两个系统进行通信.客户端"系统对服务器"系统上生成的事件感兴趣.但是客户端系统"本​​身就是不同应用程序的服务器.服务器是 Java(tomcat 中的 WAR).客户端是.Net.

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

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

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

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

首先，这听起来合理可行吗?

是否有一个标准的内置机制，使用 SOAP(服务器上的 JAX-WS，任何可用于 .Net 和客户端的)——服务器可以使用它从客户端获取回调端点?

例如，我使用 RMI 做了一些非常相似的事情，在这种情况下，客户端可以只向自己发送一个远程引用，服务器可以稍后存储 ant 引用.

最后，是否有一个标准库来存储端点引用、进行(集体)回调，并可能使列表保持最新，删除不响应的客户端，以便进行一些ping"调用?

请注意:我需要的不仅仅是带有回调的异步方法:来自客户端的一条消息将生成许多从服务器到客户端的回调消息.

解决方案

似乎您希望实现通知工具来通知任意匿名客户端.

我建议您首先考虑如何使用 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 寻址地址将帮助您智能地将 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 Sockets
如果您的客户端是 HTML5 应用程序，那么支持 Web 套接字的服务器可以将流量推送到浏览器 - 并且公司可能会打开防火墙.SOAP 消息可以通过 HTTP 网络套接字传输，使您能够推送通知.

I am quite new to web services, JAX-WS etc. so maybe noob question...

So, I want to implement a web service to make two systems communicate. The "client" system is interested in events that are generated on the "server" system. But the "client system" is itself a server for a different app. The server is Java (WAR in tomcat). The client is .Net.

There should be just one client system, but several client processes inside the client system, each interested in distinct categories of events.

I will implement the server-side, and a test client. Somebody else will implement the .Net code.

The running sequence should be along this line :

1. Server is running...
2. Client initiates conversation, "registers" to the server, and requests some initial data.
3. Server keeps a list of registered clients' endpoints
4. In the server there is a listener that is notified when certain events happen. It will then go through the list of registered clients and forwards the event to each of them
5. At some point, the client can "unregister" no notify the server that it doesn't want to receive events any more.

First, does it sound like something reasonably doable ?

And is there a standard built-in mechanism, using SOAP (JAX-WS on the server, whatever is available with .Net n the client) - that the server can use to obtain a callback endpoint from the client ?

For example, I did something very similar using RMI, in this case the client can just send a remote reference to itself, that the server can just store ant refer to later.

Finally, is there a standard library to store endpoints references, make (collective) callbacks, and maybe keep the list up-to-date, removing the clients that don't respond so some "ping" call ?

Note for clarity : I need more than just asynchronous method with callback: one message from the client will generate many callback messages from server to client.

解决方案

Seems you wish to implement a notification facility to inform arbitrary anonymous clients.

I suggest you first consider how you would pass the information using SOAP messages. Then you can consider how to achieve this using java - JAX-WS or additional non-standard libraries. The point is there may be significant limitations or assumptions required to transfer SOAP messages. E.g. firewalls might block your HTTP messages, clients might "just clients" with no ability to act in a server role to recieve SOAP notification requests

Note: An async callback mechanism is defined in JAX-WS 2.0, where the service obtains the endpoint reference of the client. This is the same sort of functionality provided by WebLogic/Fusion proprietary solution described by Deepak Bala. Websphere has a similar proprietary async solution. None of these meet your requirements, because they only allow a single response per request.

SOAP Options:

1. Proprietary SOAP messages - the "100% Do-It-Yourself Option"

   You design full SOAP payload schemas and message exchange pattern.

   You can push the notification from the server to the client if you know the client's SOAP endpoint address. The client can transfer it's SOAP endpoint address within original SOAP request payload. Sometime later the server can send a SOAP request to the client.

   Problems/Assumptions: (1) need a SOAP/HTTP communication path for requests from server-to-client - not guaranteed when firewalls exist; (2) the client needs to be aware of your notification schema - in fact the client needs to act as a Service endpoint to recieve the SOAP notification request. That's two big assumptions IF you are trying to support arbitrary anonymous clients - that's not something SOAP "just supports" both ends need to design all this in detail. In fact to do this in a service typesafe manner, the client should actually declare it's own service WSDL interface so that you can invoke it. (3) As hinted earlier, many clients are "just clients" - they might not have a HTTP server to accept SOAP requests.

   So for proprietary "push" notifications to work, both sides need to servers and both need to publish their SOA interfaces.

   Alternatively, you can pull the notification to the client. The client can use a notification request to the server that is either blocking or polling. The server can respond with the notification or nothing or error.

   Problems/Assumptions: (1) HTTP servers (i.e. the SOAP server) do not support blocking requests, as a rule, meaning you must poll; (2) the client needs to be aware of your notification schema - in fact the client needs to act as a Service endpoint to recieve the SOAP notification request. That's two very big assumptions for an arbitrary anonymous client - that's not something SOAP "just supports" both ends need to design all this in detail. In fact to do this in a service typesafe manner, the client should actually declare it's own service WSDL interface so that you can invoke it.

2. Same as above, but make include WS-addressing data in SOAP headers to inform either side of the other's endpoint address.

   Basically the same Problems/Assumptions as the first option. WS-addressing addresses will help you intelligently route SOAP messages to the right URL address, but no more.

3. Use WS-notification

   This spec was designed for your scenario.
   WS-BaseNotification sub-standard would meet your needs. It provides WSDL port definitions for notification producers and consumers. It provides a WS- standards compliant solution for subscription from a consumer to a producer, and a notification from producers to consumers.

   Problems/Limitations: (1) It does NOT define the format of notification payloads. The Notification payload is application-domain specific (proprietary design). The standard does not define any "standard" or "built-in" notification situations or messages. (2) It has the same problems with HTTP notifications passing through firewalls as mentioned above. (3) WS-Notification is not a supported standard of Java EE/JAX-WS (but there are plenty of app servers, open source and commercial, that support it as an extension).

4. Use a message queuing solution (e.g. JMS) with traffic encapsulated in HTTP This requires proprietary design of payloads passing between client and server and back - forming contracts between the two sides. An advantage is that the client can be a pure client, with a message listener invoked in a thread when a message is recieved.

   Problems/Limitations: (1) It has the same problems with HTTP notifications passing through firewalls as mentioned above. (2) Is a do-it-yourself implementation. (3) Uses more technology then you currently use.

End Result:
You need at least part of your solution to be a proprietary design - the SOAP/WS standards do not meet your full requirements. In theory this proprietary design could leverage a product to provide much of the legwork, BUT the notification schema design would need to be created and integrated by you.

IF you wish to push notifications, you need some sort of contract for notifications passing to the client, the client needs to act as a SOA server, and you need the firewalls openned for your traffic. Most corporations disallow HTTP requests leaving a server and passing to a client - you normally need an extremely good reason to open firewall ports and even then, many corporations will disallow it...

IF you wish to have clients polling for notifications, you just need a basic WSDL interface on the server side that can be called frequently by clients.

Future Option: HTML5 Web Sockets
IF your client is a HTML5 app, then web sockets enabled servers can push traffic to the browser - and there is some chance corporations will open firewalls. SOAP messages could travel over HTTP web sockets, enabling you to push notifications.

这篇关于SOAP Web 服务回调架构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！