URI Schema » History » Version 27
« Previous -
Version 27/59
(diff) -
Next » -
Current version
S. Wrede, 03/03/2011 06:40 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? Insgesamt aber gewünscht
Binding ist Instantiierung eines Patterns, sollte in der URL repräsentiert sein, besserer Name?- Binding ist Instantiierung einer REST Aktion (und impliziert die Verwendung bestimmter Port-Kombinationen)
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
REST Style Services
Kamera-Server: zwei Kameras (1) rsb://hal.cam/left/images --> Kamerabild (GET, SUB) (2) rsb://hal.cam/left/params --> Parameters (PUT, GET, POST, SUB) (3) rsb://hal.cam/right/images (4) rsb://hal.cam/right/params GET PUT POST DELETE Sender | Empfänger GET (1) --> gibt mir das Kamerabild zurück: In- / Out-Port | In- / Out-Port POST (2) --> setzt neue Parameter: Out-Port | In-Port SUB (3) --> lesen von state changes: In-Port ServiceProvider vs. ServiceUser? Aktualisieren von Information rsb:// Query Subscription Publisher
- Logisch vs. Physisch
- 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
- Service = XSRAD.Component (enthält Port-Refs)
- Component = Deployment-Unit oder Konzept?
- Interface = XSRAD.Interface (In URL enthalten?)
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.