Plug and play style interaction between nodes in the systems. Versatile systems that support many different use cases and architectures. Robust systems that can survive failure and has self-healing capabilities when failure conditions are fixed.
Communicate via a fast network protocol. This in term means a compact, binary protocol. Communicate asynchronously, as many real-time systems require. Can handle at least 1.000 messages per second, though our real goal is between 10.000 to 100.000 messages per second.
Support for both synchronous and asynchronous communication. Support for more message exchange patterns than just request-response. Faster and more compact on the wire than HTTP / JSON. Support for more use cases than document exchange and RPC.
We have implemented discovery via a versatile semantic protocol called the directory protocol. Nodes can connect to the directory service to register entities they want to expose to other nodes. Entities can be services, data (e.g.files), users, or whatever else a node would like to expose to other nodes. In particular Entities can register their location independently of other entities.
With just few lines of code you can get your services up and running. Simple and easy to use APIs to make your life easier than ever!
The better a platform performs, the more clients can be served by the same hardware. Our focus on high performance and scalability means we can keep the prices lower than many other cloud platform providers. Slow platforms are expensive platforms.
Nanosai is designed with high performance and scalability in mind. The asynchronous message oriented architecture helps with that. Additionally, our services are designed to keep data in memory as much as possible. Even databases are kept in memory.
These are our core open source projects that are directly related to the vision described in our eBook. However we will be adding more tooling projects such as our Java application launcher and class loader ModRun that can be used outside our core projects.
Free eBook explaining our vision for a better internet. We call this design "The Grid" to distinguish it from "The Web".
The free to download eBook describes the open grid standards which are mainly related to open network protocols that when implemented properly will meet the goals set forth in the grid vision.
The core open source implementations of the grid standards to make it easy for developers to versatile build distributed systems based on the grid standards.
The implementations can be used as is, or as base for implementations in other languages. We have of course decided to start first with a Java implementation.
The IAP Object Notation (ION) is a binary data format that can be used to encode a wide variety of data. It is expressive enough to contain serialized objects (e.g. Java or C# objects), CSV, JSON, XML, text and binary data.
ION is fast and reasonably easy to parse and generate, more compressed on the wire than JSON and XML, and easy to handle for servers and routers (we believe).
IAP (Internet Application Protocol) is a message oriented network protocol designed for both synchronous and asynchronous communication, making IAP suitable for many different use cases such as RPC, file exchange, streaming, message queue subscriptions.
We created IAP because existing protocols such as HTTP did not meet our versatility and high performance requirements.
Before nodes in a distributed system can interact they need to find each other. This is typically referred to as “discovery”. We have addressed discovery via a semantic protocol called the directory protocol. The directory protocol is implemented by a directory service and the technical reason for calling it a "directory protocol" and not a "discovery protocol" is simply because it can be used for more than just discovery of nodes.
Nodes can connect to the directory service to register entities they want to expose to other nodes. Entities can be services, data (e.g.files), users, or whatever else a node would like to expose to other nodes. In particular when an entity is exposed, its entity id is mapped to some information about the entity. For now we have limited that information to details about where to access the entity, such as IP address, port number, protocol needed to access the entity etc. In future we might expand to other kinds of information as needed.