URI Schema » History » Version 43
J. Wienke, 05/12/2011 11:30 AM
Formatting
| 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 | 42 | J. Wienke | * Service and/or Participant |
| 12 | 42 | J. Wienke | ** If there is only one of these entities this is enough for resolving it |
| 13 | 42 | J. Wienke | ** If multiple entities reside on this scope, a single instance can be selected using their UUID. |
| 14 | 1 | J. Wienke | @rsb:///hierarchical/service/definition/further/to/participant#UniqueIDOfParticipant [UUID]@ |
| 15 | 42 | J. Wienke | * Nothing ;) |
| 16 | 1 | J. Wienke | |
| 17 | 1 | J. Wienke | These generic URIs require a global naming service. |
| 18 | 1 | J. Wienke | |
| 19 | 43 | J. Wienke | h3. Specific |
| 20 | 43 | J. Wienke | |
| 21 | 30 | S. Wrede | <pre> |
| 22 | 30 | S. Wrede | transport://<location.transport.specific[:PORT]>/hierarchical/service/definition/further/to/participant |
| 23 | 30 | S. Wrede | </pre> |
| 24 | 42 | J. Wienke | Location uniquely identifies a single participant or service, hence an ID part is not required any more. |
| 25 | 30 | S. Wrede | |
| 26 | 42 | J. Wienke | Specific IDs can be resolved by the respective connectors and do not require a global naming. |
| 27 | 30 | S. Wrede | |
| 28 | 42 | J. Wienke | h2. Rationale |
| 29 | 14 | S. Wrede | |
| 30 | 42 | J. Wienke | * generic: usually location transparency should be available |
| 31 | 42 | J. Wienke | * specific: specific access without naming |
| 32 | 42 | J. Wienke | * UUIDs should ideally not be required to keep URIs simple |