The Object Network is designed to be a global web of structured data items linked by URLs and interacting with each other to evolve their state. Those objects may be running on remote servers, in our clothing, in our environment or in our phones, tablets and home computers. They are addressed by IPv6 and interact in a peer-to-peer model.
Each object is very much like a JSON object and each has something very much like a URL to identify and locate it. Objects are exchanged between peers over the network through a protocol very much like HTTP, but with cache update built in.
A core piece of the Object Network lies in the use of those identifiers or URLs. An object can link to a peer object through a string containing another object's id. Objects - or their animating programs - can only see and react to peer objects that they can reach through these links. Further, an object can never update another object directly.
These two constraints underly the basic Object Network programming model or interaction and animation model - which is called "Functional Observer". This model says:
"An object's new state is a function of its current state including the state of peer objects observed through links".
It's simple as you can program in terms of the dependency of local object state on peer object states, just like in spreadsheets. Then many of these simple local rules can result in complex emergent, distributed behaviour. This allows you to achieve complexity by writing little local solutions, making a local object work with what's already there and building up.
Functional Observer and the Object Network cover many common programming tasks for you: distribution of your data, data updates and notifications, cacheing, cache freshness, saving data to files, threads, concurrency and inter-process communication. These are all functions that an implementation of the Functional Observer model will take off your hands, leaving you free to focus on your particular domain logic, and any specialised I/O or adaptors and integrations you need.
It's flat, not lumpy: there are no apps or applications in the Object Net, just interacting data in a global web. You simply animate your own corner of this global data structure. There are no application boundaries - everything can link up with and interact with everything else. It's open to anyone to create active objects linked up by URLs in the network, that work with their peers. There are no silos or walled gardens, interoperability is achieved through URLs and common data types - everything is visible. It works peer-to-peer so you don't need to ask permission or to use intermediaries or central services.
In the Object Net, even users are first-class objects in the web. An object can link to a user and a user can link back. A user links to their current point of view - the object that represents their vantage point in the Object Net. Users can link to each other and communicate directly without intermediary servers. This is ideal for creating anything like a virtual world.
It's maintainable as you don't have to stop the world to upgrade one thing; new things drop in and go.
It's robust because one object or host of objects can go down without completely killing others; there's no central point of failure.
It's scalable through distributed processing and splitting of workload. This model of independently-animated objects interacting is naturally concurrent, which means its easier to write programs that do more work quicker.
It's also scalable through only transferring across network exactly what's needed, exactly when it's needed: fine-grained objects and their updates.
It's also faster to run local programs, scripts or rules over local objects because it removes the delays you get with more centralised approaches.
It's a natural for eventual consistency models.
It's more secure because it doesn't depend on central or remote single points of vulnerability.
It has all the benefits of the Web, as described in REST, but is symmetric, two-way and dynamic.
Natively, for efficiency, the Object Net uses Object Network Format (ONF) instead of JSON, UIDs instead of URLs and Object Network Protocol (ONP) instead of HTTP. However, for integration with other systems, JSON, URLs and HTTP can all be used instead.
Contact me and/or subscribe to my blog and/or follow me on Twitter.