URI Schema » History » Version 40
J. Wienke, 04/13/2011 11:33 AM
1 | 1 | J. Wienke | h1. URI Schema |
---|---|---|---|
2 | 1 | J. Wienke | |
3 | 36 | J. Wienke | Final: |
4 | 37 | J. Wienke | <pre> |
5 | 36 | J. Wienke | Generisch: |
6 | 36 | J. Wienke | rsb:///hierarchical/service/definition/further/to/participant |
7 | 37 | J. Wienke | </pre> |
8 | 36 | J. Wienke | Könnte ergeben: |
9 | 36 | J. Wienke | * Service |
10 | 1 | J. Wienke | * Participant |
11 | 37 | J. Wienke | ** Einduetig einer [ok] |
12 | 36 | J. Wienke | ** Mehrere auf dem gleichen Scope |
13 | 38 | J. Wienke | @rsb:///hierarchical/service/definition/further/to/participant#UniqueIDOfParticipant [UUID]@ |
14 | 36 | J. Wienke | * Nichts |
15 | 36 | J. Wienke | |
16 | 39 | J. Wienke | <pre> |
17 | 39 | J. Wienke | Spezifisch: |
18 | 40 | J. Wienke | transport://<location-trnasport-specific>/hierarchical/service/definition/further/to/participant |
19 | 39 | J. Wienke | </pre> |
20 | 39 | J. Wienke | |
21 | 31 | S. Wrede | h2. Storming, Norming, Forming. Let's continue... |
22 | 31 | S. Wrede | |
23 | 31 | S. Wrede | Next proposal: |
24 | 31 | S. Wrede | |
25 | 31 | S. Wrede | <pre> |
26 | 31 | S. Wrede | Code-Level |
27 | 31 | S. Wrede | ServiceComponent --> ServiceProvider | ServiceConsumer --> Bindings --> Port |
28 | 31 | S. Wrede | |
29 | 35 | S. Wrede | Participant -?-> ServiceComponent (Wichtig: Differenz zu Domain-Modell: ServiceComponent ist Container für mehrere Informer / Listener und damit unabhängige Instanz und nicht nur Oberklasse) |
30 | 33 | S. Wrede | Informer --> ServiceProvider |
31 | 33 | S. Wrede | Listener --> ServiceConsumer |
32 | 33 | S. Wrede | |
33 | 31 | S. Wrede | Modell-Level |
34 | 31 | S. Wrede | Service (1:n ServiceComponents) --> Interface (1:n ServiceProvider | ServiceConsumer) : Port (1:n Ports) |
35 | 31 | S. Wrede | |
36 | 34 | S. Wrede | Alternative Sichtweise: |
37 | 34 | S. Wrede | Service (1:n Participants) --> Interface (1:n Informer | Listener) : Port (1:n Ports) |
38 | 34 | S. Wrede | |
39 | 31 | S. Wrede | URL-Level |
40 | 31 | S. Wrede | generisch: |
41 | 31 | S. Wrede | rsb://dns/service-path/element-path/ (plus User-definable actions) |
42 | 31 | S. Wrede | spezifisch: |
43 | 31 | S. Wrede | spread://dns/service-path/element-path/ (plus User-definable actions) |
44 | 31 | S. Wrede | |
45 | 31 | S. Wrede | cf. |
46 | 31 | S. Wrede | http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html |
47 | 31 | S. Wrede | |
48 | 31 | S. Wrede | Client: |
49 | 31 | S. Wrede | ServiceComponent (ImageImport, Base-URL: facedetection) |
50 | 31 | S. Wrede | ServiceConsumer (SUB-ActionBinding, Context-URL: /images) |
51 | 31 | S. Wrede | |
52 | 31 | S. Wrede | Server-URLs: |
53 | 31 | S. Wrede | ServiceComponent (hal, Base-URL: hal) |
54 | 31 | S. Wrede | ServiceProvider (PUB, GET-ActionBinding, Context-URL: /cam/left/img)) |
55 | 31 | S. Wrede | ServiceProvider (PUB, GET-ActionBinding, Context-URL: /cam/right/img)) |
56 | 31 | S. Wrede | |
57 | 31 | S. Wrede | Modell-Level |
58 | 31 | S. Wrede | Facedetection: Service (cam-interface, gemappt auf base-url, und entsprechenden actions, ports) |
59 | 31 | S. Wrede | HAL: Service (diverse interfaces, eines davon: cam, gemappt auf base |
60 | 31 | S. Wrede | |
61 | 31 | S. Wrede | </pre> |
62 | 31 | S. Wrede | |
63 | 31 | S. Wrede | * Actions sind Event Metadaten auf die man mit Framework-Support filtern kann |
64 | 31 | S. Wrede | * Service erlaubt lokales Anhängen von Action Listenern und Publishern unter einem URL Namensraum |
65 | 32 | S. Wrede | * Beispiel: ISR param (get+set) |
66 | 31 | S. Wrede | * Pfad-Teil der URI ist erstmal völlig frei |
67 | 31 | S. Wrede | * Composites, Services und Element-URIs ergeben sich aus Modellierung, Anordnung von ServiceElementen |
68 | 31 | S. Wrede | * Domain-Teil ist Deployment |
69 | 31 | S. Wrede | * Zugriff über spezifisches Protokoll damit direkt möglich, z.B. Http |
70 | 31 | S. Wrede | * RSB prefix mit Modell erlaubt logischen Zugriff mit location transparency |
71 | 1 | J. Wienke | |
72 | 10 | S. Wrede | h2. Just Brainstorming |
73 | 10 | S. Wrede | |
74 | 17 | S. Wrede | * Ziel: Kein deployment und kein Transport in der URL! |
75 | 1 | J. Wienke | * Ziel: Location-Transparency auf logischer Ebene |
76 | 17 | S. Wrede | * Ziel: Einfachheit |
77 | 1 | J. Wienke | * Modell enthält das Deployment |
78 | 19 | S. Wrede | * Ziel: Redeployment darf keine Code-Änderungen nach sich ziehen |
79 | 19 | S. Wrede | * Ziel: URLs werden über das Modell umkonfiguriert |
80 | 19 | S. Wrede | * Ziel: Subscriptions werden auch über Modell konfiguriert für statischen Deployment-Kontext (Datentypen, Scopes) |
81 | 20 | S. Wrede | * User konfiguriert ID Modell-invariant im Code |
82 | 20 | S. Wrede | * Ports sind atomare Einheiten der Kommunikation (wie in RSB) |
83 | 26 | J. Wienke | * Composite = Scope? Insgesamt aber gewünscht |
84 | 27 | S. Wrede | * -Binding ist Instantiierung eines Patterns, sollte in der URL repräsentiert sein, besserer Name?- |
85 | 27 | S. Wrede | * Binding ist Instantiierung einer REST Aktion (und impliziert die Verwendung bestimmter Port-Kombinationen) |
86 | 1 | J. Wienke | * Interface ist ein logisches Modellelement und nicht Teil der URL (kann für Verifikation von Serviceinterfaces benutzt werden) |
87 | 1 | J. Wienke | * Service ist Abbildung von Bindings / Rest Actions auf eine URL. Beispiel, siehe (1) |
88 | 1 | J. Wienke | |
89 | 1 | J. Wienke | <pre> |
90 | 30 | S. Wrede | rsb://scopeA.scopeB/service/element-path?filter=cond¶m=n |
91 | 30 | S. Wrede | |
92 | 30 | S. Wrede | rsb://hal.cam.left/status/.../.../123?xpath=foo&timing=12 hal.cam.left eq. scopes, status eq. service |
93 | 30 | S. Wrede | |
94 | 22 | S. Wrede | rsb://isr/hyp --> hyp binding type: publish, port types: spread, local |
95 | 22 | S. Wrede | rsb://isr/conf --> conf binding type: rpc server, port types: |
96 | 22 | S. Wrede | |
97 | 22 | S. Wrede | Remote Anfrage: --> rsb://isr/conf/req/out --> Alle Nachrichten, die über verschiedene Transports des gleichen logischen Ports kommuniziert werden |
98 | 29 | S. Wrede | |
99 | 29 | S. Wrede | --> rsb+spread://isr/conf/req/out --> Nachrichten, die über spread Transport des gleichen logischen Ports geschickt werden |
100 | 29 | S. Wrede | </pre> |
101 | 1 | J. Wienke | |
102 | 27 | S. Wrede | REST Style Services |
103 | 27 | S. Wrede | <pre> |
104 | 27 | S. Wrede | Kamera-Server: zwei Kameras |
105 | 27 | S. Wrede | |
106 | 27 | S. Wrede | (1) rsb://hal.cam/left/images --> Kamerabild (GET, SUB) |
107 | 28 | S. Wrede | (1a) Introspection URIs: rsb://hal.cam/left/images/?out |
108 | 27 | S. Wrede | (2) rsb://hal.cam/left/params --> Parameters (PUT, GET, POST, SUB) |
109 | 27 | S. Wrede | (3) rsb://hal.cam/right/images |
110 | 27 | S. Wrede | (4) rsb://hal.cam/right/params |
111 | 27 | S. Wrede | |
112 | 27 | S. Wrede | GET PUT POST DELETE |
113 | 27 | S. Wrede | |
114 | 27 | S. Wrede | Sender | Empfänger |
115 | 27 | S. Wrede | |
116 | 27 | S. Wrede | GET (1) --> gibt mir das Kamerabild zurück: In- / Out-Port | In- / Out-Port |
117 | 27 | S. Wrede | POST (2) --> setzt neue Parameter: Out-Port | In-Port |
118 | 27 | S. Wrede | SUB (3) --> lesen von state changes: In-Port |
119 | 27 | S. Wrede | |
120 | 27 | S. Wrede | |
121 | 27 | S. Wrede | |
122 | 27 | S. Wrede | ServiceProvider vs. ServiceUser? |
123 | 27 | S. Wrede | |
124 | 27 | S. Wrede | Aktualisieren von Information |
125 | 27 | S. Wrede | |
126 | 27 | S. Wrede | |
127 | 27 | S. Wrede | rsb:// |
128 | 27 | S. Wrede | Query |
129 | 27 | S. Wrede | Subscription |
130 | 27 | S. Wrede | Publisher |
131 | 27 | S. Wrede | </pre> |
132 | 22 | S. Wrede | |
133 | 21 | S. Wrede | * Logisch vs. Physisch |
134 | 22 | S. Wrede | |
135 | 22 | S. Wrede | Jens: |
136 | 21 | S. Wrede | ** Component hat abstrakt andere Eigenschaften als eine Composite, z.B. Port Referenzen |
137 | 21 | S. Wrede | ** Gehört nicht zum Deployment |
138 | 22 | S. Wrede | ** Service ist nicht existent |
139 | 22 | S. Wrede | ** Interface: bindings auf Ports oder Port Referenzen |
140 | 21 | S. Wrede | |
141 | 24 | S. Wrede | Was ist mit? |
142 | 26 | J. Wienke | * Service = XSRAD.Component (enthält Port-Refs) |
143 | 26 | J. Wienke | * Component = Deployment-Unit oder Konzept? |
144 | 26 | J. Wienke | * Interface = XSRAD.Interface (In URL enthalten?) |
145 | 16 | S. Wrede | |
146 | 10 | S. Wrede | <pre> |
147 | 10 | S. Wrede | scheme://domain:port/path?query_string#fragment_id |
148 | 10 | S. Wrede | |
149 | 11 | S. Wrede | rsb://composite1.composite2:<PortId>/service/interface/port?param_n=n#filter:cond |
150 | 11 | S. Wrede | |
151 | 16 | S. Wrede | rsb://composite1.composite2.componentA.interface.port/service/interface/port |
152 | 10 | S. Wrede | |
153 | 10 | S. Wrede | More complex example (Q: How to deal with input and output ports?) |
154 | 10 | S. Wrede | |
155 | 12 | S. Wrede | rsb://composite1.composite2:<PortId>/interface/port?param_n=n#filter:cond |
156 | 12 | S. Wrede | |
157 | 10 | S. Wrede | Informer: rsb://biron.hal.camera/image/left/o/left/?param1=12 |
158 | 13 | S. Wrede | |
159 | 13 | S. Wrede | Listener A: rsb+spread://biron.hal.camera/image/left/i |
160 | 13 | S. Wrede | Listener B: rsb+shamem://biron.hal.camera/image/left/i |
161 | 13 | S. Wrede | |
162 | 10 | S. Wrede | Subscription-URI: rsb://biron.hal.vision/grab/out/left/#xpath:/frame |
163 | 10 | S. Wrede | </pre> |
164 | 10 | S. Wrede | |
165 | 10 | S. Wrede | h2. Targets |
166 | 10 | S. Wrede | |
167 | 10 | S. Wrede | * Service vs. Interface |
168 | 10 | S. Wrede | * Composite |
169 | 10 | S. Wrede | * Port |
170 | 10 | S. Wrede | |
171 | 1 | J. Wienke | h2. Use Cases |
172 | 1 | J. Wienke | |
173 | 1 | J. Wienke | * Introspection URIs? HTTP possible? |
174 | 1 | J. Wienke | * Subscription on each node of the tree (aggregation vs. filtering) |
175 | 1 | J. Wienke | * Model vs. System URI? Should not exist? |
176 | 1 | J. Wienke | * Every active object must be identifiable |
177 | 1 | J. Wienke | * Data part of URI? Probably not? |
178 | 2 | J. Wienke | * RESTful API? |
179 | 5 | J. Wienke | |
180 | 5 | J. Wienke | h2. Identified Problems |
181 | 5 | J. Wienke | |
182 | 6 | J. Wienke | * Data space (motion/wheel/left) is orthogonal to current model structure |
183 | 1 | J. Wienke | ** Using this concept could generate unmodelled ports in reverse engineering |
184 | 7 | J. Wienke | ** Is this required if we model our system? |
185 | 7 | J. Wienke | ** Wildcards in URLs? |
186 | 8 | J. Wienke | ** Idea: Second model tree for AggregationInterfaces that combine Ports from different Components / Composites etc. and automatically derive their base data type |
187 | 1 | J. Wienke | *** Different Protocol part in the URI for these interfaces to subscribe on |
188 | 1 | J. Wienke | *** 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 |
189 | 1 | J. Wienke | |
190 | 1 | J. Wienke | h2. Open Issues |
191 | 1 | J. Wienke | |
192 | 1 | J. Wienke | * Action encoding |
193 | 1 | J. Wienke | |
194 | 1 | J. Wienke | h2. Further Proposals we discussed |
195 | 9 | J. Wienke | |
196 | 30 | S. Wrede | h3. Seb |
197 | 30 | S. Wrede | |
198 | 30 | S. Wrede | <pre> |
199 | 30 | S. Wrede | rsb://composite1.composite2.composite3.componentNameXY/interfaceFooBar/portABC // EXPORT, creation of domain objects |
200 | 30 | S. Wrede | rsb://composite1/highLevelInterface/portABC // subscription URI |
201 | 30 | S. Wrede | </pre> |
202 | 30 | S. Wrede | |
203 | 30 | S. Wrede | h3. Ingo |
204 | 14 | S. Wrede | <pre> |
205 | 14 | S. Wrede | rsb://machine.domain.tld:<PortInstanceId>/composite1/composite2/interface/port?param_n=n#filter:cond |
206 | 14 | S. Wrede | </pre> |
207 | 14 | S. Wrede | _We decided against this as it breaks our aim of location transparency._ |