URI Schema » History » Version 42
Version 41 (J. Wienke, 04/13/2011 11:35 AM) → Version 42/59 (J. Wienke, 05/12/2011 11:23 AM)
h1. URI Schema
h2. URI types
Generic: Final:
<pre>
Generisch:
rsb:///hierarchical/service/definition/further/to/participant
</pre>
This may resolve to: Könnte ergeben:
* Service and/or
* Participant
** If there is only one of these entities this is enough for resolving it Einduetig einer [ok]
** If multiple entities reside on this scope, a single instance can be selected using their UUID. Mehrere auf dem gleichen Scope
@rsb:///hierarchical/service/definition/further/to/participant#UniqueIDOfParticipant [UUID]@
* Nothing ;) Nichts
These generic URIs require a global naming service.
Specific:
<pre>
Spezifisch:
transport://<location.transport.specific[:PORT]>/hierarchical/service/definition/further/to/participant
</pre>
Location uniquely identifies a single participant or service, hence an 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 part is not required any more. 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)
Specific IDs can be resolved by the respective connectors <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 do not require a global naming. 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. Rationale Targets
* generic: usually location transparency should be available Service vs. Interface
* specific: specific access without naming Composite
* UUIDs should ideally 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 keep URIs simple 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._
h2. URI types
Generic: Final:
<pre>
Generisch:
rsb:///hierarchical/service/definition/further/to/participant
</pre>
This may resolve to: Könnte ergeben:
* Service and/or
* Participant
** If there is only one of these entities this is enough for resolving it Einduetig einer [ok]
** If multiple entities reside on this scope, a single instance can be selected using their UUID. Mehrere auf dem gleichen Scope
@rsb:///hierarchical/service/definition/further/to/participant#UniqueIDOfParticipant [UUID]@
* Nothing ;) Nichts
These generic URIs require a global naming service.
Specific:
<pre>
Spezifisch:
transport://<location.transport.specific[:PORT]>/hierarchical/service/definition/further/to/participant
</pre>
Location uniquely identifies a single participant or service, hence an 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 part is not required any more. 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)
Specific IDs can be resolved by the respective connectors <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 do not require a global naming. 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. Rationale Targets
* generic: usually location transparency should be available Service vs. Interface
* specific: specific access without naming Composite
* UUIDs should ideally 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 keep URIs simple 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._