REQUIREMENT
engine.qos.login.callback
|
|
REQUIREMENT engine.qos.login.callback |
|
| Type | NEW |
| Priority | MEDIUM |
| Status | CLOSED |
| Topic | Clients of XmlBlaster can specify their desired callbacks during login |
|
Des cription |
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. |
|
Example Java |
For detailed QoS examples see requirement "engine.callback"
For examples using raw Corba, see
demo/javaclients/corba/ClientRaw.java
testsuite/src/c++/clientPOA.cc
|
| Configure |
NOTE: Configuration parameters are specified on command line (-someValue 17) or in the
xmlBlaster.properties file (someValue=17). See requirement "util.property" for details. |
| 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
<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)
|
| 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