RE: [R5xx] Application of requirements to SOAP 1.1

John,

Looks good - a few comments...

> R501
> The specification will make reasonable efforts to support 
> (but not define)
> a broad range of protocol bindings between communicating peers.
> 
> The SOAP 1.1 specification defines a binding to HTTP only. 
> Therefore it
> only partially supports requirement R501.

The MIME multipart binding defined by the SOAP attachment spec [1] is in
many respects a SOAP binding (and in this spirit it describes itself as
such) so there is at least tentative proof that it can be done. Although
it is correct that SOAP/1.1 doesn't define any other binding than for
HTTP, I believe R501 talks about "support" and not "define" such
bindings.
 
> R502
> The specification developed by the Working Group must support either
> directly or via well defined extension mechanisms different messaging
> patterns and scenarios. The specification will directly 
> support One-way and
> Request-response patterns as part of permanently and intermittently
> connected scenarios. The specification will not preclude the 
> development of
> other patterns at either the application or transport layers. 
> Examples of
> such patterns may include publish-subscribe or multicast delivery. All
> patterns and scenarios will be described by relevant use cases.
> 
> The SOAP 1.1 specification partially supports requirement 
> R502. There are
> no explicit examples in the SOAP 1.1 specification to support this
> requirement. The XP specification must provide a broader set 
> of patterns
> and scenarios.

I agree that more patterns and scenarios would be extremely useful -
also in indicating that this is not just another RPC protocol (TINJARP).
Just to clarify (not that I think you imply this by any means) I don't
believe there is anything inherently prevents using SOAP in more
complicated (or simpler) message exchange patterns.
 
> R504
> The specification developed by the Working Group shall be as 
> lightweight as
> possible keeping parts that are mandatory to the minimum. 
> Optional parts of
> the specification should be orthogonal to each other allowing
> non-conflicting configurations to be implemented.
> 
> The SOAP 1.1 specification provides a lightweight framework with
> extensibility via namespace defined header elements. The SOAP 
> Body provides
> a mechanism for exchanging mandatory information (Section 4.3). This
> provides only part of the extensibility requirements implied by R504.
> Therefore the SOAP 1.1 specification partly fulfils R504.

There is also the "mustUnderstand" attribute for SOAP headers which I
think is important in this context.
 
> R505
> The specification must be suitable for use between 
> communicating parties
> that do not have a priori knowledge of each other.
> 
> The SOAP 1.1 specification does not support this requirement. At the
> minimum, there has to be an implicit assumption that the communicating
> parties will understand the SOAP protocol. The protocol does 
> not provide a
> mechanism for submitting a SOAP request to a generic HTTP (or other
> protocol) server.

I think there are two parts here - 1) what is expected from a SOAP
processor and 2) what are the influences from the underlying protocol
binding. It might be instructive to look at both:

1) Once a SOAP processor is invoked, the processing rules are in fact
clear for what to do with the message and that can happen without the
SOAP processor knowing anything about the other peer. In this sense, two
SOAP peers can communicate without prior knowledge other than a way to
identifying each other by a URI.

2) Sending a SOAP message in a normal HTTP POST messages give no
guarantee what so ever that there is a SOAP processor in the other end.
But in fact it is not a property of SOAP as much as it is of the HTTP
binding. This is why there are two HTTP bindings in the SOAP/1.1 spec -
one that used the HTTP extension framework and one that uses plain old
HTTP.

The former allows for enforcing within HTTP that the HTTP entity body
(the SOAP envelope) is dealt with by using the only mechanism that can
cause an HTTP request to fail in a deterministic manner: using a
different method name (M-POST).

The latter doesn't but this is similar to one taking a SOAP message and
store it in a file somewhere - there is no guarantee that it ever be
processed.

> R506
> The specification must focus on the encapsulation and 
> representation of
> data being transferred between parties capable of generating and/or
> accepting an XP protocol envelope.
> 
> The SOAP 1.1 specification partially fulfils this 
> requirement. It provides
> one mechanism for encapsulation and encoding of data with 
> limited examples
> of extensibility. The XP specification must broaden these 
> mechanisms via
> use cases.

I don't understand this objection?

Henrik

[1] http://www.w3.org/TR/SOAP-attachments

Received on Wednesday, 31 January 2001 12:01:32 UTC