XmlBlaster Logo

REQUIREMENT

protocol.xmlrpc

XmlBlaster Logo


Type NEW
Priority HIGH
Status CLOSED
Topic XmlBlaster supports XmlRpc
Des
cription

The XmlRpc protocol is very simple, it uses http as underlying protocol with some XML markup for remote method invocation.

XmlBlaster has fully operational XmlRpc support, we provide client examples in C, Perl, PHP, Python, Macromedia Flash, CSharp (C#) and Java which use XmlRpc to connect to xmlBlaster. Please see xmlBlaster/demo/javaclients.

It is now possible to run xmlrpc over https and through an http Proxy or a reverse Proxy. You could for example choose to run HTTPS to an Apache Server configured as a reverse proxy where the connection to the XmlBlaster Server is done either by HTTP or by HTTPS. In the later case you can let the XmlBlaster Server take care about the authentication of the client.

Example
Java
Configure
Property Default / Example Description Implemented
plugin/xmlrpc/hostname localhost Specify a hostname where the XMLRPC server runs yes
plugin/xmlrpc/port 7607 The XMLRPC server port yes
plugin/xmlrpc/localHostname localhost The local address the xmlrpc is bound to. Usually this is dynamically choosen by your operating system and you don't need to specify it. yes
plugin/xmlrpc/localPort 8900 The local port the xmlrpc is bound to. Default is -1 and the operating system chooses an arbitrary port. yes
plugin/xmlrpc/useCDATA false Encapsulates all parameters with a CDATA. Note that you can use this only if you are sure that your Messages do not contain already a CDATA (the key, qos and content), otherwise you will get an exception. This flag is only used for systems which need to validate the content of the message on a protocol layer, for example proxies or firewalls. If unsure leave this untouched. If you set this flag on the server it will modify all updates and callback pings, if you set it on the client it will influence all requests coming from the client. yes
plugin/xmlrpc/customProxyClass null The name of the class to use for proxying requests coming from the client. This class shall only be specified if you have some non-standard behaviour, i.e. if your client is sending xmlrpc commands which are not the normal subscribe, publish ... methods internally defined by xmlBlaster. Suppose you want to send the HTTP Requests over a proxy, a firewall or a proprietary security gateway which does not allow these methods, then you could tunnel these inside other methods which are defined by a proprietary client protocol. On the server side these requests have to be extracted and decoded before invoking the original xmlBlasterImpl and authenticate requests. yes
plugin/xmlrpc/responseTimeout 0 The time it shall wait in milliseconds before interrupting the request. If zero or negative it is not set. yes
plugin/xmlrpc/SoTimeout 0 If zero or negative it is not set. It has the same meaning as for the SOCKET Protocol. yes
plugin/xmlrpc/compress/type Its only possible value is either an empty string (unset) or 'zlib'. Compression will be done on the protocol layer. You only need to define this on the client side, the server will then recognize if the client is expecting compressed or uncompressed data. yes
plugin/xmlrpc/proxyHost null If you use a proxy this specifies the hostname or IP of the host to use. Note that if you have not specified this property, it will be implicitly set to localhost if you specified proxyPort. yes
plugin/xmlrpc/proxyPort null If you set this property the protocol will use a proxy, even if you did not explicitly specify a proxyPort or the proxySet property. If you set this property and the proxyHost property is not explicitly set, the later will be set to localhost. yes
plugin/xmlrpc/proxyHostSSL You specify this property only if you want HTTPS Traffic to be directed to a proxy different from the HTTP Proxy. If you do not specify anything here, then the same host will be used for HTTP and HTTPS. yes
plugin/xmlrpc/proxyPortSSL You specify this property only if you want HTTPS Traffic to be directed to a proxy port different from the HTTP Proxy port. If you do not specify anything here, then the same port will be used for HTTP and HTTPS. yes
plugin/xmlrpc/basicUserName If basic authentication is activated on the server side (for example in a reverse proxy), then you can pass that username here. yes
plugin/xmlrpc/basicPassword If basic authentication is activated on the server side (for example in a reverse proxy), then you can pass the password to be used here. yes
plugin/xmlrpc/basicEncoding If basic authentication is activated on the server side (for example in a reverse proxy), then you can pass the encoding to be used here. yes

The Java xmlrpc implementation on client side supports the same properties as the server. You need to add the "dispatch/callback/" or "dispatch/connection/" prefix to the property key.
You have thes additional features on client side:

Property Default Description Implemented

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.

Todo
See REQ protocol
See http://www.xmlrpc.org/
See API org.xmlBlaster.protocol.xmlrpc.XmlRpcDriver
See API org.xmlBlaster.protocol.xmlrpc.XmlRpcUrl
See API org.xmlBlaster.client.protocol.xmlrpc.XmlRpcConnection

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

Back to overview