...

Personally, I (Lorenz) think this is not necessary but if possible we should keep the design flexible enough to allow for a future extension.

Design v1

Brainstorming

Storage

• Persistence of Termini and persistence of deliveryState/unsettled state should be separated. Persistence of unsettled state is out of scope for this document.
• A unsettledStore should support different levels of capability in alignment with the TerminusDurability.
  For example a Memory VH should not advertise any TerminusDurability, a JSON VirtualHost might be able to persist the configuration but not the settled state, while a BDB VH might support all three terminus durability modes.
  For now we do not provide TerminusDurability=2 
• This is another example of where we should differentiate between ConfigurableObjects and PersistentObjects which seems to be orthogonal concepts. LinkRegistry should be Persistent but not Configurable.
• Therefore, to not further make bad things worse, separate LinkRegistryStore out into distinct store? Same type as ConfigStore?
• Store needs to preplicated in HA case. Therefore, each VH needs its own store.
  

  • JSON:

• As is currently the case each VirtualHost should have its own registry.
• Both Sessions and Links are abstract immaterial concepts. The concrete objects are the SessionEndpoints and the LinkEndpoints.
  For Sessions we already only have one object (called Session_1_0 to be aligned to the legacy protocols but this really is the SessionEndpoint).
  We should do the same for Link/-Endpoints and  get rid of one of them. Currently the responsibilities are very unclear and there seems to be no value.
• The implementation of the registry should be hidden behind an API so for example we do not care whether sending links and receiving links are maintained in the same data structure or in separate data structures.
• We should ensure we discard the LinkEndpoint upon Detach(close=true), Detach(error), or Session#End(). Also it needs to be dissociated from the Terminus.
• Given the remote container id and the link name a lookup should return a Terminus. If the terminus is currently associated with a LinkEndpoint it should be reachable from the Terminus; if not we should be able to recreate a LinkEndpoint (and thus a Link) dynamically from the Terminus.
• Persistence of Termini and persistence of deliveryState/unsettled state should be separated. Persistence of unsettled state is out of scope for this.
• A unsettledStore should support different levels of capability in alignment with the TerminusDurability.
  For example a Memory VH should not advertise any TerminusDurability, a JSON VirtualHost might be able to persist the configuration but not the settled state, while a BDB VH might support all three terminus durability modes.
  For now we do not provide TerminusDurability=2 
• This is another example of where we should differentiate between ConfigurableObjects and PersistentObjects which seems to be orthogonal concepts. LinkRegistry should be Persistent but not Configurable.
• Therefore, to not further make bad things worse separate out into distinct store? Same type as ConfigStore?
  

  • JSON:

    Code Block
    language text
    { "version" : "1.0", "links" : {   localContainerId1 : { : "1.0", "sendingsendingLinks" : { remoteContainerId1 : { linkName1 : { "source" : { /* source attributes */ } }, linkName2 : { "source" : { /* source attributes */ } }, ... }, remoteContainerId2 : { linkName1 : { "source" : { /* source attributes */ } }, ... }, ... } "receivingreceivingLinks" : { { remoteContainerId1 : { linkName1 : { "target" : { /* target attributes */ } }, ... }, ... }... }, localContainerId2... : { "sending" : { ... }, "receiving" : { ... } }, ... } }

  • BDB (needs to be versioned):
    • key: (sourceContainerId, targetContainerId, linkName) 
    • value: (SourceDef, TargetDef)
      where one of the two MAY be null
  JDBC (needs to be versioned)COLUMNS: (sourceContainerId, targetContainerId, linkName, SourceDef, TargetDef)
  where either SourceDef xor TargetDef MAY be null

  • } }

  • BDB (needs to be versioned):
    • key: (sourceContainerId, targetContainerId, linkName) 
    • value: (SourceDef, TargetDef)
      where one of the two MAY be null
  • JDBC (needs to be versioned)
    • COLUMNS: (sourceContainerId, targetContainerId, linkName, SourceDef, TargetDef)
      where either SourceDef xor TargetDef MAY be null

Design v1 (obsolete)

Brainstorming

• As is currently the case each VirtualHost should have its own registry.
• Both Sessions and Links are abstract immaterial concepts. The concrete objects are the SessionEndpoints and the LinkEndpoints.
  For Sessions we already only have one object (called Session_1_0 to be aligned to the legacy protocols but this really is the SessionEndpoint).
  We should do the same for Link/-Endpoints and  get rid of one of them. Currently the responsibilities are very unclear and there seems to be no value.
• The implementation of the registry should be hidden behind an API so for example we do not care whether sending links and receiving links are maintained in the same data structure or in separate data structures.
• We should ensure we discard the LinkEndpoint upon Detach(close=true), Detach(error), or Session#End(). Also it needs to be dissociated from the Terminus.
• Given the remote container id and the link name a lookup should return a Terminus. If the terminus is currently associated with a LinkEndpoint it should be reachable from the Terminus; if not we should be able to recreate a LinkEndpoint (and thus a Link) dynamically from the Terminus.

Stpes

1. Merge (Sending-/Receiving-)LinkEndpoint and (Sending-/Receiving-)Link; Remove LinkAttachment
2. Create Terminus Interface with methods to associate/dissociate a LinkEndpoint and maintain delivery states
3. Make Source and Target Derive from Terminus and move the (non-durable) delivery state bookkeeping from the LinkEndpoint to the Terminus
4. Create class for the LinkRegistry.
   1. encapsulate remoteContainer in the registry
   2. values are Termini
5. replace current Map<containerId, LinkRegistry> on VH with new LinkRegistry

...

• Link stealing hard
• association between Source, Target, and  LinkEndpoint not explicit (no Link object). makes attaching logic complecated (see above) and hard to get right (threading, atomicity)

Design v2 (obsolete)

Instead of a LinkRegistry we introduce a LinkManager with expanded responsibilities.

...