2055 Rate this article:
5.0

Cost-effectively Converting Legacy IDL Desktop Applications to Enterprise Applications

 

Porting your IDL® application to an enterprise or cloud-based system can seem daunting. In reality, it’s quite simple and straightforward with the IDL programming language. This blog describes using your IDL license to create a backend application and how an IDL frontend client can be distributed using the IDL Virtual Machine (or an IDL Runtime license for operational environment). I will also cover using the IDL Task framework to develop code that can be accessed via a web application with an IDL backend.

Most people equate enterprise applications to integrated systems with web browsers on the client side (frontend), plus core business logic modules on the server side (backend), which is only partially true. While it is very common to run the frontend in a web browser for enterprise applications, it does not have to be this way. In fact, if you don’t have a web developer, this can be an excellent way to execute server side tasks. So long as HTTP/HTTPS protocol is supported and RESTful API calls can be made, the frontend can run in the environment of Java, C/C++, Python, etc. Either can run in IDL.

Let’s look at Image Quality Metric Toolkit (IQMT) as an example. IQMT is a L3Harris Geospatial offering for calculating standard image quality measures and assigning a National Imagery Interpretability Rating Scale (NIIRS) value from a single-band image. It was developed as a desktop application using the ENVI® API, and it can run in wizard/interactive mode as well as batch mode. This tool could be used in a data center with incoming imagery to determine if the quality of each downlinked image meets the desired NIIRS rating required for customer delivery.

IQMT uses ENVI functions for image processing and analytical calculations, but the input wizards and output displays do not necessarily depend on ENVI. Therefore, we can modify the core and heavy-duty functions of IQMT into ENVI or IDL tasks and deploy them on GSF (Geospatial Services Framework) as the backend. The frontend, working as the input wizards and output displays, interacts with those IQMT tasks on GSF using RESTful API calls via the backend server.

As an example, the edge identification and RER (Relative Edge Response) calculation of IQMT has been turned into an IDL task, CalculateEdgeRERTask, and deployed on GSF. A directory-watch server is set up to monitor the image file arrival and requesting CalculateEdgeRERTask to automatically start processing when a new image file arrives.

To run the frontend in a web browser, for example, a testing node.js web server is set up locally running at http://localhost:3000, updating every three seconds and waiting for the execution result of CalculateEdgeRERTask. The table rows automatically grow and populate with the results after images arrive and are processed by CalculateEdgeRERTask.

 

Figure 1. A web browser displays initial state and updated results after images arrive and are processed on the server automatically.

 

To run the frontend in IDL, in contrast, it is not necessary to set up a web server. Talking to the GSF server directly, the IDL client behaves similarly and displays the same content as the web browser-based client (Figure 2).

 

 

Figure 2. IDL client displays initial state and updated results after images arrive and are processed on the server automatically.

 

Although working well and serving the purpose, most people are likely to point out that using IDL client requires a license. Developing IDL applications (IDL tasks as well as IDL clients) indeed requires a license. However, using an IDL client running with the IDL Virtual Machine does not. To do this, the end user would download the .sav file of the IDL client and use it on any machine that can talk to the backend server, for free.

Note the IDL VM does have a splash screen that must be dismissed. For users who would like to not have this splash screen, such as for critical operational usage, IDL runtime licenses remove the splash screen and also allow users to use IDL ‘execute’ function to call external code.

To sum up, to develop code – frontend UI or backend processing – you need an IDL license. To run code for free, you need to create a .sav file and the end user downloads the virtual machine. To either distribute a license with your application or have the user not dismiss the splash screen and or if you need to call external code, an IDL Runtime license is needed. For widely distributed operational applications that need a runtime, your IDL account manager can work on bulk pricing.

Let’s walk through another example. Below is a project where L3Harris Geospatial built an IDL User Interface (UI) and analytics tool for Australian Bureau of Meteorology's Tsunami (AusBOM) Decision Support Tool (DST). AusBOM DST is used operationally to assess whether a tsunami is likely to hit Australia or the Indian Ocean region. If it is assessed that a tsunami is likely, the DST aggregates necessary information and generates appropriate warnings.

