Pie*_*nry 22 .net java web-services callback jax-ws
我对Web服务,JAX-WS等都很陌生,所以也许没有问题......
所以,我想实现一个Web服务来使两个系统进行通信."客户端"系统对在"服务器"系统上生成的事件感兴趣.但"客户端系统"本身就是不同应用程序的服务器.服务器是Java(tomcat中的WAR).客户端是.Net.
应该只有一个客户端系统,但客户端系统中有几个客户端进程,每个客户端进程都对不同类别的事件感兴趣.
我将实现服务器端和测试客户端.其他人将实现.Net代码.
运行顺序应该沿着这一行:
首先,这听起来像是可行的吗?
是否有一个标准的内置机制,使用SOAP(服务器上的JAX-WS,客户端的.Net可用的任何东西) - 服务器可以用来从客户端获取回调端点?
例如,我使用RMI做了一些非常相似的事情,在这种情况下,客户端可以只向自己发送远程引用,服务器可以稍后存储ant引用.
最后,是否有一个标准库来存储端点引用,make(集体)回调,并且可能使列表保持最新,删除那些没有响应的客户端,以便进行一些"ping"调用?
为清楚起见,注意:我需要的不仅仅是带回调的异步方法:来自客户端的一条消息将从服务器到客户端生成许多回调消息.
Gle*_*est 16
似乎您希望实现通知工具来通知任意匿名客户端.
我建议你首先考虑如何使用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接口,以便您可以调用它.
与上面相同,但make包含SOAP头中的WS-addressing数据,以通知对方端点地址的任何一方.
基本上与第一个选项相同的问题/假设.WS寻址地址将帮助您智能地将SOAP消息路由到正确的URL地址,但不会更多.
使用WS通知
此规范是为您的方案设计的.
WS-BaseNotification子标准将满足您的需求.它为通知生成者和使用者提供WSDL端口定义.它提供符合WS标准的解决方案,用于从消费者到生产者的订阅,以及从生产者到消费者的通知.
问题/限制:(1)它没有定义通知有效载荷的格式.通知有效负载是特定于应用程序域的(专有设计).该标准没有定义任何"标准"或"内置"通知情况或消息.(2)如上所述,通过防火墙的HTTP通知存在同样的问题.(3)WS-Notification不是Java EE/JAX-WS的支持标准(但是有很多应用服务器,开源和商业,支持它作为扩展).
使用封装在HTTP中的流量的消息排队解决方案(例如JMS)这需要在客户端和服务器之间传递的有效负载的专有设计以及在双方之间形成合同.优点是客户端可以是纯客户端,在收到消息时在线程中调用消息监听器.
问题/限制:(1)如上所述,通过防火墙的HTTP通知存在同样的问题.(2)是一个自己动手的实现.(3)使用当前使用的更多技术.
最终结果:
您至少需要将部分解决方案作为专有设计 - SOAP/WS标准不能满足您的全部要求.从理论上讲,这种专有设计可以利用产品来提供大量的工作,但是需要创建和集成通知模式设计.
如果你想推送通知,你需要一些类型的合同,以传递给客户端,客户端需要充当SOA服务器的通知,而你需要的防火墙openned为您的流量.大多数公司不允许离开服务器并传递给客户端的HTTP请求 - 您通常需要一个非常好的理由来打开防火墙端口,即便如此,许多公司也会拒绝它...
如果您希望客户端轮询通知,您只需要服务器端的基本WSDL接口,客户端可以经常调用它.
未来选项:HTML5 Web套接字
如果您的客户端是HTML5应用程序,那么启用Web套接字的服务器可以将流量推送到浏览器 - 企业有可能打开防火墙.SOAP消息可以通过HTTP Web套接字传递,使您可以推送通知.
通过使用轮询和回调,基于WSDL的服务支持异步客户端.在你的情况下,我认为要求相对更复杂.
Oracle融合中间件文档页面提供了一个可以帮助您的方案.它详细说明了一种方法,该方法允许客户端发送生成HTTP 202(已接受)的请求,然后客户端等待消息队列上的响应.在您的情况下,可以从下面显示的方案调整方案.

为每个类别的回调启动多个响应队列.客户端可以通过为队列提供客户端和类别ID来过滤它们.这将作为每个客户端或每个客户端下管理的进程的回调机制.MDB可以由文件存储或数据库存储支持,以确保可靠性和一次性交付.
当然,您不需要Oracle fusionware来实现它.您可以使用RabbitMQ或Redis(带有事务)来确认在客户端上收到消息.如果您的客户希望取消注册,则拨打电话并停止收听队列.
我不知道任何符合您情况的行业标准,但我相信这个解决方案应该适合您.
您是否考虑过使用消息产品的"pub-sub"更简单的方法?(例如MQ,EMS或ActiveMQ)
您描述的要求似乎不适合"经典"请求/回复同步/异步SOAP Web服务方案.
在Pub/Sub解决方案中,客户端订阅一个主题,发布者(在您的情况下,服务器)可以向所有订阅者发布任意数量的相关消息.
作为奖励,大多数消息传递产品都包括对"持久订阅者"的支持,因此客户端有时可以脱机并在重新连接后接收所有消息.
在您的情况下,服务器可以容纳(免费)ActiveMQ服务器...提供您似乎寻求的大部分功能.
如果您这样做,我建议您选择支持.Net的符合JMS标准的产品.
| 归档时间: |
|
| 查看次数: |
21110 次 |
| 最近记录: |