****WORKING DOCUMENT****
4.4 Migrate a Queuing-Based Application
Actors: cloud-subscriber, cloud-provider-1, cloud-provider-2, cloud-management-broker
Goals: Migrate an existing queue and associated messages from one cloud-provider to another
Assumptions: cloud-subscriber is responsible for modifying applications accessing queues to access new queue after migration.
Success Scenario (IaaS): A cloud-subscriber wishes to migrate a cloud-provider-1 queue and its associated current messages to cloud-provider-2. Both cloud-provider-1 and cloud-provider-2 implement an agreed minimum set of message attributes, queue attributes and queue operations to facilitate migration activities. Cloud-subscriber issues a command to cloud-management-broker to migrate queue X on cloud-provider-1 to queue Y on cloud-provider-2. Cloud-management-broker issues commands using native API to cloud-provider-2 to create queue Y. Cloud-management-broker issues commands using native API to cloud-provider-1 to stop queue X processing in order to create a steady state. Cloud-management-broker issues commands to cloud-provider-1 to access messages in queue X and commands to cloud-provider-2 to create identical objects on queue Y using agreed minimum attribute set. Cloud-provider issues a start command to Queue Y and notifies cloud-subscriber.
Failure Conditions: (1) Cloud-provider is unable queuing operations; (2) cloud-provider cannot provide sufficient information in a timely manner about the status of queues.
Failure Handling: The cloud-provider notifies the cloud-subscriber of the failure and provides a description of the failure.
Credit: This use case inspired by Amazon's simple queuing service. http://aws.amazon.com/sqs