[Source: http://geekswithblogs.net/EltonStoneman]
In my previous post, Cloud Services and Command-Query Separation: Part 1, I looked at the design of a service bus in the cloud based on Command-Query Separation. In this post, I’ll walk through a sample solution meeting the design, using Amazon Web Services.
Sample Cloud Service Bus Solution
I’ve worked through an implementation of this using Amazon Simple Queue Service and Amazon SimpleDB – it’s on github here: Cloud Service Bus sample solution. I’ll be extending it with the Azure alternatives in a later post.
CloudServiceBus is a VS 2010 solution, split into service, client and shared projects. To get started, you’ll need to sign up for an Amazon Web Services account, sign up for SQS and SimpleDB and set up your Access Identifiers. You’ll need to provide payment details, but trying out the solution won’t cost you anything provided you stay within the free tier (processing fewer than 100,000 messages a month).
Then there’s some one-time setup work to populate your own Access Key, Secret Key and message queue URL into the config files:
- Enter the AWSAccessKey and AWSSecretKey values to all the App.config files;
- Run the Service Provider solution and copy the “listening for messages” URL to the QueueUrl value in the client App.config – something like https://queue.amazonaws.com/[yourAWSid]/Sixeyed-CloudServiceBus-RequestQueue.
Run the solution with F5 and two console windows will load. The service provider is handling two types of message – GetChangedEmployees, which is a query service to retrieve a set of entities, and FlushDataStore which is a command service to empty the data store. The client window loads showing the URL of the public queue where requests are sent, and the URL of the private queue (generated randomly by the client) where this instance is listening for responses:
Type “get -1” in the client to retrieve a (randomly-generated) list of employees changed in the last day. You should see debug messages on the client when the message is sent, then on the server when the message received and the data is stored, then on the client again when the response message is received and the data is pulled:
Enter “get -1” again and the response will be much faster, as the service provider checks the data store and finds the data already there, so saves the time to build and store it. Enter “get -2” and a new set of data is stored and retrieved.
Load up multiple client and server windows and you’ll see the load being shared among servers, and clients receiving the correct responses on their private queues.
Enter “flush” at the end to clear out your SimpleDB store.
Implications
The cloud CQS service bus is a very different pattern from a synchronous on-premise ESB, but for solving the same type of problems the cloud solution has a lot to recommend it. Most appealing is the simplicity with which an access-anywhere solution can be built (the Cloud Service Bus sample took half a day to code and test), and the potential for that simple solution to grow to accommodate huge levels of service.
In my next post I’ll look in more detail at the implications of the cloud solution.