The SOAP Internet-Draft (http://search.ietf.org/internet-drafts/draft-box-http-soap-01.txt) provides
the following example of a SOAP request:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml
Content-Length: nnnn
SOAPMethodName: Some-Namespace-URI#GetLastTradePrice
<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
<SOAP:Body>
<m:GetLastTradePrice xmlns:m="Some-Namespace-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP:Body>
</SOAP:Envelope>
This request can be divided into 2 parts:


HTTP header (lines 1-5)
XML-RPC payload (lines 6-12, the SOAP:Envelope element)
The fact that the XML-RPC payload can be so easily divorced from the HTTP header suggests
that it should be possible to develop a standard for an XML-RPC payload independent of
transport. This idea has been brought up in the SOAP discussion group and was developed
further by Kent Brown in an article in the November 1999 edition of Enterprise Development
(http://www.enterprisedev.com/upload/free/features/entdev/1999/11nov99/cv1199//cv1199.asp ):
"The SOAP spec specifically addresses XML-based RPC over HTTP. It does not
address how the same payloads might be sent over other message transports such
as SMTP (the Internet e-mail protocol), multi-cast message systems such as TIBCO,
or reliable queue-based message systems such as MQSeries or MSMQ. However, I
see the non-HTTP-specific parts of the SOAP spec … as being very useful at
providing a standard format for usage in these other messaging systems."
I would like to expand on Kent’s thoughts with particular reference to projects we are
working on at TIBCO.
Layering an XML-RPC mechanism on top of HTTP has obvious benefits:


HTTP is ubiquitous. HTTP is the most common protocol used to access information
via the Internet.
HTTP penetrates firewalls. As David Chappell has pointed out in his whitepaper
entitled “Simple Object Access Protocol (SOAP) and Firewalls”
(http://msdn.microsoft.com/xml/general/soap_white_paper.asp): “[HTTP] enable[s] applications to
communicate directly with each other without being unintentionally blocked by firewalls.”
XML-RPC on Messaging Transports Other Than HTTP
SOAP IETF BOF Meeting
Page 1 of 2
1/25/2000
However, using HTTP as a transport mechanism for XML-RPC also has obvious
drawbacks:


HTTP is a synchronous request/reply protocol. Even if an XML-RPC payload
is of type void and has only input parameters, still, if HTTP is used as the
transport, a reply will be returned by the application server for every POST.
HTTP is a 1-to-1 protocol. In order to send an XML-RPC payload to n
subscribers, n HTTP connections must be established.
Now, HTTP is simply one of a wide variety of different communication paradigms. For
example, TIBCO supports the following paradigms:



1-to-1 synchronous and asynchronous request-reply
1-to-many synchronous and asynchronous request-reply (useful in soliciting
bids from multiple vendors, in collecting different pieces of information from
multiple sources, or for resource discovery)
Publish/subscribe (1-to-many one way)
It is easy to imagine XML-RPC payloads being used in conjunction with each of these
paradigms. The conclusion we should draw is that it’s a good idea to develop a
standard for XML-RPC independent of communication paradigm/transport.
One final comment. It has been our experience at TIBCO that system administrators are
quite willing to open other ports in the firewall besides port 80 if the benefit is great
enough and if security can be guaranteed through some mechanism. This is another
argument for not tying XML-RPC too closely to HTTP. HTTP should not be set up as the
only mechanism by which the firewall can be penetrated. What customers cannot do
without, however, is messaging interoperability. And this interoperability will certainly be
enhanced by an XML-RPC standard defined independent of transport.
XML-RPC on Messaging Transports Other Than HTTP
SOAP IETF BOF Meeting
Page 2 of 2
1/25/2000