search

reTHINK-project / core-framework

The main goal of WP3 is to provide the reTHINK core framework comprised by the runtime environment where Hyperties are executed and the messaging nodes used to support messages exchange between Hyperties.
Apache License 2.0
1 stars 0 forks source link

Clarifications and changes required for Deploying Protostub #116

Closed emmelmann-fokus closed 8 years ago

emmelmann-fokus commented 8 years ago

Notes on https://github.com/reTHINK-project/core-framework/blob/master/docs/specs/runtime/dynamic-view/basics/deploy-protostub.md

Please address the following open issues and make changes:

  1. Need to rename back-end service to catalogue to make relation between components clear
  2. Who is initiating message 1 (loadstub)? It it coming from the same or from different sandbox? --> several components might initiate message; can come from same or from other sandbox
  3. For message 3, the "sp-domain" is coming from message 1 --> rename domain in message 1 and 2 to sp-domain
  4. Message 3 incomplete. path in url not correct. likely need to include /default. Align with agreed fromat per Aveiro meeting.
  5. Missing message 3a (response + what is in there = the protocol stub descriptor of the default protocol stub)
  6. missing message 4a (response + what is included)
  7. message 5 does not specify the sandbox to use for instantiating the proto sub. -- Question here is how to have the implementation of the UA agnostic of the sandbox -- also, the downloading of the protocol sub and the instantiation has to be done wihtin the sandbox the protostub later on runs in
  8. messages 4 and 5 will have to be initiated within the Sanbox at Alice Device
  9. Sandbox at Alice Device will likely have to have a dedicated management component that is automatically initiated upon cration of the sandbox
aoncorici commented 8 years ago

One proposition of message exchange:

X is the entity requesting the protostub (Application, Hiperty, MessageBus)

X -------loadStub(domain, protostubTag, protoStubVersion-->Runtime UA

Runtime UA gets protostub descriptor and then source code from the catalogue and retrieves it asynchronously to X.

X<-----------protostubCode-------Runtime UA

X uses the retrieved code and the Service Provider Sandbox Manager to isntante the protoStub. X---instantiateProtoStub(code)------> Service Provider Sandbox Manager

Then X can register the protostub, or Sandbox manager does it.

Can you please update the diagram from deployProtoStub

aoncorici commented 8 years ago

I think we can use diagram flows like above to make sketches of messages during call conferences so that we have the same understanding in the end. What do you think?

pchainho commented 8 years ago

I've updated the diagram and the textual description according to feedback I've received. pls have a look.

Regarding, your proposal @aoncorici, we don't see advantages of having the source code passed as an input parameter and we would prefer to have it downloaded from the sandbox also for security reasons. The plantuml language is very similar to what you just provided above.

pchainho commented 8 years ago

According to today Telco it was decided to pass the source code as input parameter and have the download performed by the runtime ua. This way the runtime ua is the only component downloading the deployable components in the runtime, handle any security issues (authentication, validation,..) and decide which protocol to use (HTTPS , CoAP).

A Runtime Catalogue API will be provided soon by Fokus to let download the protostub (eg getProtoStubDescriptor(...), getProtostubSourceCode( ..) ) and the hyperty source code (getHypertyDescriptor(...), getHypertySourceCode( ..) ).