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.
