JMS, Message Queing Service, ESB related question

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 sc开发者_如何学运维enario 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?

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.

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