URI Schema¶

Use Cases¶

URIs or URLs are used in the following situations

• Specifying how to connect to the bus (i.e. specifying a scope and transport configuration)
• Naming a thing on the bus
  • A channel
  • Multiple participants
  • A single participant
    • A service

Generic URIs¶

Syntax and Semantic¶

rsb:[PATH][#FRAGMENT]

Components of the URL are interpreted as follows:

• SCHEME -> has to be "rsb"
• PATH -> A scope which designates a one of the following things
  • A channel
  • A participant
    • A service (which is-a participant)
• FRAGMENT ->
  • Not allowed when designating a channel
  • ID of a participant otherwise

This may resolve to:

• Service and/or Participant
  • If there is only one of these entities this is enough for resolving it
  • If multiple entities reside on this scope, a single instance can be selected using their UUID.
    rsb:/hierarchical/service/definition/further/to/participant#UniqueIDOfParticipant [UUID]
• Nothing

These generic URIs require a global naming service.

Examples:

rsb:                                              -> The channel designated by the scope "/" 
rsb:/                                             -> The channel designated by the scope "/" 
rsb:/foo/bar                                      -> The channel designated by the scope "/foo/bar" 
rsb:/foo/bar#10838319-09A4-4D15-BD59-5E054CDB4403 -> The participant with UUID 10838319-09A4-4D15-BD59-5E054CDB4403

Rationale¶

Usually location transparency should be available.

Transport-specific URLs¶

Syntax and Semantic¶

[SCHEME:][//HOST][:PORT][PATH][?QUERY][#FRAGMENT]
transport://<location.transport.specific[:PORT]>/hierarchical/service/definition/further/to/participant

Components of the URL are interpreted as follows:

• SCHEME -> transport name (e.g spread)
• HOST -> Transport-specific "host" option (e.g. host that runs the daemon for spread transport)
• PORT -> Transport-specific "port" option (e.g. port on which Spread daemon listens for spread transport)
• PATH -> A scope which designates a one of the following things
  • A channel
  • A participant
    • A service (which is-a participant)
• QUERY -> "freestyle" transport-specific options
• FRAGMENT ->
  • Not allowed when designating a channel
  • ID of a participant otherwise

What does this mean?

Location uniquely identifies a single participant or service, hence an ID part is not required any more.
Specific IDs can be resolved by the respective connectors and do not require a global naming.

Examples for specifying bus connections when creating participants:

                              -> participate in channel with scope "/" using the default transport configuration
spread:                       -> participate in channel with scope "/" using the Spread transport with its default configuration
inprocess:                    -> participate in channel with scope "/" using the in-process transport with its default configuration
spread://localhost:5555       -> participate in channel with scope "/" via the Spread daemon running on localhost and listening on port 5555
inprocess:someotherhost       -> syntactically correct, but does not make sense
spread:/foo/bar               -> participate in channel with scope "/foo/bar" using the default transport configuration
spread:?maxfragmentsize=10000 -> participate in channel with scope "/" using the Spread transport with default host and port and a maximum event fragment size of 10000 bytes

Rationale¶

• Transport-specific access is possible without naming service.
• UUIDs should ideally not be required to keep URIs simple