The Nexus is the name given to an integration technology which will be deployed as part of the Prosperity4All project. This system has not yet been implemented, although many of the base libraries required for it are nearly complete. Whilst it will not initially be co-deployed with the GPII's "universal" module and will form a separate deployment during its early development, in time this will become a set of endpoints that will indeed be co-deployed as a core part of the GPII architecture - a "Nexus" will be available wherever there is a GPII "FlowManager" as well as in numerous other situations. The deployment footprint of a "Nexus" is even lower than that of a "FlowManager" since one may exist purely within the context of a single page in a web browser - as well as scaling up to local and distributed deployments as the "FlowManager" does.
The Nexus does not originate new protocols but simply uses standard protocols already existing as part of standardised web technologies. The protocols named here are not exclusive, and it would be perfectly possible to construct bindings to the Nexus over other protocols if they were found sufficiently widespread and usefully adopted - such as MQTT, CoAP, etc. The intent of the Nexus and its protocols is to useful constrain semantic in a way that will promote genuine interoperability - that is, to promote the chance that messages may be successfully understood and acted upon, with minimal fresh programming-language-level development ("code") and architectural overhead - rather than that they may merely be received and decoded, which is the province of the underlying protocols themselves.
The Nexus forms what has been described in the literature as an integration domain (#Kell09) - an alternative viewpoint might cast it as a system for composition of synthesized web services (#Fen08) (SWS, SWM, SST, etc.). In this case, we make no immediate plans for allowing users to discover the space of states of component services and hence construct synthesized services by composing the respective machines (although we plan to act as a platform on which such highly complex inference could proceed in the future). Instead, we plan to in the first instance encourage all participants to follow an integral model whereby all interesting states of their components are represented by distinct, fully realised bodies of publically addressable state - and whereby component composition simply consists of the composition of these bodies of state, and component interfacing simply consists of transduction of corresponding values of this state, which are brought into equivalence by means of (primarily) symmetric lenses (#Pierce11).
Note that as a result of this much more simplified correspondence - that is, correspondence between the values of the state itself, what we refer to under the name Model Transformation (Model Relay) is a very much more simple thing than often goes by that name in the wider literature - which refers to transformations between the structures of state machines rather than simply the state. However, wherever we succeed in representing the correspondences between state as proxies for the states of any respective machines, naturally we will succeed in putting any supervening machines into correspondence as well, without necessarily becoming aware of the fact.
The Nexus API
Read the specification (as JSON) of a component with a particular global name
global.name: String - the name of the component grade whose defaults are to be read
Protocol/Method: HTTP GET
Kell09 Stephen Kell. The Mythical Matched Modules: Overcoming the Tyranny of Inflexible Software Construction. In the OOPSLA 2009 Companion, Onward! Innovation In Progress track, October 2009 Author's preprint
Fen08 W. Fan, F. Geerts, W. Gelade, F. Neven, and A. Poggi. Complexity and composition of synthesized Web services. In PODS, 2008 [PDF]
Pierce11 Martin Hofmann, Benjamin C. Pierce, and Daniel Wagner. Symmetric Lenses. In ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), Austin, Texas, January 2011 PDF