GeoSuite Demo

Hello folks!

If you’re up to date with the latest news you probably already know that we have reasons to be very happy, our Crowdcube campaign is overfunded! If you didn’t know about that, good news for you, you still have the opportunity to be part of it and invest now 😉

We’re back after a few days to show you the first part of our GeoSuite demo, one of the fundamental pieces of the infrastructure we want to build. GeoSuite is a software suite for the interconnection of DLT and big data ETL and some of you may ask yourself, why a software suite? GeoDB is ‘only’ a DLT protocol to share information at the big data level, right?. Well, we aspire to be a little more than that.

Why GeoSuite

Unlike other tools shown in previous posts, GeoSuite is not ‘only’ a tool to develop our proposal, it’s the way to develop our vision. Maybe it sounds ambitious, but let us explain our approach.

In a world of multiple DLT solutions that are being developed right now as isolated islands, we seek to build bridges. From the beginning, our vision is that it doesn’t make sense to bet on a single DLT technology as the winner of a fierce figurative contest. There are unique DLT projects adapted to specific niches, some overlapping projects and many of them that complement each other, and this isn’t an anomaly, it’s the usual scenario every time a technological revolution is brewing. Who can limit innovation?

For us, DLT enthusiasts, the future lies in the interconnection, and GeoSuite is our proposal in this area. Obviously we’re aware that there are thousands of different alternatives, so we have not gone crazy and tried to reinvent the wheel, we did not seek to offer a tool that connects all of them. We propose something simpler than that, we propose a tool from which it will be possible to support and connect any necessary solution.

Instead of developing a fabulous golden cage that shines but that limits the options of our users, we want to provide all the facilities so that they can move easily between any point, and the best way to do this is to do it from the beginning.

To develop the infrastructure for a new DLT solution, a perfectly valid (and usual) approach is to define a specification and then develop the necessary network nodes and tools (either open or closed) using the most in-use technologies. In our case we follow a similar approach. The improvement with GeoSuite is that these tools will be developed in a modular environment of an expandable, adaptable and interconnectable nature, and in which anyone can participate.

GeoDB is an open source project with specifications that anyone can implement, but with a reference implementation that will be developed to be executed in GeoSuite. Using it, anyone can deploy and configure GeoDB nodes or execute queries to purchase information. But they can also deploy and configure nodes of any other DLT supported, obtain information from other integrated marketplaces, use the information obtained directly in any necessary tool or create completely new solutions.

So, whether you’re a user who wants to provide a node for our infrastructure or consume information from it, you’ll have a single tool and platform to do it, but if you need to operate at the same time with different nodes of different DLT networks, combine information from different sources or analyse the results in an integrated solution you can also do it. In short, GeoSuite is not an environment that interconnects every project, it is an environment that allows to interconnect every project.

Do you want to obtain data from GeoDB? With GeoSuite you can do it. Do you want to combine this data with another source of information and analyze them using Spark or Hadoop? With GeoSuite you can do it too. Do you want to store your results in a DLT infrastructure to raise some oraquelization? GeoSuite. Do you want to enrich your analytics directly with GeoDB data? GeoSuite.

And not only that, as an open, adaptable and configurable environment, the range of possible solutions to create is immense.

Do you want to run a node for some DLT network and you don’t know which of them is more profitable? Why not develop a component that manages the nodes in execution based on the current price of the different cryptocurrencies and thus optimize your profits?

Do you have a solution with monetizable data but which has little value by its own? Why not incorporate a connector in GeoSuite so that when a user makes a query they can acquire them directly and transparently?

As we indicated above, we don’t want to support every solution, but rather create an environment that allows to support them. However, we want to give initial support to some well-known technologies in order to validate our proposal, demonstrate that this integration is easy and exemplify how it’s carried out. We’ve already experimented with some DLT technologies (note for DLT enthusiasts, experimented != developed), such as Hyperledger Fabric, IPFS or IOTA. From this last one we even published a blogpost some time ago in which we showed the support of a node in a modular OSGi environment (surely, our motivation to do this is understood now 🙂 ).

Without further ado, we present the first part of this demo, which is still far from being that complete solution described before. This first part is limited to the acquisition of GeoDB information. Before showing it, and in order to understand its operation from the perspective of GeoSuite, let us explain the underlying technologies on which it is based.

GeoSuite architecture

