Request/response messaging pattern - Azure Service Bus

1
votes

All ,

I have a doubt on the Request response pattern... Assume the following is my scenario

1.I have a service running on Windows Azure. This service can be called by users to execute a command.

2.I have a client applications that is running on my intranet. This client application will execute the command . The computer in which the client application is running is connected to internet , but does not have a static IP i.e machine cannot be accessed directly via the internet

3.I am planning to use Azure Service Bus through which my service on Windows Azure can communicate with the client application to execute....

In this scenario, can i use Request/response messaging i.e can the service post a message and expect a response from the client

OR

Should i use command queue for each client , the Service will push the command to be executed on a queue , the client will poll the queue and execute a command

Any help is appreciated

2
wcfazuremessagingazureservicebusazure-servicebus-queues
Which way is the communication flowing? Is the intranet computer calling the service on Windows Azure, or is the Windows Azure service calling a command on the intranet computer (or both)? - mellamokb
The communication can be in both directi directions - Sabarish Sathasivan

2 Answers

0
votes

Since you are using WCF (based on the tag), you should consider using Service Bus Relay calling the WCF service asynchronously.

0
votes

I assume you want to use Relaybinding here, using WCF.
Your web service (which is behind NAT, firewall devices, etc) is only opening outbound connections in that case. The service is listening on a registered endpoint in the cloud (that is accessible for him, because of credentials and protocol). All incoming service calls are sent over that port/socket. The response will then be sent back over the outgoing port again.
If the IP Address of your service changes, it wil register itself again (by listening on the same registered endpoint) and you can reach that service transparantly.

Another way you can achieve request/response in an asynchronous fashion, is through queues. This does not require any open connection between your client and your service and can happen fully asynchronous. This can be achieved by sending a message to the request queue for your specific service (with a Correlation Id). And when that service has processed that message, it can send the response to the response queue of your application, using sessions. A good example of this pattern can be found on Alan Smith's blog: http://www.cloudcasts.net/devguide/Default.aspx?id=13051