RPCTF: Should RPC be core or an extension ?

Should RPC be part of the core SOAP specification or an architected
extension ?

I believe the SOAP 1.1 specification confused matters by including sections
on RPC and encoding. Readers of the specification came to the incorrect
conclusion that SOAP was inextricably linked to RPC. As Henrik pointed out
inthe early days of the WG, SOAP is really only a single way message with
RPC being a convention for linking two single way messages into a
request/response pair together with an encoding mechanism. By removing  RPC
from the core specification and placing it into a separate extension, we
have the opportunity to correct the confusion that I believe originates
from SOAP 1.1.

There is a second reason for removing RPC from the core specification.
There is a large body of users (the EDI community via ebXML) for whom RPC
is not the preferred invocation mechanism. They operate with a document
exchange model which may include boxcarring of business documents in a
single message each of which is of equal processing importance. If the WG
perpetuates the perceived importance of RPC by including it in the core
specification rather than viewing it as an extension, then acceptance of
SOAP in some communities may be diminished.

Comments please,
John

XML Technology and Messaging,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com

Received on Wednesday, 25 July 2001 06:38:10 UTC