Legacy Interworking Overview
reTHINK framework provides a mechanism to interact with legacy services by using InterWorking protostub - the “IWStub”.
From the Identity Management perspective, probably the Hyperty will need to be associated to two identities. The Identity Module will handle the authentication against the Identity Provider of the Legacy domain. After a successful authentication normally a token will be provided. This token has to be used from the Protostub to authenticate itself during the registration/login process to the legacy domain. Depending on the Legacy Domain this process may be different, however it should be compatible with the most scenarios.
Once the Identity Module has finished the authentication process, the Hyperty is ready to instruct the Protostub to register into the legacy domain and start the exchange of messages in order to give service to the application using the Hyperty.
The Hyperty will be able to interact with the legacy domain sending messages to the Protostub as it is done for a regular Message Node. The same way the Hyperty will be able to receive messages from it. The messages received by the Protostub from the legacy domain will also be translated into reTHINK messages (which are described here).
The main data flows to support the deployment of protocol stubs required to connect the Hyperty Runtime to a Legacy domain, is presented in the figure below and described in this section.
Steps 1-3: The Interworking Protocol Stub (the term IWstub will used in this document) deployment can be intiated by the Core Runtime Sandbox (e.g. Runtime Registry) or from other sandbox (e.g. Application). The Interworking Protocol Stub deployment will be triggered by the deployment of an Hyperty which will interact with a Legacy Domain service or by some attempt from a local Hyperty to communicate with a legacy domain which requires that interworking Protocol Stub. The Runtime UA only downloads and deploys requested IWstub after checking in the Registry that there is no Protocol Stub available in the Hyperty Runtime. The “p2pconfig” parameter is not used in Interworking Protostub.
Steps 4 - 5: the Runtime UA is able to derive the URL to download the Protocol Stub descriptor from the domain URL (legacy-domain), since it is a well known URI defined in the reTHINK Architecture Interfaces [15]. The Legacy Domain must add a Catalogue and a Service backend to download the IWstub code. This role may not be played by the Legacy Domain itself by a Third organization which provide interoperability between reTHINK and the legacy service. In this case, the descriptor of the protostub will include the attribute set to true.
Steps 6-7: The Runtime UA extracts protostubDownloadURL from the protostub descriptor and downloads the protostub source code from a back end server from where the Legacy Domain serves the IWstub code.
Steps 8 - 11: 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.
Steps 12-15: The Runtime UA 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. This parameter can be useful to support future interconnection with different Legacy Domains.
Steps 16-18: The Runtime UA requests the new Legacy Domain sandbox to instantiate the protostub source code, extracting the configuration data from the protostub descriptor.
Steps 19-20: These steps are exclusive of the IWstub and may be different depending on the Legacy Domain the IWstub interacts with. In the diagram an interconnection with a SIP network is proposed, but other pro. Please note that if the runtime is being executed in a browser there is a limitation in the types of protocols we can use to interact with the Legacy Domain since it is limited to use either Protocols over HTTP or Protocols over Websocket (e.g. SIPoWS or XMPPoWS).
Steps 21-22: The Runtime UA finishes the deployment by adding a listener is added to the Msg BUS in order to be able to send messages to the IWstub from the Core Runtime. The RuntimeUA notifies the Application that the IWstub has been correctly deployed.
Protocol stubs are connected by using credentials handled by the Core Runtime Identity Module which are detailed in the Domain Login.
Steps 23 - 24: 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.
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" }