SimpleCloud Part 3 – The Abstract Job

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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

namespace com\zend\jobqueue;
 
abstract class JobAbstract
{
    protected abstract function _execute();
 
    public final function run()
    {
        $this->_execute();
    }
 
    public function execute()
    {
        $mgr = new Manager();
        return $mgr->sendJobQueueRequest($this);
    }
 
}

There are only three methods.  The first is _execute().  This method needs to be overridden.  It is the code that will be executed on the remote server.  And because it will be serialized and executed on the remote host, the code for your job class will need to be deployed there.  You could actually send the source code for the class along with the serialized version and make the backend COMPLETELY stupid, but I would think that anyone remotely security minded could see the problem with that.

To implement a new job, do something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

namespace org\eschrade\jobs;
 
use comzendjobqueueJobAbstract;
 
class SendEmail extends JobAbstract
{
    private $mail;
 
    public function __construct(Zend_Mail $mail)
    {
        $this->mail = $mail;
    }
 
    protected function _execute()
    {
        $this->mail->send();
    }
}

Then to send the job to the queue call:

1
2
3
4
5
6
7

$mail = new Zend_Mail();
$mail->setSubject('This is a test');
$mail->addTo('Kevin', '[email protected]');
$mail->setBodyText('Some boring text');
 
$sendMail = new SendEmail($mail);
$sendMail->execute();

The execute() method is called on the front end.  But it doesn’t really execute.  It calls the queue manager and queues it on the backend servers.

Then on the backend servers (remember the executeJob() method?) the run() method is called, which actually calls the _execute() method, which contains the logic.  And while I didn’t show it here, because this job is re-serialized after execution you can store status information any other data attached to the object in that object and, once it’s unserialized on the front end after calling getCompletedJob() on the job manager.  If the job is completed it will return the unserialized instance of, in this case, orgeschradejobsSendEmail as it existed at the end of its run.

Now, to get to the SimpleCloud portion of this series; Storage.  The link for part 4, discussion storage, is in the related stuff section.