GeoSuite is an Eclipse E4 RCP application that integrates several features developed following an OSGi modular architecture. This architecture allows to add and manage features transparently, which results in a living environment that evolves to meet the needs of its users.

But first, why using a modular architecture like OSGi instead of a monolithic one? It might seem that this type of architecture produces complex solutions that are difficult to maintain, but this is the result of a simplistic approach. Modularity allows us to manage complexity and be tolerant with uncertainty.

Software engineering is a new and evolving discipline, and there is constant innovation in both techniques and theoretical foundations. Therefore, we still do not know which are the best paradigms to develop a given solution, but this does not mean that there are no certainties. One of the most celebrated books for having brilliantly reflected several of these certainties is the one published in 2003 by Robert L. Glass, “Facts and Fallacies of Software Engineering”. Many of the quotes contained in this book have been taken by developers and software architects as principles that guide their daily work. One of them, which focuses precisely on complexity, and which is sometimes referred to as Glass’s Law, states that:

For every 25% increase in problem complexity, there is a 100% increase in complexity of the software solution.

Modularity allows us to deal with this problem directly. If we analyse the way in which the complexity of the solution increases as the complexity of the problem increases, it is obvious to deduce that, if we divide the solution into its constituent elements, we will move from a solution that doubles its complexity if complexity of the problem increases a 25%, to a solution in which this increase in complexity will only be reflected in the elements involved.

In “The Mathematics of IT Simplification”, Roger Sessions proved that Glass’s Law can be restated in modular terms into:

A module with b functions is 10log(C)*log(b)/log(F) times more complex than a module that contains just 1 of the functions. Being C the complexity of the software solution and F the complexity of the problem.

And what does this mean in practical terms? Suppose a solution with 9 functional units. The software solution can be developed in multiple ways, but to illustrate our case we will consider two different proposals: i) a monolithic solution A, and ii) a modular solution with components B and C. In a monolithic system, the complexity of the solution can be computed as C = F^3.11, so complexity of A=928, whereas the combined complexity of B and C is 75+149=224, or what is the same, 24% of the complexity of A.

Therefore, it’s clear that the complexity of the solution does not increase if you follow a modular architecture, but it’s significantly reduced. In our case, we build GeoSuite using OSGi, a vendor-independent, standards-based approach to modularizing Java software applications and infrastructure. OSGi proven services model enables application and infrastructure modules to communicate locally while being distributed across the network, providing a coherent end-to-end architecture [https://www.osgi.org/developer/what-is-osgi/].

Additionally, we use Eclipse Rich Client Platform technology, or Eclipse RCP, which has been developed under an OSGi architecture and provides several open source components of high quality and actively maintained with which develop advanced features in a simple way.

https://wiki.eclipse.org/Eclipse4/RCP/Architectural_Overview

Thanks to these technologies, GeoDB exposes several features that postulate it as a tool to be included in the toolbox of GeoDB users, data scientists and anyone interested in DLT technologies, since its allows to:

• Access and manage GeoDB modular nodes easily.
• Integrate any functionality necessary to interoperate with different technologies whether they are data sources, web services, third-party software or other DLTs.
• Encourage community participation in the development of GeoSuite compatible modules in order to increase the available features.
• Follow a rolling release development model in which the user can always stay updated without effort.

GeoSuite is a versatile solution that provides a wide range of features, which are subdivided into three general categories.

Core functionalities

They allow to adapt the suite to users’ needs and include features such as accounts management, GeoCloud (a SSI solution) administration, AppStore (a marketplace for GeoSuite) access or activation and deactivation of features among others.

GeoDB infrastructure management

They allow to manage GeoDB modular nodes to provide infrastructure capabilities. With these features, users can start, stop and manage the nodes, obtain statistical information about them, use custom modules to provide additional functionality or deploy their own nodes and DLTs using modules developed for the suite.

Big data analytics

They allow to buy datasets, execute algorithms and software libraries developed in the same suite, use third-party tools to enrich the information or integrate other software to carry out a customized analysis.

Purchase information using GeoSuite

As we said before, today we stick to the acquisition of information from GeoDB and in our opinion, to understand how a software works there is no better way than to see it in action.

If you want to try it you can download the release candidate versions here, but we must warn you that they’ve only been tested in GNU/Linux, so if you use Windows or Mac, it may not work correctly.