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和大多數瀏覽器兼容。

過去也使用長輪詢變體，現在有時稱爲彗星作爲聚合體。