Now that we’ve gotten some job processing code done, let’s get into the good stuff. The first thing we’re going to look at is the storage mechanism in SimpleCloud. The example we used was uploading an image to the server so it could be resized for viewing at multiple resolutions or junk. Now, you could simply attach the file contents to the job class, serialize it and unserialize it on the other side. But the Job Queue server is really not designed for that (nor are most other queueing applications). So what we’re going to do is use the Storage mechanism in SimpleCloud (in this case, S3) to store the files temporarily and then for the resized versions.

Earlier in December I did a webinar on the Zend PHP Cloud Application Platform. It’s not some new product or anything like that, but rather a view of how our software is going to fit together. It’s not something that will be “released” in the typical software fashion. Instead it is the mindset of our product development teams when they look at building new features. Cloud-based pricing for Zend Server, AWS/Cloud integration in Zend Studio, and, of course, SimpleCloud.

In the previous installment I talked a little about the cloud, what Zend is doing in the cloud and what the example application for my ZPCAP webinar did. One of the primary characteristics of scalability is the ability to process data as resources are available. To do that I implemented the Zend Server Job Queue with an abstraction layer that I’ve written about three different versions for. I think the fourth will be the charm :-).

We have so far looked at setting the stage and managing the job. How about executing the job itself? The job we will look at here will be relatively generic. I will get into more detail after I have talked about the SimpleCloud elements. This, here, is simply to show you the theory behind how jobs are executed.

The abstract class is pretty simple.