The LEADTOOLS Cloud SDK provides developers with a complete framework which can be used to create powerful cloud-based applications. By deploying your solution to the cloud, you move the resources necessary for your application from the end-user's machine or device to an environment you control. Since these resources are controlled by you, your application can scale with user demand, without the need to change the application itself.
Once the LEADTOOLS Cloud SDK is installed on the system, the user is ready to begin creating powerful applications which can be deployed to the cloud. Please note that LEADTOOLS Cloud features must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features.
LEADTOOLS Cloud SDK can be used in any scenario where you want to perform some type of automated job processing on a farm of computers. This opens a wide range of opportunities: consider the following examples:
A service where users can submit a file to be converted from one format to another. Using a web interface for submitting the file, the actual conversion is performed on a farm of worker machines in the cloud. After conversion is complete, the converted file is sent back to the user.
A service where users can submit images from their desktop or mobile device to be processed for OCR (Optical Character Recognition). After an image is received by the cloud service, it is processed, OCR is performed, and the results are sent back to the user, to be archived in a database or whatever the application architecture requires.
You have a farm of worker machines dedicated to crawling websites. The LEADTOOLS Cloud framework can be used to distribute websites in a queue fashion to the different worker machines and monitor the crawling process for each website.
LEADTOOLS Cloud SDK Framework
The LEADTOOLS Cloud SDK is a complete framework and can be broken down into 3 individual components as described below. For your reference, a diagram showing these individual complements and the workflow between them can be seen in Figure 1.
Client - The Cloud clients can be any type of computer or mobile device. Communication between the clients and the central server is based on Microsoft WCF services, so this allows for a platform-independent solution.
The clients communicate with the cloud via the JobService WCF service, which is hosted on the central server. The JobService allows clients to add, abort, delete, and monitor the status of existing jobs. For more information, refer to the IJobService interface.
Central Server - The central server is the primary interface between the clients and the worker machines, and has the following responsibilities:
Host the JobService and WorkerService WCF Services.
Store cloud settings. This includes what types of jobs each worker will take, the maximum number of concurrent jobs for each worker, CPU thresholds, etc. For more information, refer to LEADTOOLS Cloud Settings. Storing cloud settings on the central server allows user administrators to make global changes to all the worker machines in the cloud from a single location.
The central server may or may not contain the cloud database. For simplicity, let's assume the cloud database is installed on the central server. The cloud database is used to store all jobs, and any information related to each job. For more information, refer to Understanding the LEADTOOLS Cloud Database.
Worker Machine - The worker machines are the ones that actually perform the work for the cloud framework. There is no limit to the number of worker machines in the cloud: this depends on the specific needs of your cloud. As with the clients, communication between the worker machines and the central server is based on Microsoft WCF services. Each worker machine can be configured to process specific types of jobs. In addition, it can have machine-dependent settings for the maximum number of concurrent jobs, maximum CPU threshold, and other related settings. For more information, refer to LEADTOOLS Cloud Settings.
Each worker machine hosts a windows service, which communicates directly with the central server via the WorkerService WCF Service. The windows service will use the WorkerService to obtain new jobs ready for processing, as well as to update the status of any jobs the worker machine accepts. For added stability, each job is processed in a separate process spawned by the windows service, which communicates directly with the windows service. The windows service will monitor the process for progress, status updates, etc. In the event where the process terminates unexpectedly, hangs, or experiences any other fatal error, the windows service will kill the process if necessary, and provide the developer with the ability to react to these issues via the OnJobTerminated Method, and continue to process new jobs.
When the Windows Service is paused, jobs currently in progress will continue to process, but no new jobs will be accepted until the service is resumed. If the service is stopped, or the machine is shut down, all jobs currently in progress will be terminated, and their status will be rolled back to the last status before the job was started. This allows these jobs to be attempted again when the service resumes.
You can begin creating LEADTOOLS Cloud clients by adding a web reference to the JobService WCF Service. The JobService WCF Service contains the various interfaces, classes, structures and delegates necessary to create a cloud client capable of adding, aborting, deleting, and monitoring the status of existing jobs. For more information, refer to the IJobService interface.
You can begin creating LEADTOOLS Cloud Workers by adding a reference to the Leadtools.Cloud.Job.dll assembly. This assembly contains the various interfaces, classes, structures and delegates necessary to create a cloud worker capable processing jobs in your cloud. For more information, refer to the Creating Cloud Worker Assemblies.
Figure 1: A diagram showing the LEADTOOLS Cloud SDK components complements and the workflow between them.