FAQ xmlBlaster


Why should I need such a middleware?

If you have a distributed client / server architecture you will face the problem how all the processes communicate with each other. xmlBlaster provides a professional way for sending instant messages between C/C++, Perl, Tcl, Java, Php and any other CORBA, SOCKET or XmlRpc aware programming language based process. If parts of the clients are off line, messages will be queued reliable.

Message routing may be based on two different styles:

  • The Pub/Sub (publish and subscribe) paradigm.
    Here the sender doesn't know the receivers. The sender publishes data and interested clients independently subscribe to it.
    This is a very powerful communication schema.
  • The PtP (point to point or point to broadcast) paradigm.
    Point to points allows direct addressing to named destinations. If the addressed client is not on line (logged in), the messages are queued.
    Broadcasts allow to address destinations which are selected by XPath queries over receiver meta informations like receiver roles or receiver groups or any other XML based meta information.

Why CORBA, XmlRpc and XML, is it only a hype?

Yes, its a hype, but a nice one.
CORBA allows inter operability between all major programming languages with type safety at compile time.
XML allows dynamic modeling of real day problem domains with type safety at runtime and free versioning.
The query language XPath allows to access XML in a powerful way.
XmlRpc is a very simple protocol using HTTP, and allows easy integration of scripting languages.

Why is it open source?

We use a lot of open source products in daily life, for example gcc and Linux.
So we had the desire to contribute something back to the community.
The license is based on LGPL (see LICENSE file).
Please note that the code is delivered as is, there are no warranties.

Can is use xmlBlaster for free in my commercial application?

Yes.

Are there examples how to access xmlBlaster with Java, C/C++, Perl, TCL, Python, Php ?

Yes, there are examples provided in the directory xmlBlaster/demo and xmlBlaster/testsuite
You can try the examples with xmlBlaster and if you like it, use the examples as a base for your own applications.
If you are using xmlBlaster with other languages, it would be nice if you could send us a little note with some working code.
See the installation page for useful links.

What is the current state of xmlBlaster, can I use it in my project?

Yes, you can use it in your project.

XmlBlaster has a rich featured support for Publish/Subscribe and PtP operation and clustered operation
and the development is very active and alive.
XmlBlaster has a powerful plugin architecture where you can write specific plugins for you special problem domain - but usually the default plugins are powerful enough to support common MoM tasks.

We develop daily on xmlBlaster, since it is used in many commercial applications already like air traffic control, telecommunication / satellite industry, industrial control, ship control, GPS car control etc. So, xmlBlaster is even getting better with every day.

Note that there is no transaction support yet, but reliable store and forward (acknowledged message delivery) with crash recovery is available. For most applications this is quite enough. Transaction support is planned for a future release.

Is there any database (RDBMS/ODBMS/NativeXML) used in xmlBlaster?

Persistency is handled by a plugin framework. Currently there are plugins for Postgres http://www.postgresql.org, Microsoft-SQLServer http://www.microsoft.com/sql, Oracle http://www.oracle.com, Firebird http://www.ibphoenix.com, HSQLDB and some other databases available.

All persistency requests from xmlBlaster are forwarded to the I_Queue and I_Map plugin interface which uses the configured plugin to store the data in the backend RDBMS.

See requirement queue.jdbc.commontable. for a detailed description.

Which XML parser is used?

With xmlBlaster <= 1.0.6 you need to use SUNs crimson parser.
With xmlBlaster > 1.0.6 and with JDK 1.5 or above all DOM/SAX XML access is only using standardized XML API.
Here is an overview what you can set in your xmlBlaster.properties file:
  • JDK 1.5 or 1.6 - We use only DOM Level 3 compliant coding, so any such parser should do the job. You can use the XML parser delivered with the JDK or any other modern and standard conforming XML parser, the parser can be forced with (here the SUN-JDK 1.5 and 1.6 default setting): 
    javax.xml.parsers.SAXParserFactory = com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