L3Harris Geospatial Solutions Delivery team supported the original development of this application and then provided upgrades and service-support to the DST as their needs evolved. More information can be found in the article “IDL Programming Language is Engine Behind Australian Tsunami Decision Tool.”

 

Figure 3. The DST (v11.1) used in training mode for assessing the tsunami threat to Australia caused by an earthquake of magnitude 8.6 off the west coast of South Island, New Zealand.

As shown in Figure 3, the IDL UI of DST has many features to serve operational workflows. DST users in AusBOM are retrained every time a new release is deployed. If DST moved to the enterprise with a browser-based client (note: this is simply an idea and does not imply in anyway about Bureau's inclination towards such an idea), its UI should work with features that are very similar to the desktop UI. One prototyping example is shown as Figure 4. Even though the core functions of the DST could be modified to IDL tasks working on a backend server, the web-based client would need to be developed from scratch and a map server would need to be set up for DST to operate as a web application.

Alternatively, a future enterprise DST can go with an IDL client, which will have almost the same look-and-feel UI as currently in operational use. The IDL client itself can display map-related information just as the desktop DST does. There’s no need to set up a map server. However, at the backend a database server would need to be added. This eliminates local file writing, such as writing the event log in JSON files (a prototype example shown in Figure 5), and warning transmission log in .sav files that are currently implemented in the desktop DST.

This change is one of the “must-be-done” items for the DST to go enterprise. It will ultimately manage synchronizing event logs, bulletin counters, and product generation for multiple users simultaneously using the DST. Currently in the desktop DST, the synchronizations are handled by file-locking and merging local files with remote files, which takes care of occasional dual users simultaneously using DST.

Of course, other issues may need to be addressed for the IDL client to run successfully on any machine. The L3Harris Solutions Delivery team can support assessing and performing code changes. For the DIY crowd, online documentation and tech support may provide the resources to make needed changes to the original IDL application.

On the backend, running IDL or ENVI tasks on GSF does require a license. If performance degrades when the number of IDL client users increase, you may need to scale up GSF by running the tasks on multiple nodes with a license on each node, which is beyond the scope of this article. More information about GSF can be found here.

Let’s recap before wrapping up this topic. It’s worth considering IDL client UI as an option when converting IDL legacy desktop applications to enterprise applications. The main reasons to use the IDL UI for this are:

  1. No license is required to run IDL client in the IDL Virtual Machine.

  2. Significant portions of the desktop application code can most likely be reused in developing its enterprise version.

  3. Training costs for application users may be much less because the application UI may stay the same. Frontend users will likely not notice any changes.

  4. If a browser-based client UI becomes necessary later, it should be easy to replace the IDL client because no changes are needed on GSF at the backend.

 

Figure 4. Prototyping example for browser-based UI of enterprise DST.

 

 

Figure 5. Prototyping example for IDL client UI of enterprise DST after JSON files were replaced with a MySQL database table for DST event log.

 

The IDL Task framework can ultimately make it easy to convert legacy code to be accessible via a webserver by using GSF. An IDL client can be distributed at no cost, or at a minimal cost, to access the backend applications on a desktop or virtual desktop. The same code can be reused if you want to develop a web application, saving time in rearchitecting working code for a different environment. As data volumes increase, cloud storage use grows, and the need for desktop analytic code needs to move to server environments, IDL has flexible “right sizing” to fit your need and budget.

DISCOVER MORE

ENVI DEEP LEARNING MODULE

AUTOMATE ANALYTICS

Automate analytics with deep learning for fast, accurate results.

WHAT’S NEW IN ENVI & IDL WEBINAR

RECORDED WEBINAR

ENVI 5.6.1 and IDL 8.8.1 introduce many new, exciting, and impactful features!

Open Source Technologies for ENVI and IDL

RECORDED WEBINAR

Explore novel ways to use ENVI + IDL with open source technologies

 

 

 

 

 

Please login or register to post comments.