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 |