The IVAAP data model was created after researching the commonalities between the industry data models. However, when we built it, we kept in mind that each data store carries its own set of information, information that is useful for users to consume. This is why we made “properties” a part of the data model itself. From an IVAAP SDK point of view. “Properties” is a set of name-value pairs that you can associate with specific entities within the IVAAP Data Model.
One of the productivity features of the IVAAP Data Backend SDK is that the services developed with this SDK are container agnostic. Practically, it means that a REST service developed on your PC using your favorite IDE and deployed locally to Apache Tomcat will run without changes on IVAAP’s Play cluster.
While the Data Backend SDK is traditionally used to serve data, it is also a good candidate when it comes to developing non-data related services. For example, as part of IVAAP 2.8, we worked on a “gridding” service. In a nutshell, this service computes a grid surface based upon the positions of a top across the well of a project. When we tested this service, we didn’t deploy it to IVAAP’s cluster, it was deployed as a standalone application, as a servlet, on a virtual machine (VM).
As the use cases of IVAAP grow, the implementation of the data backend evolves. Past releases of IVAAP have been focused on providing data portals to our customers. Since then, a new use case has appeared where IVAAP is used to validate the injection of data in the cloud. Both use cases have a lot in common, but they differ in the way errors should be handled.
This release confirms IVAAP as a leader in the subsurface data visualization space, supporting Data Visualization and Data Management for Subsurface, Exploration, Drilling, or Production Applications in the cloud. Houston, TX — INT is pleased to announce the newest release of its HTML5 upstream visualization platform, IVAAP™ 2.6, accelerating the pace of our release cycle […]
When doing demos of IVAAP, the wow factor is undeniably its user interface, built on top of GeoToolkit.JS. What users of IVAAP typically don’t see is the part accessing the data itself, the IVAAP backend. When we designed the IVAAP backend, we wanted our own customers to be able to extend its functionalities
One of the unique features of the IVAAP backend SDK is that you can develop your own data connectors and services with the IDE you are already familiar with. The data backbone of IVAAP is meant to be deployed in a cluster made of multiple nodes for scalability and reliability. However, despite the distributed nature of such a deployment, our SDK requires no particular plugin to compile or execute your code. The tools needed to develop a plugin for IVAAP’s backend are identical to the tools you would need to develop classic Java Servlets: a Java SDK (Oracle, OpenJDK), an IDE (Eclipse, NetBeans) and an application server (Tomcat, Glassfish).
The purpose of IVAAP’s backend is to access data from many data sources and present this data in a unified manner to the IVAAP HTML5 client. Performance is key, and some data stores are faster to access than others. 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.
As a new member of the software development team, I had no prior experience with development on IVAAP, INT’s HTML5 visualization framework for upstream E&P solutions. My first task was to add a data connector, so to gain knowledge of IVAAP and to understand more about the IVAAP software development kit, I used the IVAAP developer’s guide. I found this guide quite useful as it made the key points behind IVAAP easily understandable. Coding with IVAAP is actually easy, and I was surprised by several features of the platform and SDK that make it quite simple to learn.