javax.xml.parsers.DocumentBuilderFactory = com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
javax.xml.transform.TransformerFactory = com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
    The jar files xmlBlaster/lib/jaxp.jar and xmlBlaster/lib/parser.jar are not needed anymore.
  • JDK 1.4 - We need the SUN crimson parser. Other XML parsers are not supported as we use none standard crimson functions. This parser is delivered with JDK 1.4. The parser is forced with: 
    javax.xml.parsers.SAXParserFactory = org.apache.crimson.jaxp.SAXParserFactoryImpl
javax.xml.parsers.DocumentBuilderFactory = org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
javax.xml.transform.TransformerFactory = org.apache.xalan.processor.TransformerFactoryImpl
  • JDK 1.2 und 1.3 - We need the SUN crimson parser. Other XML parsers are not supported as we use none standard crimson functions. The parser is delivered in the jar files xmlBlaster/lib/jaxp.jar and xmlBlaster/lib/parser.jar and is forced with: 
    javax.xml.parsers.SAXParserFactory = org.apache.crimson.jaxp.SAXParserFactoryImpl
javax.xml.parsers.DocumentBuilderFactory = org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
javax.xml.transform.TransformerFactory = org.apache.xalan.processor.TransformerFactoryImpl
  • For IBM JDK 1.4 and IBM JDK 1.5 please use: 
    javax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl
javax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
javax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

What is XML'ish with xmlBlaster?

All messages sent using xmlBlaster have a header, a content and a QoS.
  • HEADER - The message meta data describing the topic
    The header is XML based, so you are able to place your meta data of the message content here. After a topic has been created with a first publish, this meta data is immutable.
    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 query the content with a MIME based plugin possibility. Plugins for 'full text' regex search and XPath search are provided as an example.
    This allows to add full text searches for any specific content you use.
    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>

What encoding is supported?

The three parts of a message have following requirements according to the charset used.
  • HEADER - This string is XML and only the default UTF-8 charset is supported.
  • CONTENT - The message content can contain anything
  • QoS - This string is XML and only the default UTF-8 encoding is supported. If you transport in the client properties anything else than UTF-8 you need to transform it to base64. The Java and the C++ client library assist you with base64 encoding.

How can i query topics with XPath?

Topics are stored in xmlBlaster building a huge DOM tree. Each topic has a unique name (see 'oid=...') and contains all messages with the same oid. Here are some messages sent to xmlBlaster, the key of each looks like: 
   <key oid='airtraffic.windspeed1' contentMime='text/plain'>
      <wind>
         <speed id='1' unit='knots'/>
      </wind>
   </key>

   <key oid='airtraffic.windspeed2' contentMime='text/plain'>
      <wind>
         <speed id='2' unit='knots'/>
      </wind>
   </key>

   <key oid='airtraffic.winddirection' contentMime='text/plain'>
      <wind>
         <direction/>
      </wind>
   </key>
If a topic with those oids are not existing they are dynamically created by xmlBlaster on the first message arriving. Internally we store those topics in a DOM tree: 
   <xmlBlaster>
      <key oid='airtraffic.windspeed1' contentMime='text/plain'>
         <wind>
            <speed unit='knots'/>
         </wind>
      </key>
      <key oid='airtraffic.windspeed2' contentMime='text/plain'>
         <wind>
            <speed id='2' unit='knots'/>
         </wind>
      </key>
      <key oid='airtraffic.winddirection' contentMime='text/plain'>
         <wind>
            <direction/>
         </wind>
      </key>
   </xmlBlaster>
Note that the DOM is immutable, if a follow up message for an existing oid changes the XML meta information this DOM change is ignored. To query only the wind speed of device 2 the XPath query could look like this: 
   //wind/speed[@id='2']
or like this (better performing query) 
   /xmlBlaster/key/wind/speed[@id='2']
The Zvon tutorials give a nice introduction on how to use XPath.

Here you find theXPath specification

Why is it not 100% JMS (Java Message Service) based?

