Difference between revisions of "Software architecture"

From Organic Design wiki
m ({{legacy}})
m (legacy)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{legacy}}
 
{{legacy}}
−
1. The purpose of this document is to describe a collection of free open source software projects that can be packaged together to form a larger system that allows groups using it to work as a [[Platform]] in the [[Platform network]].
+
This article describes a software architecture that supports the Organic Design [[vision statement|vision]] in accord with the [[core values]]. The general topology of this system is a nodal network where every node has a unique identifier and represents a specific persistent object.
  
−
2. The purpose of this document is to define a software application designed specifically to match the [[platform specification]] which is summarised following:
+
== The logical layer ==
−
{{section zero|Platform}}
+
The term ''object'' in the above short description is used in the sense of prototype-based object-oriented programming, where an object is effectively a container of properties, arbitrary content, other objects, and methods accessible via an API. So the informational structure of the object is essentially a hierarchical collection of key/value pairs like a JavaScript object.
−
The software architecture describes the implementation of the specification within the context of our own Linux distro (eventually a GNU Hurd distro) which has a web-desktop integrated at the Window-manager layer. We will make it available in a limited way via exiting operating systems running a client application, and in an even more limited way purely from a browser with no client application present, but the primary aim is for end users who are running the complete operating system solution, and this architecture document will be covering that perspective as its default context of discussion.
 
  
−
The software architecture can be generally divided into three main abstraction layers called the "network layer", the [[Foundation Ontology]] and the "interface layer". There is then an "application layer" on top of this which is not considered to be part of the software since it's in the form of content including persistent objects representing a real-world [[ontology]] of such things as [[trust group]]s, [[member]]s, [[resource]]s and [[system]]s.
+
This network of objects is called the ''logical'' network layer and exists persistently regardless of the nodes coming and going in the physical layer of actual devices and processors.
  
−
== Requirements ==
+
So far what we've described is quite a standard sort of network these days that's used in all sorts of projects, but one thing to bear in mind is that the ''keys'' and ''values'' (when thinking of the object as a collection of key/value pairs) can be hashes that refer to other nodes in the network, and that this is the usual way that they're used in our system. It's still fine to have keys and values of the usual textual kind too so that objects can contain any diverse content, but for the purposes of this article we should always think of them both as node references.
−
The software architecture requires the following of the software (since the [[Platform specification]] has those same equivalent requirements of a Platform organisation)
 
−
*Community developed free software
 
−
*No third-party servers - just the peers composing the network
 
−
*Trustable privacy with reliable decentralised storage and communications including media distribution
 
−
*independent private commerce between peers and groups in the network
 
−
*Decision-making and self-governance tools
 
