Simple WorkFlow Service – SWF
Web service to coordinate work across distributed application components [ Human tasks outside of process can be included as well ] – Tasks represent invocations of logical steps in Applications.
SWF Task is assigned once, never duplicated.
SWF Tasks can be stored for up to one year
SWF keeps track of all tasks in an application
SWF ACTORS
- Workflow Starters [ Application or event ] that kicks off workflow
- Workflow Deciders Controls the flow of activity based on outcomes of task state
- Activity Workers – programs that interact with SWF to get tasks, process them and return results
Simple Queue Service – SQS
SQS is a Web Service that gives access to message queues that can be used to store messages while they are waiting to be processed.
SQS is a distributed Queue System that enables applications to queue messages that one part of an app generates to be consumed by another [ de-coupled ] part of that application.
De-Couple Application components so they can run independently; SQS acts as a buffer between components.
SQS is “Pull based” , meaning instances poll and ask it for work.
Messages are 256 KB [ and can be in 64 KB chunks ]
Messages can be stored in SQS for:
- as little as 1 min
- DEFAULT of 4 days
- up to 14 days
For SQS STANDARD QUEUE: VisibilityTimeOut is the amount of time that the message is “invisible” in the SQS queue after a EC2 (or other reading software) retrieves that message.
- If job is process BEFORE the VisibilityTimeOut expires, messages is deleted from queue
- If job is not processed within VisibilityTimeOut, the message will become “visible” again and another EC2 will pull it; possibly resulting in same message being delivered twice.
VisibilityTimeOut MAX is 12 hours
SQS [ Standard Queue ] will guarantee a message is delivered at least once.
- but will NOT guarantee message order
- but will NOT guarantee message is ONLY delivered once ( e.g. could be delivered twice )
Long Polling vs. Short Polling: In almost all cases, Amazon SQS long polling is preferable to short polling. Long-polling requests let your queue consumers receive messages as soon as they arrive in your queue while reducing the number of empty ReceiveMessageResponse instances returned.
Long-Polling does not return a response until message is in message queue. [ will save money, because you are not polling an empty queue ]
Short-Polling, returns immediately; even if queue is empty.
