Robotics Service Bus

h1. URI Schema

Final:

<pre>

Generisch:

rsb:///hierarchical/service/definition/further/to/participant

</pre>

Könnte ergeben:

* Service

* Participant

** Einduetig einer [ok]

** Mehrere auf dem gleichen Scope

   @rsb:///hierarchical/service/definition/further/to/participant#UniqueIDOfParticipant [UUID]@

* Nichts

<pre>

Spezifisch:

transport://<location.transport.specific[:PORT]>/hierarchical/service/definition/further/to/participant

</pre>

Location muss eindeutig auf einen einzigen Participant zeigen (keine Fragment-ID mehr)

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

Next proposal:

<pre>

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

</pre>

* 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

h2. 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)

<pre>

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

</pre>

REST Style Services

<pre>

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 

</pre>

* 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?)

<pre>

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

</pre>

h2. Targets

* Service vs. Interface

* Composite

* Port

h2. 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?

h2. 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

h2. Open Issues

* Action encoding

h2. Further Proposals we discussed

h3. Seb

<pre>

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

rsb://composite1/highLevelInterface/portABC  // subscription URI

</pre>

h3. Ingo

<pre>

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

</pre>

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