|Topic||Clients of XmlBlaster can specify their desired callbacks during login|
When you subscribe to messages or get sent a PtP message, xmlBlaster will deliver this to you through a callback.
You can specify your preferred callback protocol and your address through the
qos (Quality of Service) parameter of the login method.
The default callback protocol is "SOCKET" which stands for our native protocol format.
"IOR" stands for a CORBA callback. The client must in this case supply a Corba callback interface with the method update() and ping(), see xmlBlaster.idl. This method is called by xmlBlaster for callbacks.
Other supported protocols are "RMI" and "XMLRPC", scheduled protocols are "EMAIL" and "SOAP".
Further protocols may be plugged into xmlBlaster very easy -
you only need to implement the interface I_CallbackDriver.java
with your protocol driver and register it in xmlBlaster.properties
You can specify zero to many callbacks for one single client, with mixed protocols, all of them will be invoked for new messages.
For detailed QoS examples see requirement "engine.callback" For examples using raw Corba, see demo/javaclients/corba/ClientRaw.java testsuite/src/c++/clientPOA.cc
NOTE: Configuration parameters are specified on command line (-someValue 17) or in the
xmlBlaster.properties file (someValue=17). See requirement "util.property" for details.
A callback address corresponds to a callback server created by a client. A client may establish many callback servers, for example one CORBA and another for XMLRPC. Only one callback address is actively used by xmlBlaster. If the callback fails, the subsequent callback addresses will be tried until the message is delivered. If all callback addresses fail, the result will depend on the specified login qos. Below there follows a QoS of a login method, this raw string is delivered to xmlBlaster to control the behavior of this client. All elements/attributes have a default value, so a simple <qos></qos> will allow a login as well. In this case no callbacks are possible but synchronous access with get() runs fine. Delegated subscribes: it is possible to subscribe for somebody else to certain messages. This can be handled by logging in again with the callback addresses of that delegated client (kind of gift)
This page is generated from the requirement XML file xmlBlaster/doc/requirements/engine.qos.login.callback.xml
Back to overview