JMS、消息队列服务、ESB 相关问题
假设 SOA 基础设施中有 2 个 Web 服务 A 和 B 设置。
Web 服务 A 依赖于本地安装的桌面应用程序（它是基于 C++ 编程的遗留应用程序，并提供 C++ API 来提供 Web 服务 A 所需的信息）中可用的信息。
场景是这样的：人类参与者（可以被视为 Web 服务 B 的消费者）登录网站并单击请求 Web 服务 B 提供的服务的按钮。作为此请求的一部分，发送他的 ID。 Web 服务 B 使用此 ID 向 Web 服务 A 发送请求。 Web 服务 A 使用此 ID 以某种方式确定与发起请求的人类参与者的本地安装的桌面应用程序进行通信的方式。
主要问题是，Web 服务 A 如何使用 SOA 基础设施连接到桌面应用程序并以可靠的方式获取信息。
假设该 SOA 中除桌面应用程序外的所有内容均基于 Java。
桌面应用程序基本上就像一个 CRM 应用程序，有自己的内部数据库，而不是像 MySQL 这样的传统数据库。它仅提供有关人类参与者以及该人类参与者在其安装的 CRM 桌面应用程序中的客户的基本文本信息。
我确实想使用SOA相关技术，尽管它可能更复杂。
鉴于以上详细信息：
我如何使用 JMS 来解决这个问题？
如果 JMS 不是正确的解决方案，那么 ESB 又如何？如何使用 ESB 来解决这个问题？
Assume there are 2 web services A and B setup in SOA infrastructure.
Web services A depends on information that is available from the locally installed Desktop application (its a legacy application based on C++ programming and provides C++ API to give the information needed by web service A).
The scenario is this: Human actor (which can be considered as Consumer of web service B)logs into a website and clicks a button which requests the service provided by web service B. As part of this request, his ID is sent. Web service B sends request to web service A with this ID. Web service A uses this ID to somehow determine a way to talk to locally installed desktop application of the human actor who originated the request.
The main problem how can web service A connect to desktop application and get the information in a reliable way using SOA infrastructure.
Assume that everything in this SOA is Java based except the desktop application.
The desktop application is basically like a CRM application with its own internal database and not traditional database like MySQL. It provides just basic textual information about the human actor and about the customer(s) of that human actor in his installed CRM desktop application.
I do want to use SOA related technologies even though it may be more complicated.
Given above details:
How can I use JMS to solve this problem?
If JMS is not the right solution, what about ESB and how can I use ESB to solve this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
与桌面应用程序的通信很大程度上取决于应用程序能够执行的不同方法。如果应用程序有数据库后端，ESB 可以促进与所使用的特定数据库的预定义适配器的通信。如果应用程序有一个可以通过编程方式访问的 api，那么这也是一种方法。我不确定 JMS 是否是合适的解决方案，因为根据您的用例，您需要同步回复。将 JMS 放在中间（以某种方式）会破坏该回复，而是返回异步响应。
我建议更多地研究桌面应用程序中可用的功能，并根据您的发现开始评估 ESB 功能。对于此用例，ESB 可能有点大材小用，但如果您计划执行更多这样的操作，它可能会变得有价值。
The communication with the desktop application will greatly be determined by what different methods the application is capable of performing. If the application has a database backend, an ESB can facilitate communication with predefined adapters for the specific database being used. If the application has an api that can be tapped programmatically, that is a method as well. I am not sure JMS would be the appropriate solution since given your use case you would want a synchronous reply. Putting JMS in the middle (somehow) will break that reply and rather return an asynchronous response.
I would recommend looking more into the functionality available in the desktop application and with your findings start with evaluating ESB functionality. An ESB may be overkill for this use case but if you plan to do more operations like this it may become valuable.
我认为问题归结为 Java Web 服务 A，需要与 C++ 桌面应用程序通信以获取用户详细信息。
如果桌面应用程序能够使用 Stomp 等来使用 JMS，则可以使用 ActiveMQ 或 HornetQ。这还允许您将 A 扩展到多台计算机上的多个实例，并使用 JMS 从桌面应用程序请求用户信息。
另一种选择是在桌面应用程序上公开一个简单的 API（REST、TCP 等），并使用该 API 使 Web 服务 A 与桌面应用程序对话。同样，您可以将 A 分发到多个实例中以实现可扩展性。
您可以使用 ESB 将 REST 调用转换为 TCP，或将 SOAP 转换为 JMS 等。基本上是任意到任意的转换。免费开源 ESB UltraESB [http://adroitlogic.org] 包含许多示例，并且是轻量级的 (~35MB)，因此与 > 相比，“过度杀伤”将是最小的。 300MB+ 资源匮乏的 ESB
I think the problem boils down to a Java Web Service A, having a requirement to talk to a C++ desktop application to get user details.
If the Desktop application is able to use JMS using Stomp etc, ActiveMQ or HornetQ maybe used. This also allows you to scale A into multiple instances across many machines, and use JMS to request user information from the Desktop application.
Another option is to expose a simple API (REST, TCP etc) on the Desktop application and make the Web Service A talk to the Desktop application using that. Again, you could distribute the A into multiple instances for scalability.
You can use an ESB to convert a REST call to TCP, or a SOAP to JMS etc. Basically any-to-any conversion. The Free and Open Source ESB UltraESB [http://adroitlogic.org] contains many examples, and is lightweight (~35MB) so the 'overkill' will be minimal compared to > 300MB+ resource hungry ESBs