Zend_Cloud_Queue is a component in the Simple Cloud API that provides a common API for cloud application queue services, such as Amazon SQS and Windows Azure Queue Storage. The design goals of this API include simplicity, portability across cloud queue services, stability, and extensibility for future expansion.
3. Component Requirements, Constraints, and Acceptance Criteria
This component must support creating queues.
This component must support deleting queues.
This component must support listing all queues associated with an account.
This component should support fetching metadata for queues.
It would be nice if this component supported storing metadata for queues.
This component must support sending individual messages to a queue.
This component must support receiving one message from queues with a visibility timeout.
This component should support receiving more than one message from queues with a visibility timeout.
This component must support deleting messages from queues.
It would be nice if this component supported peeking messages.
4. Dependencies on Other Framework Components
Zend_Exception
Cloud queue client libraries under the Zend_Service namespace.
5. Theory of Operation
Although there are some differences in the queue APIs offered by cloud vendors, there is a set of common runtime operations that can be supported in one API. Note that unique value-add offerings such as peeking messages in Azure's API are not must-have features.
The API follows a more 'functional' model, as opposed to an OOP paradigm, to more easily model services available via RESTful, SOAP, and RPC interfaces. Such an API will also negligibly affect performance, while allowing users to build their own object-oriented data access libraries on top of the simple methods it exposes.
This proposal covers only components implemented for Zend Framework, but these interfaces and classes have been designed to be implementable in other languages and/or package structures.
6. Milestones / Tasks
Milestone 1: [DONE] Simple Cloud API project launched.
Milestone 2: Community review sufficient to submit proposal for recommendation.
Milestone 3: Implement API and adapters in Zend Framework trunk.
Milestone 4: Document API.
Milestone 5: Address issues as necessary for production release.
<p>This looks really good. Will this replace the current Zend_Service_Amazon_Sqs or just provide hooks into what is currently there and being maintained.</p>
<p>There will be a Zend_Cloud adapter for Zend_Service_Amazon_Sqs. I'll make an initial version of this adapter and unit tests for the interface available shortly.</p>
<p>There will be a Zend_Cloud adapter for Zend_Service_Amazon_Sqs. I'll make an initial version of this adapter and unit tests for the interface available shortly.</p>
<p>I like the goals that are set out for Simple Cloud. However, I haven't quite made up my mind wether I like the "functional" approach or not. I do see and largely agree with the reasoning behind. I also can't quickly come up with an OO design that serves a purpose other than making the component look more OO. In short, go for it <ac:emoticon ac:name="smile" /></p>
<p>Edit:<br />
Let me clarify "largely agreeing with". Zend Framework is an OO framework. Also, any other PHP framework, Java, C#, Ruby or <ac:link><ri:page ri:content-title="programming language here" /></ac:link> has the ability to implement an OO approach. The exceptions to this case might be languages like Haskell, which will most likely come up with their own API anyway.</p>
<p>Hmmm. We should really call this the 'procedural' approach, so we don't get it mixed up with functional programming. I'll fix that in the proposal.</p>
<p>In any case, the procedural approach was taken for a few reasons:</p>
<ul>
<li>To simplify the API so that it clearly indicates the functionality it provides</li>
<li>To make room for others to build an OOP model on top of these interfaces, if desired</li>
<li>To avoid using PHP features that aren't available in other OO languages to ease adoption of this API in other communities</li>
</ul>
<p>That said, I'm open to any changes. Even making the interface more model- or resource-centric. I just couldn't figure out how to do this without sacrificing the simplicity that is part of the project's goals. Please throw out any ideas you have on this.</p>
<p>Huh? We're considering a queue class and it doesn't implement Zend_Queue_Adapter_AdapterInterface and follow the conventions set forth by that component?</p>
<p>Matthew and I actually spoke with Daniel Lo and Justin Plock about this very issue before the announcement. We decided to leave room in Zend_Queue for additional features because there was a lot of feedback on the Zend_Queue proposal calling for more message-oriented features.</p>
<p>As Matthew (Weier O'Phinney) points out, Zend_Cloud_Queue was designed specifically for simple queues in the cloud, like SQS. Features that aren't common to most of these queue service offerings will not be supported in Zend_Cloud_Queue. We're actually planning to have a Zend_Cloud_Queue_Adapter_ZendQueue (the naming can- and probably should- be tweaked) adapter. This will provide support for local queues through Zend_Queue, which is important for 'offline' development for the cloud. We will probably write direct adapters from Zend_Cloud_Queue to Zend_Service_Amazon_Sqs, however.</p>
<p>As with all design decisions in the Simple Cloud API, we're open to new ideas. So if there is a better way to do this, throw it out there so we can discuss it.</p>
<p>I was hoping we could avoid anything that looks like a remote object, but I think we need a value object for messages. There are 2 properties we need- id and body- and putting them in an array feels like a hack to me. Thoughts?</p>
<p>Archiving this proposal, feel free to recover it when you want to work on it again. For more details see <a href="http://framework.zend.com/wiki/display/ZFDEV/Archiving+of+abandoned+proposals+(Feb+5+2011)">this email</a>.</p>
12 Comments
comments.show.hideOct 05, 2009
Jon Whitcraft
<p>Wil, </p>
<p>This looks really good. Will this replace the current Zend_Service_Amazon_Sqs or just provide hooks into what is currently there and being maintained.</p>
<p>Jon</p>
Oct 08, 2009
Wil Sinclair
<p>There will be a Zend_Cloud adapter for Zend_Service_Amazon_Sqs. I'll make an initial version of this adapter and unit tests for the interface available shortly.</p>
<p>,Wil</p>
Oct 08, 2009
Wil Sinclair
<p>There will be a Zend_Cloud adapter for Zend_Service_Amazon_Sqs. I'll make an initial version of this adapter and unit tests for the interface available shortly.</p>
<p>,Wil</p>
Oct 05, 2009
Jurrien Stutterheim
<p>I like the goals that are set out for Simple Cloud. However, I haven't quite made up my mind wether I like the "functional" approach or not. I do see and largely agree with the reasoning behind. I also can't quickly come up with an OO design that serves a purpose other than making the component look more OO. In short, go for it <ac:emoticon ac:name="smile" /></p>
<p>Edit:<br />
Let me clarify "largely agreeing with". Zend Framework is an OO framework. Also, any other PHP framework, Java, C#, Ruby or <ac:link><ri:page ri:content-title="programming language here" /></ac:link> has the ability to implement an OO approach. The exceptions to this case might be languages like Haskell, which will most likely come up with their own API anyway.</p>
Oct 08, 2009
Wil Sinclair
<p>Hmmm. We should really call this the 'procedural' approach, so we don't get it mixed up with functional programming. I'll fix that in the proposal.</p>
<p>In any case, the procedural approach was taken for a few reasons:</p>
<ul>
<li>To simplify the API so that it clearly indicates the functionality it provides</li>
<li>To make room for others to build an OOP model on top of these interfaces, if desired</li>
<li>To avoid using PHP features that aren't available in other OO languages to ease adoption of this API in other communities</li>
</ul>
<p>That said, I'm open to any changes. Even making the interface more model- or resource-centric. I just couldn't figure out how to do this without sacrificing the simplicity that is part of the project's goals. Please throw out any ideas you have on this.</p>
<p>,Wil</p>
Oct 07, 2009
Matthew Ratzloff
<p>Huh? We're considering a queue class and it doesn't implement Zend_Queue_Adapter_AdapterInterface and follow the conventions set forth by that component?</p>
Oct 08, 2009
Wil Sinclair
<p>Matthew and I actually spoke with Daniel Lo and Justin Plock about this very issue before the announcement. We decided to leave room in Zend_Queue for additional features because there was a lot of feedback on the Zend_Queue proposal calling for more message-oriented features.</p>
<p>As Matthew (Weier O'Phinney) points out, Zend_Cloud_Queue was designed specifically for simple queues in the cloud, like SQS. Features that aren't common to most of these queue service offerings will not be supported in Zend_Cloud_Queue. We're actually planning to have a Zend_Cloud_Queue_Adapter_ZendQueue (the naming can- and probably should- be tweaked) adapter. This will provide support for local queues through Zend_Queue, which is important for 'offline' development for the cloud. We will probably write direct adapters from Zend_Cloud_Queue to Zend_Service_Amazon_Sqs, however.</p>
<p>As with all design decisions in the Simple Cloud API, we're open to new ideas. So if there is a better way to do this, throw it out there so we can discuss it.</p>
<p>,Wil</p>
Oct 15, 2009
Peter Smit
<p>I think you should consider using the word receive instead of recieve...</p>
Oct 16, 2009
Wil Sinclair
<p>Drats! My devious plan to create an enduring misspelling on the scale of 'referer' has been foiled! <ac:emoticon ac:name="cheeky" /></p>
<p>Thanks for the report. It's fixed in the branch I'm about to move over to the laboratory.</p>
<p>,Wil</p>
Oct 26, 2009
Wil Sinclair
<p>I was hoping we could avoid anything that looks like a remote object, but I think we need a value object for messages. There are 2 properties we need- id and body- and putting them in an array feels like a hack to me. Thoughts?</p>
<p>,Wil</p>
May 13, 2010
Artur Ejsmont
<p>I like the API, seems very clean and simple. That's the way i like it.</p>
<p>Is it still in initial draft? its half year? is any development in process? maybe need some help?</p>
<p>Would be good to have that kind of apis in stable zend : )</p>
<p>Art</p>
Feb 08, 2011
Dolf Schimmel (Freeaqingme)
<p>Archiving this proposal, feel free to recover it when you want to work on it again. For more details see <a href="http://framework.zend.com/wiki/display/ZFDEV/Archiving+of+abandoned+proposals+(Feb+5+2011)">this email</a>.</p>