−
*A unified address space for collaborative content (shared ontology)
 
  
−
== Technology stack ==
+
To be more specific: The network is a peer-to-peer network of hashes similar to a [[DHT]]. The hashes are globally unique identifiers that contain an arbitrary set of related node-hashes where the connecting relation is also a node-hash (i.e. a triple-space). The target node can also be arbitrary text, or a URI allowing the nodes to effectively contain any kind of resource or content.
−
An architecture is a description of a [[system]] which covers a number of abstraction layers and which is often referred to as a "technology stack", for example the [http://www.w3.org/Consortium/techstack-desc.html W3C Technology Stack].
 
  
−
Common interfaces between abstraction layers of operation allow the technology in each layer to be satisfied by different vendors or projects, such as in the layers of hardware architecture, operating system and browser, where each provides a standardised environment that the other layers can interact with regardless of which of the many available options has been selected for it.
+
== The physical layer ==
 +
The physical layer doesn't need to be discussed in any detail here, but suffice to say that the technologies composing the Internet of Things provides the perfect framework in which to host such objects, and ensures that any object has the ability to establish communications channels with any other object via the most efficient path.
  
−
=== Internal & external aspects ===
+
The physical layer is composed of actual real-world resources, and each of these resource-types and each physical instance of these types all have corresponding nodes in the logical network through which they are organised and managed. So we now have three conceptual sets of nodes: purely logical nodes, physical resource types and physical resource instances.
−
There is also a dichotomy of "internal" and "external" which apply both as a whole, and also to each layer in the stack which all have their own aspects that fall into both the internal and external sides.
 
  
−
For example the World Wide Web can be seen from the "browser side" (inside the web) as a collection of documents and application-forms within a tree of domain-names and file-path names. But there is also a "server side" which is outside of the web since it can't be reached directly from in the "web browsers" and isn't composed of HTML content that a web-broswer could even recognise. This server side is composed of physical network connections and computers, filesystems and operating system services etc.
+
These resources cover all types of processors, storage and bandwidth and cover all scales from processes running on a devices up to human roles working on machine. All of them are integrated into the network by having their methods connected into the logical network to be presented as a standard API that other nodes can interface with.
  
−
In terms of technology stacks, the external side of the Internet is computers and ethernet connections at the bottom, then IP addresses and domain names on top of that, and then protocols for web pages, email and chat etc and finally interface such as browsers and desktops at the top. The inside aspect's stack involves concepts such as users, groups, document types, active user sessions, folders, windows, forms and buttons, events and schedules etc.
+
== Class/Instance ==
 +
The process of creating a new node requires that it be an instance of another node, creating new completely empty nodes is not possible. This leads to the network being a tree structure with a root node. This means that all nodes in the network inherit the functionality of the root node.
  
−
=== Our stack ===
+
Instances can have any amount of content added or even content removed, so the fact that they have to be based on something is not a limitation, but allows the network to keep track of what nodes have in common with each other and how they differ.
−
{| border
 
−
|-
 
−
!external!!internal
 
−
|-
 
−
| - || -
 
−
|-
 
−
| - || -
 
−
|-
 
−
| - || -
 
−
|-
 
−
| - || -
 
−
|}
 
−
== The network layer ==
 
−
In the standard web-based paradigm, this layer would be referred to as "the server side" since it's the system at the other end of the HTTP connection that the interface environment (JavaScript/DOM) is communicating with. In our case it doesn't make sense to call it "the server side" because it's a service running on the same machine as the browser in which the interface is running (connecting through ''localhost'' using HTTP as a [[Single Page Application]]).
 
  
−
The primary purpose of the network layer is to provide the '''users''' and '''groups''' oriented functionality including the persistent storage of their content. It does this in a [[peer-to-peer]] configuration, and keeps the group's ontology consistent in real-time (as long as a network connection between them is present).
 
  
−
There is actually no technical difference between a ''user'' and a ''group'', the only real difference is that in the case of a user only one person has the PGP key to access its private content, but in the case of a group node a number of members have private access. The node's content, structure and functionality will then evolve accordingly becoming more single-user or group oriented over time.
+
== Relationships ==
 +
The root node is also the one that implements the base relationship functionality that comes from a node being connected to other nodes.
  
−
Authentication involves an interface device allowing a user or process to use its private key to open a "session" through which it accesses a nodes internal content, functionality or resource. "Session" is just a fancy name meaning; time during which a [[viewer]] application is connected to a user or group node in the network. There could be many active sessions viewing a particular node since there could be many connected members viewing it and each could be logged in from many devices and locations at the same time.
+
The entire effect that the relationship has on the end-nodes of a relationship is done by the relationship node. This is the basis of the "action not opinion" value, the meaning of a relationship is a description of what it does.
  
−
It's the job of the network layer to ensure that all the change occurring within the content structure of a group is routed promptly to all the viewers of it amongst all their diverse locations and technologies. Each group can be considered as a live collaborative "channel" where its members are ''subscribers'' to the content.
+
...
  
−
== The interface layer ==
+
== Space ==
−
The interface is a [[viewer]] (in the [[MVC]] sense) onto the [[unified ontology]] which is a [[peer-to-peer]] network. The viewer is a standard web-browser based [[Single Page Application]] using the [[Livelets]] SWF method so that events can be propagated asynchronously from the local peer up to the browser instances, and interface events can be routed the other way down into the peer if necessary. The browsers current URL determines the node in the network which currently has focus, and the specific context within that focus such as views, sub-views and actions.
+
All the types of resource are organised into a tree, and nodes can "own" a certain amount of any of these. All these resources are able to flow around the network through channels (which are also resources) that connect the instances of resource. All these resources can be connected by their APIs with simple connector scripts (either on or off chain depending on context). Nodes can be made into complex hierarchical structures of services and contracts to represent larger-scale functionality such as organisations.
 +
 
 +
...
 +
 
 +
== Time ==
 +
The scheduling method by which these services interact with each other over time is encoded purely by the semantic relationships between them. This scheduling aspect covers parallel and serial structure of order as well as event-based connections. A normal schedule is a bunch of "slots" of time and resource into which specific instances are allocated.
 +
 
 +
In this system the same is true, where the slots are specified in terms of roles, and they're organised in a semantic relational network specifying order, hierarchy and events instead of just the normal linear timeslots. The nodes are the resource instances, but the way they're connected together forms the energy aspect.
 +
 
 +
== Energy ==
 +
An energy-oriented view of any node is available since its resource usage over time is known. This gives rise to the ability to budget (cache) and determine the total active and potential energy of a node. What products and services its possible to perform and what profit and loss this entails.
 +
 
 +
== Organisation ==
 +
The way all the aforementioned functionality works is encapsulated into the [[generic organisation]] node, which is the most general template for starting a new organisation, ether at the computer process scale, or the real-world people-oriented scale.
 +
 
 +
== Interface ==
 +
The [[viewer]] is the default generic organisation at the computer process level, and the [[trust group]] is the default real-world people-centric generic organisation. After trust groups are more refined we'll start defining [[platform]] more clearly which brings physical operating premises into the equation.
 +
 
 +
The viewer is a standard web-browser based [[Single Page Application]] that connects to the network via a local service. The browsers current URL determines the node in the network which currently has focus, and the specific context within that focus such as views, sub-views and actions.
 
:http://localhost/#node/path/view/action...
 
:http://localhost/#node/path/view/action...
 
We've made an experimental start on this idea which is being documented in the [[Nodal interface using corMVC]] article. The most important point in this URL format is the hash character since no change in the URL after that character is considered to be outside of the current document, so the entire viewer session is self-contained into a [[Single Page Application|single DOM instance]] requested only once at the start of the session.
 
We've made an experimental start on this idea which is being documented in the [[Nodal interface using corMVC]] article. The most important point in this URL format is the hash character since no change in the URL after that character is considered to be outside of the current document, so the entire viewer session is self-contained into a [[Single Page Application|single DOM instance]] requested only once at the start of the session.
Line 65: Line 61:
  
 
:peer → [[trust group]] → user session (persistent) → interface session (not persistent) → view
 
:peer → [[trust group]] → user session (persistent) → interface session (not persistent) → view
−
 
−
== Foundation ontology ==
 
−
Within the context of the software architecture, the [[Foundation Ontology]] runs in the same runtime environment (i.e. same programming language etc) as the network layer. It means that a peer can be a fully functional part of the network even if it has no display capability (i.e. a "headless" server configuration).
 
−
{{section zero|Foundation Ontology}}
 
−
*content revisions and history
 
−
*persistent user sessions into the persistent groups
 
−
*scheduling and workflow
 
−
*exchange and accounts (note that this could require dedicated support from the network layer since it's extremely difficult to achieve in a solid way and needs to tie in closely with the p2p and security aspects. We envisage integrating the network layer with [[Bitcoin]] to achieve this aspect.)
 
−
*package management (installation of external functionality)
 
  
 
== Applications ==
 
== Applications ==

Latest revision as of 20:28, 2 September 2017

Legacy.svg Legacy: This article describes a concept that has been superseded in the course of ongoing development on the Organic Design wiki. Please do not develop this any further or base work on this concept, this is only useful for a historic record of work done. You may find a link to the currently used concept or function in this article, if not you can contact the author to find out what has taken the place of this legacy item.

This article describes a software architecture that supports the Organic Design vision in accord with the core values. The general topology of this system is a nodal network where every node has a unique identifier and represents a specific persistent object.

The logical layer

The term object in the above short description is used in the sense of prototype-based object-oriented programming, where an object is effectively a container of properties, arbitrary content, other objects, and methods accessible via an API. So the informational structure of the object is essentially a hierarchical collection of key/value pairs like a JavaScript object.

This network of objects is called the logical network layer and exists persistently regardless of the nodes coming and going in the physical layer of actual devices and processors.

So far what we've described is quite a standard sort of network these days that's used in all sorts of projects, but one thing to bear in mind is that the keys and values (when thinking of the object as a collection of key/value pairs) can be hashes that refer to other nodes in the network, and that this is the usual way that they're used in our system. It's still fine to have keys and values of the usual textual kind too so that objects can contain any diverse content, but for the purposes of this article we should always think of them both as node references.

To be more specific: The network is a peer-to-peer network of hashes similar to a DHT. The hashes are globally unique identifiers that contain an arbitrary set of related node-hashes where the connecting relation is also a node-hash (i.e. a triple-space). The target node can also be arbitrary text, or a URI allowing the nodes to effectively contain any kind of resource or content.

The physical layer

The physical layer doesn't need to be discussed in any detail here, but suffice to say that the technologies composing the Internet of Things provides the perfect framework in which to host such objects, and ensures that any object has the ability to establish communications channels with any other object via the most efficient path.

The physical layer is composed of actual real-world resources, and each of these resource-types and each physical instance of these types all have corresponding nodes in the logical network through which they are organised and managed. So we now have three conceptual sets of nodes: purely logical nodes, physical resource types and physical resource instances.

These resources cover all types of processors, storage and bandwidth and cover all scales from processes running on a devices up to human roles working on machine. All of them are integrated into the network by having their methods connected into the logical network to be presented as a standard API that other nodes can interface with.

Class/Instance

The process of creating a new node requires that it be an instance of another node, creating new completely empty nodes is not possible. This leads to the network being a tree structure with a root node. This means that all nodes in the network inherit the functionality of the root node.

Instances can have any amount of content added or even content removed, so the fact that they have to be based on something is not a limitation, but allows the network to keep track of what nodes have in common with each other and how they differ.


Relationships

The root node is also the one that implements the base relationship functionality that comes from a node being connected to other nodes.

The entire effect that the relationship has on the end-nodes of a relationship is done by the relationship node. This is the basis of the "action not opinion" value, the meaning of a relationship is a description of what it does.

...

Space

All the types of resource are organised into a tree, and nodes can "own" a certain amount of any of these. All these resources are able to flow around the network through channels (which are also resources) that connect the instances of resource. All these resources can be connected by their APIs with simple connector scripts (either on or off chain depending on context). Nodes can be made into complex hierarchical structures of services and contracts to represent larger-scale functionality such as organisations.

...

Time

The scheduling method by which these services interact with each other over time is encoded purely by the semantic relationships between them. This scheduling aspect covers parallel and serial structure of order as well as event-based connections. A normal schedule is a bunch of "slots" of time and resource into which specific instances are allocated.

In this system the same is true, where the slots are specified in terms of roles, and they're organised in a semantic relational network specifying order, hierarchy and events instead of just the normal linear timeslots. The nodes are the resource instances, but the way they're connected together forms the energy aspect.

Energy

An energy-oriented view of any node is available since its resource usage over time is known. This gives rise to the ability to budget (cache) and determine the total active and potential energy of a node. What products and services its possible to perform and what profit and loss this entails.

Organisation

The way all the aforementioned functionality works is encapsulated into the generic organisation node, which is the most general template for starting a new organisation, ether at the computer process scale, or the real-world people-oriented scale.

Interface

The viewer is the default generic organisation at the computer process level, and the trust group is the default real-world people-centric generic organisation. After trust groups are more refined we'll start defining platform more clearly which brings physical operating premises into the equation.

The viewer is a standard web-browser based Single Page Application that connects to the network via a local service. The browsers current URL determines the node in the network which currently has focus, and the specific context within that focus such as views, sub-views and actions.

http://localhost/#node/path/view/action...

We've made an experimental start on this idea which is being documented in the Nodal interface using corMVC article. The most important point in this URL format is the hash character since no change in the URL after that character is considered to be outside of the current document, so the entire viewer session is self-contained into a single DOM instance requested only once at the start of the session.

When the node ID changes by clicking on links or buttons in the application, JavaScript events are called by the DOM which update the page and may involve an AJAX request through localhost to the local peer instance for other nodes' content in the peer-to-peer network.

Its job is to render a users persistent user session which may include many concurrent logins across a number of devices allowing applications and hardware (such as processing, storage, bandwidth, inputs and displays etc) to be shared amongst the devices producing a single "desktop environment" together. Each user generally has just one persistent session at a time (although there's nothing to stop a "power user" from running many concurrently or shelving some for later use etc). Such persistent sessions are viewed using the locally available "views" in a "network viewer" application (an interface layer typically running on a machine connecting through localhost to a network layer "peer" instance).

The running interface layer is only temporarily active in RAM and is typically running in a browser DOM environment (in the form of a single-page application) and lasts for the duration of the user login. The currently selected "view" within this browser DOM environment is even more transient but is considered as one of the abstraction layers since it's the conceptual equivalent of a running application in a desktop environment.

peer → trust group → user session (persistent) → interface session (not persistent) → view

Applications

We consider "applications" to be defining "what a trust group can do", for example following is a list of some of the common requirements a typical trust group would have in the network. This list sounds like some pretty normal readily available functionality, but bear in mind that all of this takes place in peer-to-peer space with complete privacy when desired and without any dependence on any kind of third-party external resources or services.

  • maintain content together (like using a wiki, blog or other CMS)
  • maintain media channels (e.g. shared playlists or radio stations)
  • maintain software and packages (work on code together and manage releases)
  • govern and make decisions together (see group decision-making and self governance)
  • manage projects together (assign tasks, raise issues, track time etc)
  • engage in commerce together

See also

Retrieved from "https://organicdesign.nz/wiki/index.php?title=Software_architecture&oldid=122833"