NIST logo
*

****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