Project Design

In this exercise we'll go over the design of our new project.

Table 1.1. Design Considerations

Design Element Description
Generic, Data-Driven Approach We'll write an application service that executes the compute workload. This won't require us to change the user interface of make any modifications to any application. The only thing we really need is the GEOTIFF elevation data. Everything else will be self-contained. As with all API design, there may be questions about whether or not the code we write could be more widely used. For example: should some of the image processing code we write be promoted to the Simdify Scripting Language utility libraries for the <Image> class? We'll leave these questions for later and get something running first. Afterwards, perhaps in future exercises, we can think about wider API considerations, but it's very difficult to know in advance how this application could affect existing APIs.
Scripted Plugins We want to make sure that this design allows us to write Simdify Scripting Language code in a 'plugin style'. This means that we want the Layout application to know as little about the workloads as possible, and we want to delegate that responsibility to the scripts that implement the service. In order to accomplish this kind of extensibility, our design requires a little more work upfront. However, it will be worth it because it will be easier to promote code to general libraries if we write the code with the right abstractions from the beginning.
Don't Neglect Quality of Life Features We need to make sure that we pay attention to quality of life features. For example: the ability to enable and disable workloads is very important, as is the ability to specify that the workload is in a debug state. Otherwise, it will be frustrating to try to modify code that executes workloads.
Pay Attention To Service Boundaries Service boundaries are also very important. Without clear service boundaries, we run the risk of making the application know too much about the workloads, and we run the risk of making the scripts that implement the system know too much about each other. For any service, the underlying script code should only know about the function call signature required for it to execute. Otherwise, we run the risk of having changes to the application require changes to the service scripts. With some changes we will be unable to avoid refactoring the scripts that process the workloads, but we want this to happen as little as possible.

Now let's create a small 'to do' list for the project and discuss each element. It might be a good idea to write these items down so you can keep track of them as you work through the exercises. Or, you can refer to this document from time-to-time.

Table 1.2. To Do List

Project Item Description
Download Elevation Data We will download elevation data from the United States Geological Survey website that we'll use as source data for our implementation.
Create Service Script We'll create a new script that implements an empty service.
Create Service Classes Script We'll create a new script that implements classes to store service input and output data.
Create CPU Image Processing Library We'll create a new script that implements CPU image processing functions for extracting data from GEOTIFF image files, cleaning the data, and generating array textures that we can feed to compute shaders.
Create GPU Image Processing Library We'll create a new script that implements GPU image processing functions that process the elevation data and prepare it for analysis. This includes generating visual representations.
Create Report Generation Library We'll create a new script that generates an HTML-based report that uses CSS and Javascript to deliver a nice user experience. We'll make sure to generate a report that can be view on a PC and a mobile device as well.
Finish Service Implementation We'll finish the service implementation by writing code that uses the CPU, GPU, and report generaton libraries to complete the entire workload.

Finally, we'll discuss an initial service boundary design below. These are just guidelines that we can change if needed.

Table 1.3. Service Boundaries

Service Group Scripts
Service Orchestration Group. These scripts implement and orchestrate the service.
  • app_service_workload_analyze_terrain_util.ssl
  • app_service_workload_analyze_terrain_classes.ssl
Service Execution Group. These scripts execute the workload.
  • app_service_analyze_terrain_cpu_image_processing_util.ssl
  • app_service_analyze_terrain_gpu_image_processing_util.ssl
  • app_service_analyze_terrain_generate_report_util.ssl