SOAP Web服务回调体系结构？ [英] SOAP web service callback architecture?

问题描述

我对web服务，JAX-WS等等很新，所以也许noob有问题...

所以，我想实现一个web服务，系统通信。 客户端系统对在服务器系统上生成的事件感兴趣。但是客户端系统本​​身就是一个不同应用的服务器。服务器是Java（Tomcat中的WAR）。客户端是.Net。

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

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

运行顺序应该沿着这一行：

1. 服务器正在运行...


2. 客户端启动会话，注册到服务器，并请求一些初始数据。


3. 服务器保留已注册客户端的端点列表


4. 在服务器中有一个侦听器，当某些事件发生时通知它。然后它将通过已注册的客户端列表，并将事件转发给每个客户端


5. 在某些时候，客户端可以取消注册不通知服务器它不想




首先，这听起来是否合理可行？





还有一个标准的内置机制，使用SOAP（服务器上的JAX-WS，无论客户端是否有.Net n） - 服务器可以使用它从客户端获取回调端点？ p>



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



最后，是否有一个标准库来存储端点引用，make（集体）回调，并且可能保持列表最新，删除不需要的客户端





注意：为了清楚起见，我需要的不仅仅是异步方法与回调：来自客户端的一个消息将从服务器生成许多回调消息

解决方案

似乎您希望实施通知工具来通知任意匿名客户。





我建议你先考虑如何使用SOAP消息传递信息。然后你可以考虑如何使用java - JAX-WS或其他非标准库来实现这一点。要点是可能存在传输SOAP消息所需的重大限制或假设。例如。防火墙可能会阻止您的HTTP消息，客户端可能只是客户端，无法在服务器角色中接受SOAP通知请求





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





SOAP选项：



<


6. 专有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接口，以便您可以调用它。




7. 但是要在SOAP头中包含WS-addressing数据，以通知对方端点地址的任一端。

   
   
   

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




8. 使用WS-通知

   
   
   

   此规范是为您的场景设计的。
   
   WS-BaseNotification子标准将满足您的需求。它为通知生产者和使用者提供WSDL端口定义。

   
   
   

   问题/限制：（1）它不是从一个消费者到一个生产者的订阅的WS-标准兼容解决方案，定义通知有效内容的格式。通知有效载荷是特定于应用域（专有设计）。该标准没有定义任何标准或内置通知情况或消息。 （2）如上所述，它具有与HTTP通知通过防火墙相同的问题。
   （3）WS-Notification不是Java EE / JAX-WS的支持标准（但是有很多应用程序服务器，开源和商业版本，它们作为扩展支持它们）。

   li>
   

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

   
   
   

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

结束结果：

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

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

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

未来选项：HTML5 Web Sockets

如果您的客户端是HTML5应用，则启用网络套接字的服务器可以将流量推送到浏览器是一些机会公司将打开防火墙。 SOAP消息可以通过HTTP Web套接字传输，使您能够推送通知。

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屋！