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 |