[R2xx] Application of XP Requirements to SOAP 1.1

I've quoted the original requirements in the 2xx section, described 
specific sections of the SOAP 1.1 spec [1] that address the requirements 
and raised issues where there may be conflicts.

--Vidur


R200

    "The XML Protocol must contain a convention for representing
     calls and replies between RPC (Remote Procedure Call)
     applications and services."

Section 7 [1] of the SOAP 1.1 spec addresses the issue of using SOAP for 
RPC. It provides a "uniform representation of remote procedure calls and 
responses".

    "The conventions must include the following:
       1.Complete and unique identification, by means of URI
       syntax, of the program, service or object and procedure
       or method to be called."

Section 7 states that the "URI of the target object" is necessary to 
make an RPC calls and that the "protocol binding [should] provide a 
mechanism for carrying the URI". It further implies that the method name 
should be a QName, and is modeled as an element in the SOAP enveloper body.

Issue RPC1: The target (program, service or object) URI is pushed down 
to the protocol binding and is not represented in the envelope instead. 
While this does not conflict with the requirements, I believe it's an 
important (and possibly debatable) decision. This decision precludes 
sending an RPC invocation through an intermediary that uses different 
protocol bindings for sending and receiving XP messages.

Issue RPC2: The SOAP 1.1 spec uses words like "object" and "method" to 
refer to the end-points of an RPC operation. More generic words (or 
better qualification of these terms) that do not bias the reader towards 
expectations of full-fledged object systems on both sides are necessary.

Issue RPC3: The requirements state that the "procedure or method to be 
called" should also be represented using URI syntax. I believe this is 
an error in our document - the requirements should place no restrictions 
on the form of a procedure or method name.

    "2.Enable support for matching response messages to request
     messages for cases in which matching is not provided by the
     underlying protocol binding."

Section 7.2 states that a transaction ID is an example of the use of a 
SOAP header element.

Issue RPC4: This does not seem to be a normative part of the 
specification and no rules are placed on the form of such a transaction ID.

    "3.The ability to specify the parameters to a call in a
     request message and the results of a call in a reply
     messages."

Section 7.1 describes how elements in the body of a SOAP envelope can be 
used to represent parameters in an invocation and return values (and out 
parameters) in a response.

    "4.Provisions for specifying errors in a reply message
     (see also 703a and 703b) "

Section 7.1 states that a "method fault is encoded using the SOAP Fault 
element".

Issue RPC5: Should there be a predefined set of fault codes that apply 
specifically to RPC? Examples would include errors for missing 
parameters, out of range values, etc.

    "Where possible, an attempt will be made to leverage any
     related work done by the IETF."

Issue RPC6: The SOAP 1.1. spec does not directly reference the IETF work 
on RPC [2]. Is the quoted RFC out-of-date? Should more attention have 
been paid to IETF activity?

---------------------------

R201

    "The RPC conventions within the XML Protocol should use the Data
     Representation model discussed in section 4.5 to represent
     parameters to a call in the request message and results of
     the call in the reply message."

A method invocation is modeled as a struct. Parameters and results are 
modeled as accessors on the struct. The concepts of "struct" and 
"accessor" are loosely described in Section 5 [3] of the specification.

Issue RPC7: SOAP 1.1 describes its notion of a "data model" in a section 
describing an encoding system. The notion of a data model should 
probably be separated from the actual physical representation.

    "It must be convenient to create straightforward mappings of
     the data types to a wide variety of widely deployed
     programming languages and object systems."

The Schema types [4] have been shown to map to a reasonable set of 
native data types in commonly used programming languages and object 
systems. The additional types described in SOAP 1.1 - structs, arrays - 
also map to commonly used programming constructs.

---------------------------

R202

    "The XML Protocol should allow applications to include custom
     encodings for data types used for parameters and results in
     RPC messages."

The SOAP encodingStyle attribute [5] can be used to used to indicate 
arbitrary serialization rules within a SOAP message. Section 5 [3] of 
the specification also states that "use of the data model and encoding 
style described in [the section describing the default SOAP encoding] is 
encouraged but not required; other data models and encodings can be used 
in conjunction with SOAP."

---------------------------

[1] http://www.w3.org/TR/SOAP/#_Toc478383532
[2] http://www.ietf.org/rfc/rfc1831.txt
[3] http://www.w3.org/TR/SOAP/#_Toc478383512
[4] http://www.w3.org/TR/xmlschema-2/
[5] http://www.w3.org/TR/SOAP/#_Toc478383495

Received on Tuesday, 30 January 2001 19:28:37 UTC