JMS has several drawback, the main problems with JMS are:
  • JMS is not CORBA based.
    Trying to access JMS from Perl, Tcl, C/C++ or any other CORBA aware language will give you some major headache.
    But the world is and will ever be heterogeneous, so there is no place for narrow minded Java centric approaches.
  • JMS is not XML based.
    XML allows professional modeling of every day problems with free modification at runtime.
    So basing a middleware on the XML descriptive possibilities and allowing the query with a XML query language is a major advantage over key-value based approaches.
  • JMS API is split.
    xmlBlaster has only very few communication methods to allow the whole spectrum of MOM (Message orientated middleware) communication paradigms.
    Extending the xmlBlaster CORBA API once it is published as release 1.0 is very unlike.
    Adding new MOM features in future releases of xmlBlaster is mainly adding backward compatible XML tags.
  • JMS has a mixed HEADER section.
    Some header fields in JMS address the message content and some other the message routing.
    In xmlBlaster there is a clear separation between message meta data and quality of service.
  • JMS API is an API specification and no implementation.
    The reference implementation JMQ of JMS is no open source :-)
  • JMS API is a client side API and not a server side API.
    If you once have chosen a JMS server in a distributed environment you can't switch to another one, all clients and server are forced to use the same JMS implementation as the protocol is vendor specific.
Michele Laghi is currently implementing the JMS API to access xmlBlaster over JMS.

Which ports are used? How to configure the firewall?

Example for XmlRpc:

1. The server starts for example with: 

   java org.xmlBlaster.Main -plugin/xmlrpc/hostname hostA -plugin/xmlrpc/port 6002

and listens on: 

   http://hostA:6002/

so you need to open port 6002

2. If the client wishes callbacks: 

   java HelloWorld3 -protocol XMLRPC -dispatch/callback/plugin/xmlrpc/hostname hostB
                                     -dispatch/callback/plugin/xmlrpc/port 6007

so the client host needs to open port 6007 on hostB

Example for CORBA (JacORB): 
   java -DOAPort=6002 -DOAIAddr=hostA org.xmlBlaster.Main
   java -DOAPort=6007 -DOAIAddr=hostB HelloWorld3

Now the server listens on 6002 on hostA
and the client listens on 6007 on hostB.

Note that if you use our builtin IOR download, you need to open bootstrap port 3412 as well.
Adjust this with: 

   java -DOAPort=6002 -DOAIAddr=localhost org.xmlBlaster.Main
        -bootstrapHostname localhost -bootstrapPort 3412

Setting -bootstrapPort to 0 switches this feature off, but then you need to find other ways to transfer the server IOR.
For example by using a naming service and corbaloc or emailing the IOR or whatever.

Don't forget to switch off the protocols you don't need in xmlBlasterPlugins.xml

If you use Linux (or another UNIX) check the ports used with 

   lsof -i

so you have full control what happens.

Example for raw SOCKET communication:

XmlBlaster supports a native SOCKET protocol as well. This is best suited to tunnel firewalls since it doesn't need a callback server. Callback messages are sent in the same socket connection back to the client. Note that currently only for Java, C and C++ clients the SOCKET protocol is implemented (volunteers for other languages are welcome, there was a very basic implementation in Python already). 

   java org.xmlBlaster.Main
   java HelloWorld3 -protocol SOCKET

Now the server listens on 7607 and the client needs no listen port. 

   java org.xmlBlaster.Main -plugin/socket/port 8080
   java HelloWorld3 -protocol SOCKET -plugin/socket/port 8080

Now client and server communicate over port 8080 in both directions. This port is open in many firewalls. You can also use port 80, which is most certainly open in your firewall, but then the xmlBlaster server needs to run as root.

For more info read requirement protocol.socket.

How can i establish a secure connection?

Java clients with SSL out of the box

If you need a SSL connection from java clients to xmlBlaster this is available out of the box (JDK 1.4 or above). Please read details about the simple setup in protocol.socket requirement.

Setup with SSL tunneling

You can tunnel your access from clients to xmlBlaster using ssh to have a secure connection.

Here is an example using the SOCKET protocol of xmlBlaster: 

On the client machine establish a secure tunnel to the server host:

    ssh -L 7607:server:7607 server

Activate SOCKET in xmlBlasterPlugins.xml and start xmlBlaster:

    java org.xmlBlaster.Main

Start the client (in one line):

    java HelloWorld3 -protocol SOCKET -plugin/socket/hostname localhost
                                      -plugin/socket/port 7607

The HelloWorld3-client connection to xmlBlaster and its callback connection (which is the same socket) is tunneled secure with SSH!

Other useful tools for tunneling are Zebedee and the Java SSL toolkit.

On demand search the mailing list for a setup tunneling a CORBA connection and a CORBA callback connection with multiple ssh tunnels (described by sebastien.louafi@e-qual.fr)

For XmlRpc with SSL and tunneling through proxies (squid) read Does Squid support SSL/HTTPS/TLS

Why is it not COM/DCOM/COM+/.NET based?

What is COM ?? :-O

Which platforms are supported?

Every platform supporting JDK 1.4 or better (e.g. JDK from SUN or IBM) should be OK for the server to run.

The Java client side runs with JDK 1.4 or better, further there is a tiny J2ME and applet client library available.
For other programming languages / OS please see our feature matrix.

To develop xmlBlaster, there is ANT as the build tool, which should run on any Java aware platform with JDK 1.4 or better.
Further you can import the code into tools like eclipse to compile it (to use the CORBA protocol plugin you need to generate the stubs/skeletons first, typically by an ant call 'build java-corba-idl').

When starting xmlBlaster in background the CPU goes to 100% load

Please start the xmlBlaster server if running as a background process or as a Windows service with the argument -useKeyboard false.

How do i distribute an xmlBlaster server or an xmlBlaster Java client?

  • If you want to install the xmlBlaster server use ant to create a jar file:
     build dist
    Copy the created xmlBlaster-<version>.jar to the server host into the destination directory, unjar it and start the server as usual.
     java -jar lib/xmlBlaster.jar
    Try 
     build usage
    to find out about configuration options.

  • If you want to install a Java based xmlBlaster client use ant to create a jar file:
     build dist-client                         (client runs with JDK 1.2 or better)
 build -DADD_COLLECTION=true dist-client   (client runs under JDK 1.1x)
    This generates a file dist-client/lib/xmlBlasterClient.jar. Copy this jar file to your client host.
    Type 
     build usage
    to find out what options you have to add different packages to xmlBlasterClient.jar

  • This is for xmlBlaster version <= 1.0.6: Note that Java clients running under JDK 1.1 should use XMLRPC as protocol and the xmlBlaster server has to run with JDK 1.2 or 1.3 (not JDK 1.4). JDK 1.1 clients with CORBA or RMI throw exceptions (the reason is not tracked down). Example for JDK 1.1 client (type all in one line):
     java -classpath ${JAVA_HOME}/lib/classes.zip:
        dist-client/lib/xmlBlasterClient.jar:
        lib/jaxp.jar:lib/parser.jar
        HelloWorld3 -protocol XMLRPC

Java clients: Why is the key/qos on xmlBlaster method invocations a String instead of some "QosWrapper" object?

To avoid to "force" clients to use these wrappers if they don't want it. In any case, if you have the PublishQos.java object (lets call an instance of it qosWrapper), then you can pass qosWrapper.toXml() to the method publish(String qos, String qos).

All method invocations of xmlBlaster have simple strings as arguments. The strings are usually xml encoded. This allows future changes and enhancements without braking the client/server contract. (An older client may still talk to a newer server without need to recompile).

If we would pass objects (or structs) as arguments, the CORBA IDL would change with every small modification, for example adding a new QoS 'ForceUpdate' would change the object and could lead that an older client somewhere suddenly couldn't talk to the updated xmlBlaster server anymore.

Having the arguments as xml encoded strings, allows simple access, if you use Perl, Python, C++ or whatever.

The Java class PublishQos is just a simple helper class for Java clients, it is only provided that you don't need to type the xml ASCII string "by hand".

How can I contribute?

This is a great idea, fields of interest are distributed transactions, load balancing
and anything else you can imagine.
Fell free to contribute ideas, code, links or patches on our mailing list.
If you want to contribute code contact us to get subversion write access.

How can I get commercial support?

Michele Laghi and Marcel Ruff offer commercial support if you desire so.

How can I debug remotely the xmlBlaster?

To start the xmlBlaster just invoke: 
java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n org.xmlBlaster.Main
And then you can attach to it remotely with the debugger of your choice. For example with Eclipse you would debug as Remote Java Application using Standard (Socket Attach) as the Connection Type and the host and port (in this case 8787) on which the xmlBlaster is running.

HOME