• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

INT

Empowering Visualization

  • Blog

IVAAP

Using Scopes in IVAAP: Smart Caching and Other Benefits for Developers

By Thierry Danard | November 13, 2018

With the release of IVAAP 2.2 coming up, there are lots of new features to explore. Since more data sources have being added, the Software Development Kit (SDK) of IVAAP’s backend has also grown. As developers get acquainted with IVAAP’s Application Programming Interface (API), one often-asked question concerns the presence of a scopeUUID parameter in several method declarations: What is this scope, and why is it useful?

Smart Caching

The purpose of IVAAP’s backend is to access the data from many data sources and present this data in a unified manner to the IVAAP HTML5 client. This backend is written in Java and accesses SQL databases, web services, basically any type of data store. Performance is key, and some data stores are faster to access than others. For example, web services tend to have much higher latency than SQL databases. In a web service configuration, a smart caching strategy is required so that the same web/HTTP calls are not made to the same data store twice while a service request is being fulfilled, regardless of its complexity. This is where the concept of scope comes in.

A scope is defined as a short-lived execution, and within this short lifetime, it’s generally OK to assume that two identical calls to the same data store will return the same result. The scopeUUID is a unique identifier of a scope. A scope is created automatically when an HTTP request is sent to a backend service, and disposed of when that entire request has been fulfilled. Depending of the performance characteristics of a data source, developers working on a data connector have the option to reuse cached information across the time span of a scope.

Scopes are needed because of the asynchronous nature of IVAAP’s execution architecture. Asynchronous code is not as common as synchronous code; it’s more complex to write, but tends to withstand higher workloads, which is a key requirement for IVAAP. If service executions were performed synchronously, the scope would be strongly associated with the current thread, and developers would typically cache the same information in a ThreadLocal variable instead.

Identifying the Source of a Method Call

While the most common use of scopes is for caching, being able to identify the source of a method call can be quite useful when running your application. In a synchronous world, the Java call stack provides this information. But in an asynchronous world where messages are being passed between actors, this call stack provides very little useful information. The IVAAP API allows you to build a useful call stack while developing. For example, if your backend code makes a call to an external web service, but you’re not sure why, you can plug your own AbstractScopesController class to control when this scope is created, then plug your own AbstractActorsController class to track how actors spawn other actors within that scope.

Managing Transactions

A third typical usage of scopes is to help with the management of transactions. When you retrieve a connection from a SQL connection pool, knowing the scope allows you to decide whether to reuse the same connection instead of the first one from the pool. Transactions are tightly associated with connections, and, without a scope, you’d need to pass connections around while a transaction is in play. Passing a scopeUUID instead avoids this code clutter, allowing you to easily implement APIs that are truly data-source agnostic.

Scope: Just More Code Clutter?

This brings me to the main objection to scopes: “Isn’t passing a scopeUUID a code clutter of its own?” The answer lies in how a developer plans to use the IVAAP backend SDK. If you use this API to write synchronous code, the scopeUUID will appear to get in the way. If you use the same API to write asynchronous code, you’ll find that the internal maintenance of scopes doesn’t affect the implementation of your actors. The scopeUUID of a service request is passed automatically from one actor to the next, without the developer’s intervention. If your data source is fast enough that it doesn’t require caching, if you do not make use of transactions, your asynchronous code will not need to be aware of scopes. It’s only when you will have to troubleshoot the relationships between actors at runtime that you might come to appreciate its usefulness.

Visit our products page for more information about IVAAP or contact us for a demo.


Tags: ivaap, SDK

Primary Sidebar

SEARCH THE BLOG

Top Posts

  • INT Advances IVAAP as Universal Subsurface Cloud… January 7, 2022
  • How Apache SIS Simplifies the Hidden Complexity of… February 17, 2022
  • Intel OpenVino and IBM Red Hat Select IVAAP to… July 29, 2021
  • How to Generate Dynamic Forms Using JSON in IVAAP April 21, 2022
  • GeoToolkit.JS: New Features and Improvements in Carnac 3D February 25, 2022
  • Rethinking ML Integration to Deliver a User… July 6, 2021
  • Raster Log and TIFF Rendering in the Cloud with… January 26, 2022
  • INT Joins SLB Digital Platform Partner Program,… February 2, 2023
  • Latest Release of INT’s GeoToolkit.JS Brings More… December 8, 2021
  • INT and ANPG Improve Collaboration on Oil & Gas… June 28, 2022

Footer

Solutions

  • For E&P
  • For OSDU Visualization
  • For Cloud Partners
  • For Machine Learning
  • For CCUS
  • For Geothermal Energy
  • For Wind Energy
  • For Enterprise
  • Tools for Developers
  • Customer Success Stories

Products

  • IVAAP
  • GeoToolkit
  • INTViewer
  • IVAAP Demos
  • GeoToolkit Demos

About

  • News
  • Events
  • Careers
  • Management Team

Resources

  • Blog
  • FAQ

Support

  • JIRA
  • Developer Community

Contact

INT logo
© 1989–2023 Interactive Network Technologies, Inc.
Privacy Policy
  • Careers
  • Contact Us
  • Search

COPYRIGHT © 2023 INTERACTIVE NETWORK TECHNOLOGIES, Inc