|
|
||
|
The YAMI4 broker does not use the concept of named queue or topic, which can be found in other broker implementations. It also does not create any logical structures attached to the particular data producer or consumer. Instead, the broker offers message routing that is solely based on the concept of multiple tag matching, which is similar to the concept of tuple spaces.
Any message produced by a publisher needs to have attached a list of tags, which are string values. This list of tags, passed as a comma-separated list of strings, is used to identify what the given message is "about". There is no restriction on the meaning of tags and users are free to use the values that best describe their application domains.
The simplest list of tags contains only one string value, for example:
temperature
A possible meaning of this tag is that it identifies temperature reports from local weather station. Any subscriber that wants to receive temperature reports can just use "temperature" in the list of subscription tags to set up a proper subscription. If the subscriber uses more tags, he will get information that is associated with any of the tags - for example, if the weather station also produces data values with tag:
pressure
then a subscription for "temperature" will receive only temperature values, a subscription for "pressure" will receive only pressure values, but a multi-tag subscription for "temperature,pressure" will get all messages with temperature or pressure data.
Message routing can be defined with much higher flexibility thanks to the hierarchical matching. A hierarchical tag has at least one dot character. The whole routing scheme with hierarchical tags can be described based on naming examples known from Usenet discussion groups.
The following example set of publisher messages can help to visualize the routing scheme:
"comp.lang.ada""comp.lang.c++""comp.lang.java""comp.lang.c++,comp.lang.java""comp.programming.threads""dilbertjokes"With these messages in the system, the following describe the effect of various subscription patterns:
"comp.lang.ada" will get only message A,"comp.lang.c++" will get messages B and D,"comp.lang.ada,comp.lang.c++" will get messages A, B and D,"comp.lang.*" will get all messages related to programming languages - that is, A, B, C and D,"comp.*" will get all computer-related messages - that is, A, B, C, D and E,"*" will get all messages listed above,"temperature" will not get any message, as there is no message with such a tag.
It should be noted that a wildcard "*" is supposed to match a single whole subcomponent of a hierarchical name or all remaining subcomponents if it is the last character in the subscription tag.
The combination of these two features - multi-way tag matching and hierarchical tags with wildcard patterns - allows to set up very flexible routing schemes.