XmlBlaster Logo



XmlBlaster Logo

Type NEW
Priority HIGH
Topic The cpp client library handles the communication to xmlBlaster transparently.

For the user
The user can make all invocations to xmlBlaster by using the class XmlBlasterAccess. This class hides all intrinsic communication protocol dependencies. In other words if you want to write a client to xmlBlaster you don't need any knowledge of the communication layer, i.e. CORBA, XMLRPC, SOCKET or whatever protocol you decide to use.

For the programmer
It is relatively easy to write a plugin that handles the communication to xmlBlaster. First of all you must make sure you have the counterpart on the server side. Lets say you want to write the socket plugin, such a protocol is already supported on the server side (and java clients).

  • Get familiar with the details of the protocol you want to implement (for example by reading the socket requirement).
  • Write a requirement describing the protocol (I should not say so since I am bad at it myself).
  • Write a class which implements I_XmlBlasterConnection (this will be the sender) and one which implements I_CallbackServer (the receiver). Note that I_CallbackServer and I_XmlBlasterConnection could be implemented by one single class (this is currently done in CORBA. See for that the CorbaDriver).
  • Add the code for the creation of an instance of the sender in the method DispatchManager::getPlugin(...) and the removal or deletion of that instance in the method DispatchManager::releasePlugin(...).
  • Add the code for the creation of an instance of the receiver in CbServerPluginManager::getPlugin(...) and the removal of the instance in CbServerPluginManager::releasePlugin(...)
  • Write a test suite which tests the good work you have done
  • Since you want to enjoy but also let others enjoy and admire your work, commit the code to CVS and make a statement on the mailing list

Normally, that is if the communication protocol driver is handled and controlled internally by the XmlBlasterAccess class, you don't need to bother about the underlying protocol. An example is if you are using the CORBA protocol and you you don't need/want to bother about CORBA, then you can instantiate XmlBlasterAccess and directly work with it. In such a case XmlBlasterAccess will create an orb instance, it will start the orb performing thread and it will clean up all corba resources on destruction.
There are usages where this is not sufficient. Suppose you have already an application which communicates with some other software via a particular CORBA implementation and you want to use the same orb instance for the communication to xmlBlaster. In such a case you need to

  • Instantiate the orb outside XmlBlasterAccess
  • invoke orb->run() or orb->perform_work() yourself
  • make a duplicate of the orb and pass it to CorbaDriverFactory::getFactory(global, orb). It is important that you do that before you create the first instance of XmlBlasterAccess. This way it is garanteed that XmlBlasterAccess will use the CorbaDriverFactory (which is a singleton) with the orb you passed to it.
  • You must cleanup the corba resources yourself (i.e. you need to invoke shutdown and destroy.
for example you For situations where you have to configure and instantiate protocol specific stuff, for example as if you would want to use an instance of an orb which you have instantiated outside XmlBlaster, you must make sure to instantiate the protocol driver by passing all external parameters. In the mentionned case we would create an instance of CorbaDriver by passing an external orb by assigning it a certain instance name. Then, when instantiating an XmlBlasterAccess object we must make sure to pass to it the same instance name. This way we make sure that we will use that particular instance of the driver and at the same time XmlBlasterAccess does not need to know anything about the protocol it will be using.


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 REQ client.cpp
See CODE ExternOrb

This page is generated from the requirement XML file xmlBlaster/doc/requirements/client.cpp.protocol.xml

Back to overview