URI Schema » History » Version 42

J. Wienke, 05/12/2011 11:23 AM
tried to clean up old mess (still available in history) and condense the rationales discussed there

1 1 J. Wienke
h1. URI Schema
2 1 J. Wienke
3 42 J. Wienke
h2. URI types
4 42 J. Wienke
5 42 J. Wienke
Generic:
6 36 J. Wienke
<pre>
7 37 J. Wienke
rsb:///hierarchical/service/definition/further/to/participant
8 1 J. Wienke
</pre>
9 42 J. Wienke
This may resolve to:
10 42 J. Wienke
* Service and/or Participant
11 42 J. Wienke
** If there is only one of these entities this is enough for resolving it
12 42 J. Wienke
** If multiple entities reside on this scope, a single instance can be selected using their UUID.
13 1 J. Wienke
   @rsb:///hierarchical/service/definition/further/to/participant#UniqueIDOfParticipant [UUID]@
14 42 J. Wienke
* Nothing ;)
15 1 J. Wienke
16 42 J. Wienke
These generic URIs require a global naming service.
17 42 J. Wienke
18 42 J. Wienke
Specific:
19 30 S. Wrede
<pre>
20 30 S. Wrede
transport://<location.transport.specific[:PORT]>/hierarchical/service/definition/further/to/participant
21 30 S. Wrede
</pre>
22 42 J. Wienke
Location uniquely identifies a single participant or service, hence an ID part is not required any more.
23 30 S. Wrede
24 42 J. Wienke
Specific IDs can be resolved by the respective connectors and do not require a global naming.
25 30 S. Wrede
26 42 J. Wienke
h2. Rationale
27 14 S. Wrede
28 42 J. Wienke
* generic: usually location transparency should be available
29 42 J. Wienke
* specific: specific access without naming
30 42 J. Wienke
* UUIDs should ideally not be required to keep URIs simple