URI Schema » History » Version 44

J. Wienke, 05/12/2011 02:47 PM

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