Des
cription |
XmlBlaster is a MoM (message oriented middleware) supporting distributed
clients to communicate through messages.
All messages have a header, a content and a QoS.
-
HEADER - The message meta data
The header is XML based, so you are able to place your meta data
of the message content here.
Your are able to query this meta data with XPath, the XML query language.
Example:
<key oid='Product.Toaster' contentMime='image/gif'>
<color>blue</color>
<model>TopFamily</model>
<description>Picture of the new family toaster model</description>
</key>
-
CONTENT - the data BLOB
The message content is a BLOB (binary data, or an 'octet sequence' in CORBA jargon).
So you may send JPEG, ASCII, XML, serialized code or whatever with your messages.
You can't query the content, but we will provide a MIME based plugin possibility in a future
release, with a XML-XPath plugin as an example.
This will allow full text searches.
Example:
[Here is the binary data of the gif image]
-
QoS - the Quality of Service
The Quality of Service are XML based informations to control the xmlBlaster.
For example you may specify some expiration date or transaction context or
whatever the xmlBlaster is supporting.
If you use the direct addressing style, the destination addresses or destination XPath
queries are placed here.
Example:
<qos>
<persistent /> <!-- The message shall be recoverable if xmlBlaster crashes -->
</qos>
Topics and messages:
A topic is a server side instance which handles identical message oids. The first
message with a specific oid creates the topic in the server and further messages
with identical oids are handled by this topic.
Features of messages:
- Messages are created when published
When a data source (a client) publishes a message it
gets created in xmlBlaster.
- A message has a unique identifier (oid)
If not specified by the publisher,
a unique oid (object identifier) is generated by xmlBlaster for every message.
Publisher using their own message oid should take care to avoid naming
conflicts.
The oid can in this case be hierarchically organized, for example
oid="MyCompany.MyProject.statusOfXy".
- Messages have a span of life
A message can be erased explicitly by a call with erase() or
is discarded on expire timeout.
The message life cycle defaults to forever.
- Messages are atomic entities
A message is a small unit of data. The publisher decides what he puts
into a message, but usually using atomic information nucleus is a good choice.
- The message meta data (key) is invariant
Once a topic with an unique oid (object id) is created, the
meta information (the attributes and descendant tags of the key)
can't be changed any more. They are final - const - readonly.
To change the key info, you need to delete and recreate the topic
or publish another message with another key oid.
- The message QoS can contain a transaction context
Messages can be processed under transaction control (two phase commit).
This feature is not yet implemented.
- History of messages
Further published messages with the same oid overwrite the previous message (the history depth is one).
If message history is needed each topic has a
history queue which you can configure with the first published message (or with
an initial administrative message).
|
