Nexus API

From wiki.gpii
Revision as of 01:49, 19 April 2015 by Bosmon (talk | contribs) (Created page with "== The Nexus == 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 impl...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The Nexus

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 API will be available in both local and remote forms. The local form simply takes the form of JavaScript function calls made to a JavaScript VM which happens to be locally deployed (e.g. in a browser, a node.js process, or other). The remote form takes the form of JSON payloads sent over plain HTTP and WebSockets protocols to a well-known endpoint. The two forms of the protocol are isomorphic and every message which can be sent in one form has a direct equivalent in the other.

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 Defaults

Description

Read the specification (as JSON) of a component with a particular global name

Local API

Function: gpii.defaults(global.name)

Arguments: global.name: String - the name of the component grade whose defaults are to be read

Return: defaults: Object - the defaults of the required component, as a JavaScript (JSON-equivalent) Object

Remote API

Endpoint: /defaults/global.name

Protocol/Method: HTTP GET


References

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