URI Schema » History » Version 24

« Previous - Version 24/59 (diff) - Next » - Current version
S. Wrede, 03/03/2011 03:38 PM


URI Schema

rsb://composite1.composite2.composite3.componentNameXY/interfaceFooBar/portABC // EXPORT, creation of domain objects
rsb://composite1/highLevelInterface/portABC  // subscription URI

Just Brainstorming

  • Ziel: Kein deployment und kein Transport in der URL!
  • Ziel: Location-Transparency auf logischer Ebene
  • Ziel: Einfachheit
  • Modell enthält das Deployment
  • Ziel: Redeployment darf keine Code-Änderungen nach sich ziehen
  • Ziel: URLs werden über das Modell umkonfiguriert
  • Ziel: Subscriptions werden auch über Modell konfiguriert für statischen Deployment-Kontext (Datentypen, Scopes)
  • User konfiguriert ID Modell-invariant im Code
  • Ports sind atomare Einheiten der Kommunikation (wie in RSB)
  • Composite == Scope !
  • Binding ist Instantiierung eines Patterns, sollte in der URL repräsentiert sein
rsb://isr/hyp        --> hyp  binding type: publish, port types: spread, local
rsb://isr/conf       --> conf binding type: rpc server, port types: 

Remote Anfrage:      --> rsb://isr/conf/req/out --> Alle Nachrichten, die über verschiedene Transports des gleichen logischen Ports kommuniziert werden

                     --> rsb+spread://isr/conf/req/out --> Nachrichten, die über spread Transport des gleichen logischen Ports geschickt werden
  • Logisch vs. Physisch
Jens:
  • Component hat abstrakt andere Eigenschaften als eine Composite, z.B. Port Referenzen
  • Gehört nicht zum Deployment
  • Service ist nicht existent
  • Interface: bindings auf Ports oder Port Referenzen
Was ist mit?
  • Service
  • Component
  • Interface
scheme://domain:port/path?query_string#fragment_id

rsb://composite1.composite2:<PortId>/service/interface/port?param_n=n#filter:cond

rsb://composite1.composite2.componentA.interface.port/service/interface/port

More complex example (Q: How to deal with input and output ports?)

rsb://composite1.composite2:<PortId>/interface/port?param_n=n#filter:cond

Informer:   rsb://biron.hal.camera/image/left/o/left/?param1=12

Listener A:   rsb+spread://biron.hal.camera/image/left/i
Listener B:   rsb+shamem://biron.hal.camera/image/left/i

Subscription-URI: rsb://biron.hal.vision/grab/out/left/#xpath:/frame

Targets

  • Service vs. Interface
  • Composite
  • Port

Use Cases

  • Introspection URIs? HTTP possible?
  • Subscription on each node of the tree (aggregation vs. filtering)
  • Model vs. System URI? Should not exist?
  • Every active object must be identifiable
  • Data part of URI? Probably not?
  • RESTful API?

Identified Problems

  • Data space (motion/wheel/left) is orthogonal to current model structure
    • Using this concept could generate unmodelled ports in reverse engineering
    • Is this required if we model our system?
    • Wildcards in URLs?
    • Idea: Second model tree for AggregationInterfaces that combine Ports from different Components / Composites etc. and automatically derive their base data type
      • Different Protocol part in the URI for these interfaces to subscribe on
      • We do not need data hierarchies (only required for function overloading), instead only collections of interfaces are required and an intersection operation to derive the resulting type of an aggregation

Open Issues

  • Action encoding

Further Proposals we discussed

rsb://machine.domain.tld:<PortInstanceId>/composite1/composite2/interface/port?param_n=n#filter:cond

We decided against this as it breaks our aim of location transparency.