URI Schema¶

Storming, Norming, Forming. Let's continue...¶

Next proposal:

Code-Level
ServiceComponent --> ServiceProvider | ServiceConsumer --> Bindings --> Port

Participant -?-> ServiceComponent (Wichtig: Differenz zu Domain-Modell: ServiceComponent ist Container für mehrere Informer / Listener und damit unabhängige Instanz und nicht nur Oberklasse)
Informer    --> ServiceProvider
Listener    --> ServiceConsumer

Modell-Level
Service (1:n ServiceComponents) --> Interface (1:n ServiceProvider | ServiceConsumer)  : Port (1:n Ports)

Alternative Sichtweise:
Service (1:n Participants) --> Interface (1:n Informer | Listener)  : Port (1:n Ports)

URL-Level
generisch:
rsb://dns/service-path/element-path/ (plus User-definable actions)
spezifisch:
spread://dns/service-path/element-path/ (plus User-definable actions)

cf.
http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html

Client:
ServiceComponent (ImageImport, Base-URL: facedetection)
ServiceConsumer (SUB-ActionBinding, Context-URL: /images)

Server-URLs:
ServiceComponent (hal, Base-URL: hal)
ServiceProvider (PUB, GET-ActionBinding, Context-URL: /cam/left/img))
ServiceProvider (PUB, GET-ActionBinding, Context-URL: /cam/right/img))

Modell-Level
Facedetection: Service (cam-interface, gemappt auf base-url, und entsprechenden actions, ports)
HAL: Service (diverse interfaces, eines davon: cam, gemappt auf base

• Actions sind Event Metadaten auf die man mit Framework-Support filtern kann
• Service erlaubt lokales Anhängen von Action Listenern und Publishern unter einem URL Namensraum
• Beispiel: ISR param (get+set)
• Pfad-Teil der URI ist erstmal völlig frei
• Composites, Services und Element-URIs ergeben sich aus Modellierung, Anordnung von ServiceElementen
• Domain-Teil ist Deployment
• Zugriff über spezifisches Protokoll damit direkt möglich, z.B. Http
• RSB prefix mit Modell erlaubt logischen Zugriff mit location transparency

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)
• Interface ist ein logisches Modellelement und nicht Teil der URL (kann für Verifikation von Serviceinterfaces benutzt werden)
• Service ist Abbildung von Bindings / Rest Actions auf eine URL. Beispiel, siehe (1)

rsb://scopeA.scopeB/service/element-path?filter=cond&param=n

rsb://hal.cam.left/status/.../.../123?xpath=foo&timing=12 hal.cam.left eq. scopes, status eq. service

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)
(1a) Introspection URIs: rsb://hal.cam/left/images/?out
(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

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 = 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¶

Seb¶

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

Ingo

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.