XmlBlaster Logo



XmlBlaster Logo

Type NEW
Priority HIGH
Topic XmlBlaster has a MIME based plugin interface to filter message access

XmlBlaster allows you to query topics based on their meta information with XPath. Sometimes this is not enough. The key-meta information for one topic (say oid="Track") is immutable. Putting dynamic data into the topic meta information is not supported as implementing it has impact on performance. Distributing thousand messages / second under different topics is memory consuming.

This is a use case where you may want to write a little plugin, doing some query in the message content (it is like a full text search). Please study the following illustration which shows this use case.

Example how to use the MIME plugin

All airplanes are sending their GPS track coordinates every 5 seconds. If you track 5000 airplanes you have 1000 messages/second. Performance is a real challenge here.

Air traffic controllers want to zoom into special geographic areas and need to subscribe to only those airplanes which are in their latitude and longitude range.

An air traffic controller subscribes to the message oid="Track". Other messages won't be delivered. It is a normal subscription. Now his software adds a filter rule, which is evaluated on each track message by your plugin.

As a plugin coder, you have to implement two interfaces

  • I_Plugin: Which allows xmlBlaster to load the plugin
  • I_AccessFilter: Which forces you to implement the match() method
This is simple and straight forward (see requirement mime.plugin.accessfilter.howto).

Filter Features:

  • MIME based plugin selection
    The plugin you code has to supply MIME types which it can handle. Only messages of this mime type are directed to the plugin. The mime type "*" registers the plugin for all message MIME types.
  • Filter support for synchronous access with get() and asynchronous access with subscribe()
    You can specify the filter rules with two xmlBlaster methods:
    1. Synchronous access with the get() invocation:
      Specify the filter rule in the QoS of the get() method to filter the desired messages. The messages are returned as the get() return value.
    2. Asynchronous access with the subscribe() invocation
      Specify the filter rule in the QoS of the subscribe() method to filter the desired messages. The messages are returned with the asynchronous update() callback.
  • Multiple filters per subscription
    Multiple filters can be specified in one subscribe/get invocation. Each of them may address another plugin. They are sequentially executed and if one filter denies access (the match() method returns 'false') the message is not delivered. The filters are logically AND connected.
  • Cascading approach for XPath/exact query and filters
    On subscribe first the usual XPATH or exact subscription is checked. The client is added as subscriber to all matching message types. If now real messages arrive, the filter plugin is additionally filtering messages away. The same applies for get() invocations.
  • The plugin can analyze the complete message
    The plugin has access to the complete message, key, content and QoS. It can use all those informations to decide access or deny.
  • The plugin can manipulate the message content
    The plugin may manipulate the content of the message if desired, delivering changed content to the client. Changing of the key or qos is not allowed, as the problems which may ocurre are not analyzed yet.


These is an example key and QoS of a subscribe() invocation:

   <key oid='' queryType='XPATH'>

      <filter type='ContentLenFilter'>
      <filter type='ContainsChecker' version='7.1'>


All messages containing the xml meta information element <StockData/> are selected.
Those message are further filtered to not contain the word 'sex' in the message content and to have a content shorter then 8 kBytes.

The topic of the message below contains the topic meta information <StockData/> and is therefore subscribed, but it is filtered away as it contains the word sex:

      <key oid="MyMessage"><StockData/></key>

      <content>Enhance your sex ...</content>



Note that some filter plugins check the qos settings of the message, others check the content of a message

Don't forget to put your query string in a <![CDATA[ ... ]]> section if you use "<" in your query string.


For coding and configuration of plugins please read the requirement mime.plugin.access.howto (see link below)

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.engine.mime.I_AccessFilter
See API org.xmlBlaster.engine.mime.demo.ContentLenFilter
See API org.xmlBlaster.util.plugin.I_Plugin
See REQ mime.plugin.accessfilter.howto
See REQ mime.plugin.access.regex
See REQ mime.plugin.access.sql92
See REQ mime.plugin.access.xpath
See REQ util.property.env
See REQ mime.plugin.publishfilter
See TEST org.xmlBlaster.test.mime.TestSubscribeFilter
See TEST org.xmlBlaster.test.mime.TestGetFilter

This page is generated from the requirement XML file xmlBlaster/doc/requirements/mime.plugin.accessfilter.xml

Back to overview