2431 Rate this article:
No rating

Should Apps be Federated too?

Mark Alonzo
In the world of enterprise geospatial operations we often see data (imagery, vector layers, etc.) managed in federated databases.  A federated management strategy essentially maps several disconnected warehouses of data to a single, virtual database. This helps to avoid replicating large datasets in multiple locations or merging heterogeneous databases. Federation is great for military ISR organizations that may be collecting imagery in multiple theaters but want to centralize the discovery and exploitation of that imagery at home. But what about geoprocessing tasks or apps? These are the analytical routines that are applied to data to extract meaningful information or to predict a future event. We typically require apps to be local to the data for the most efficient processing.  However, when big data is federated, we may need the apps in several places. And that's o.k.  Because apps are relatively small and are easy to distribute using formats like OGC GeoPackage, Esri Geoprocessing Packages, or ENVI Services Engine task bundles. Once we start sharing apps we run into some management problems. Where is the gold standard app? Is it local to the data I would like to process? Is it the most recent version? What is its service interface?  I think that keeping track of app location and its nearest data source will become important for maintaining efficiency, consistency of service, and product quality. Is a federated approach the way to do this?

Please login or register to post comments.