URI Schema » History » Version 31
« Previous -
Version 31/59
(diff) -
Next » -
Current version
S. Wrede, 03/04/2011 10:32 AM
URI Schema¶
Storming, Norming, Forming. Let's continue...¶
Next proposal:
Code-Level ServiceComponent --> ServiceProvider | ServiceConsumer --> Bindings --> Port Modell-Level Service (1:n ServiceComponents) --> Interface (1:n ServiceProvider | ServiceConsumer) : 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
- 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¶m=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
- 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¶
Seb¶
rsb://composite1.composite2.composite3.componentNameXY/interfaceFooBar/portABC // EXPORT, creation of domain objects rsb://composite1/highLevelInterface/portABC // subscription URI