INTGeoServer v3 is a rewrite on INTGeoServer v2, with a strong focus on the cloud and performance. This rewrite brings many new features highlighted below.
INTGeoServer v2 supported only files posted on a local file system such as NFS. INTGeoServer v3 introduces additional support for files posted in:
Amazon AWS S3
Microsoft Azure Blob Storage
Google Cloud Storage
Each one of these options is called a connector.
Local file access (similar to what INTGeoServer v2 was providing) is performed by the geofiles connector
Amazon AWS S3 file access is performed by the s3 connector
Microsoft Azure Blob Storage file access is performed by the blobstorage connector
Google Cloud Storage file access is performed by the cloudstorage connector
Posting a file to a file system or to the cloud doesn't change the format of these files. You do not need to perform extra processing to your SEGY or LAS files when posting to the cloud compared to posting them to a local file system
INTGeoServer v2 only supported one source of data per server instance. The INT_GEOSERVER_HOME environment variable could point to only one home directory on disk.
INTGeoServer v3 allows several connectors in the same server instance. Not only you can have several geofiles connectors configured in the same server instance, but you can have several connector types in one server instance as well. For example, an INTGeoServer v3 instance can host several s3 and geofiles connectors at the same time (see Configuration of Data Sources).
Because hosting large files on the cloud has costs, the INTGeoIndexer desktop application that is used to index seismic files has been modified to allow decimated transpositions, where only a few time slices are created instead of one for each possible time value.
INTGeoServer v3 supports this new decimated file format.
INTGeoServer v3 makes use of the asynchronous options of the Servlets API to allow more concurrent users per server.
INTGeoServer v3 also leverages the Akka API for greater scalability of its services.
INTGeoServer v3 supports ZFP seismic compression
INTGeoServer v2 used layer.xml files to "plug" behaviors. INTGeoServer v3 uses registration annotations instead.
One benefit of annotations is that they are faster to write. The main benefit of INTGeoServer v3 annotations for developers is that when you change the name of a plugged class, or when you change its package, you do not need to update this registration.
INTGeoServer v3 follows the OpenAPI guidelines (http://spec.openapis.org/oas/v3.0.2), where the method (GET, POST, PUT, DELETE) is the verb/action and the URL designates the object being operated on.
All INTGeoServer v3 services are reachable from the /INTGeoServer/api/about starting point, following HATEOAS (https://en.wikipedia.org/wiki/HATEOAS) links.
This improves the discoverability of these services.
INTGeoServer v3 and the IVAAP data backend share the same code base, giving developers a direct path to upgrade to IVAAP when needs evolve. A service written with the INTGeoServer v3 API can be deployed to the IVAAP data backend without changes.
IVAAP provides multiple options that are not included in INTGeoServer v3. Such options are:
an entitlement system (users, groups, domains) to control access to your data. By default, INTGeoServer doesn't require any authentication to access data
a project system to group datasets logically. By default, INTGeoServer doesn't support projects
deployment of multiple instances as one manageable cluster that is auto-scalable. By default, INTGeoServer is deployed as standalone Tomcat instances.
This documentation assumes developers are using INTGeoServer. Developers using IVAAP typically need to pass a bearer token in the HTTP Authorization header when calling these services.
Also note that the INTGeoServer URLs typically start with http://myserver.mycompany.com:8080/INTGeoServer/api. The IVAAP URLs typically start with http://myserver.mycompany.com:8080/ivaap/api
Contact support@int.com for more information on IVAAP.