XmlBlaster Logo



XmlBlaster Logo

Type NEW
Priority HIGH
Topic XmlBlaster uses a well defined message format

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.
    <key oid='Product.Toaster' contentMime='image/gif'>
       <description>Picture of the new family toaster model</description>
  • 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.
    [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.
       <persistent />  <!-- The message shall be recoverable if xmlBlaster crashes -->

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).
See link to Javadoc API of PublishQos below how to set message attributes.

These parameters allow to configure the xmlBlaster server default behavior.

Property Default Description Implemented
message.maxRemainingLife 0 A message lease lasts forever if not otherwise specified. Specifies the maximum lifetime in milliseconds in the server, 0 is forever. yes

These parameters can be specified on client side with java clients (see ConnectQos API).

Other programming languages need to supply these setting with a raw XML string (see example section above).

Property Default Description Implemented
message.remainingLife 0 A message lease lasts forever if not otherwise specified. Specifies the lifetime in milliseconds for a specific message on publish(), 0 is forever. yes

NOTE: Configuration parameters are specified on command line (-someValue 17) or in the xmlBlaster.properties file (someValue=17). See requirement "util.property" for details.
Columns named Impl tells you if the feature is implemented.
Columns named Hot tells you if the configuration is changeable in hot operation.

See API org.xmlBlaster.client.qos.PublishQos
See API org.xmlBlaster.client.key.PublishKey
See API org.xmlBlaster.engine.xml2java.PublishQos
See REQ engine.message.lifecycle
See REQ engine.queue
See REQ engine.callback
See REQ util.property

This page is generated from the requirement XML file xmlBlaster/doc/requirements/engine.message.xml

Back to overview