Question

Background

There’s a RESTful API offering some operations. This RESTful API is consumed by third-parties that must be authenticated and authorized into the platform in order to get access to API’s operations.

Third-parties require reliable data consumption, and the API must provide a publisher/consumer pattern-based solution to consume some data.

Since the so-called API won’t reinvent the wheel, it’s about to use Windows Azure Service Bus.

Problem

The RESTful API should abstract the actual service bus service. In the other hand, Service Bus is the solution to provide reliable messaging in the own platform.

Actually, Service Bus isn’t an standalone service, but it’s part of some workflows. Third-parties aren’t supposed to have Windows Azure credentials.

Third-parties should connect to Windows Azure Service Bus using API-specific credentials that would give access to the Service Bus’ topics (i.e. message queues).

Possible solutions

a. Authorize direct access to Windows Azure Service Bus

It seems the easiest solution. Let’s see the flow:

1. A third-party sends a request to the RESTful API in order to get Windows Azure Service Bus connection string – credentials –.
2. Once it has the connection string, the third-party connects to Windows Service Bus and starts receving message from some topic subscription. NOTE: The connection string is encrypted in the server-side and it can only be decrypted by an accepted client.

Pros

• Easy. The API authorizes the third-party to use Windows Azure Service Bus and it has no other responsibility.
• Own API doesn’t manage the high load of topic subscribers: this is handled by Windows Azure platform.

Cons

• Third-parties are very tied to Windows Azure.
• Third-parties can easly by-pass the RESTful API for some time.

b. Proxy access to Windows Azure Service Bus

Is this ever possible? The whole flow would be:

1. A third-party asks a TCP API similar to RESTful one in order to get subscribed to some Windows Azure Service Bus topic.
2. The TCP API makes the connection and it creates a proxy in order to mirror TCP API connection to Service Bus I/O to the TCP API-to-third-party.
3. Now third-party is connected to the proxy and sends and receives messages.

Pros

• Third-parties are connected through a proxy, meaning that they don’t own any Windows Azure credential and they can’t potentially by-pass the TCP or RESTful API.
• Messaging isn’t absolutely tied to Windows Azure anymore.

Cons

• What happens if Windows Azure Service Bus closes the connection?
• What happens if the platform proxy goes down?

c. Windows Azure Service Bus server wrapper

This is the definition and flow:

1. The RESTful API server has pool of Windows Azure Service Bus subscription connections.
2. Third-parties are subscribed to a TCP socket or WebSocket of the API server.
3. Whenever Windows Azure Service Bus has a message, it’s routed to the third-party connection pool and the third-party receives the message.
4. Third-parties send messages using a RESTful API.

Pros

• Third-parties are completely agnostic of the service bus technology.

Cons

• Same as b. approach.

Questions

• Is b. approach possible?

• What’s your advise about c. Windows Azure Service Bus server wrapper. Do you find an avoidable war the less reliability in terms of uptime and Windows Azure Service Bus to API and API to third-party synchronization?

• Am I wrong and there’s some alternative to these approaches?

Answer 1

Finally, I opted-in with option a.: Authorize direct access to Windows Azure Service Bus.

This is using the Windows Azure Access Control Service.

Using this approach, third-parties receive an Azure Service Bus connection string with an issuer (an identity) that has specific permissions on some topics. For example: “consumer can only listen”.

For more details about this:

• http://www.windowsazure.com/en-us/develop/net/how-to-guides/access-control/