Protocol Stub Deployment
The main data flows to support the deployment of protocol stubs required to connect the Hyperty Runtime to a specific back-end server, is presented in the figure below and described in this section.
Steps 1: Several components might initiate de Protocol Stub deploy that can come from the Core Runtime Sandbox (e.g. Runtime Registry) or from other sandbox (e.g. Application). The Protocol Stub deployment may be triggered by the deployment of an Hyperty or by some attempt from a local Hyperty to communicate with a remote Hyperty running in the domain served by the Protocol Stub. In this former case the Runtime Registry would take the initiative to start the Protocol Stub deploy. For the deployment of P2P Requester Stubs, the “p2pconfig” parameter contains the remote P2P Handler Stub instance URL and the “local MN StubURL” connecting to the MN from the remote runtime that will be used for the P2P setup signalling. For the deployment of P2P Handler Stubs, the “p2pconfig” parameter contains “isHandlerStub = true”.
Steps 6 - 7: The Runtime UA only downloads and deploys requested Protocol Stub after checking in the Registry that there is no Protocol Stub available in the Hyperty Runtime. It checks the p2pConfig to look for the type of protostubb to be loaded and check with the runtime registry that it is not yet deployed in the Runtime.
Steps 8 - 9: the Runtime UA is able to derive the URL to download the Protocol Stub descriptor from the domain URL (sp-domain), since it is a well known URI defined in the reTHINK Architecture Interfaces [15].
Steps 10-11: The Runtime UA downloads the protostub source code, extracting the protostubDownloadURL from the protostub descriptor.
Steps 12-16: The Runtime UA requests the Registry about existing sandbox do be used. If no appropriate sandbox is available, it instantiates a new sandbox through the Sandbox interface which is registered in the Registry. The capabilities input parameter (see RuntimeSandboxCapabilities type in Runtime Descriptor) is used to indicate capabilities required eg window capabilities.
Steps 17 - 25: the new Protocol Stub is registered in the Runtime Registry, which allocates and returns the runtime address (RuntimeURL) for the new runtime component. Since the protostub only has to be reached by runtime components, the protostub URL can be generated by the Runtime Registry ensuring the URL is unique in the Runtime namespace. Optionaly, the protostub is registered in the remote Domain Registry. In addition, the runtime Registry requests the runtime BUS to add its listener to receive events about the Protocol Stub status. For P2P Requester Stubs its Routing Path is set at Message Node Subscription Manager functionality.
Steps 26-28: The Runtime UA requests the new sandbox to instantiate the protostub source code, extracting the configuration data from the protostub descriptor. For P2P Requester Stubs, the p2pConfig json data is concatonated with the protostub descriptor configuration json data.
Steps 29: The Runtime UA finishes the Protocol Stub deploy by adding in the runtime BUS the protostub listener to receive messages from the runtime.
Protocol stubs are connected by using credentials handled by the Core Runtime Identity Module which are detailed in the Domain Login.
Steps 30 - 33: Protocol Stub publishes its status (including events about when it is connected or disconnected) in its resource status. Components registered on the Protocol Stub status resources, like the Registry, are notified about the new protocol status. As soon a “live” status is received, the load is finished.
Message to publish Protocol Stub Status
"id" : "1"
"type" : "UPDATE",
"from" : "hyperty-runtime://sp1/protostub/123",
"to" : "hyperty-runtime://sp1/protostub/123/status",
"body" : { "value" : "live", "resource": "<remoteRuntimeURL>" }
note: