XmlBlaster Logo



XmlBlaster Logo

Type NEW
Priority MEDIUM
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

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.

Change Request
   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
   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)

See REQ protocol
See REQ engine.callback
See API org.xmlBlaster.client.LoginQosWrapper
See API org.xmlBlaster.util.qos.address.CallbackAddress
See API org.xmlBlaster.util.qos.storage.QueueProperty
See API org.xmlBlaster.client.qos.ConnectQos

This page is generated from the requirement XML file xmlBlaster/doc/requirements/engine.qos.login.callback.xml

Back to overview