Re: Issue 25 Proposal

Please see my comments inside. All IMHO unnecessary parts
removed.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Tue, 12 Jun 2001, Herve Ruellan wrote:

 > Jacek Kopecky wrote:
 > > Please, can you show me the specific problems created by
 > > separation of Headers and Body?
 >
 > First, I think that both headers and body are blocks, but separating
 > them enforce to process them separately.

I agree completely and I think that's the point for separation.
8-)

 > Second, there are several use cases where it is needed to have a
 > header after the body (that is a block containing metadata like
 > a checksum after the block containing the application message).
 > To handle such use cases we have either to rely on tricks (putting
 > the application message in a header and having the body refer to
 > it) or to introduce trailers which may or may not be fully-
 > fledged blocks.

I think that introducing trailers which are not full-fledged
blocks is exactly what the first proposal in [1] is about.

 > Third, having only one block for the body do not allow us to
 > send multiple application messages in one SOAP message to a given
 > target. This may be useful for some applications (for example,
 > I would be able to tell my bank in one SOAP message that I want
 > to buy Canon stocks and sell France-Telecom stocks).

The point against protocol-level multiple application payloads is
one of the faulting architecture: what do you do if buying stock
A succeeds, selling stock B fails and selling stock C would
succeed if processed after selling B? You can fault at the first
failure or you can want to proceed transactionally - all or none
- or you can accumulate faults.

None of these three ways is suitable for large-enough majority of
applications so that it would be accepted as the way we do it,
moreover all this would complicate the protocol and its
implementation.

 > I think we have to provide trailers, because some users will
 > need them. And I think those trailers will add complexity both to the
 > specification (we can already see it in the thread at [1] discussing
 > about their definition) and to the way messages are processed (senders
 > must be able to add trailers, receivers to access them...).

My opinion is that proposal #1 in [1] is simple enough for the
spec, that it doesn't add substantial complexity for
implementations that don't do streaming, and that it doesn't add
substantial complexity over what the streaming implementations
have to do anyway.

Proposal #2 would move all the trailing data into Attachments,
and I think trailing data is one of the cases in mind of the
creators of the "SOAP w/ Attachments" spec.

 > > But SOAP already know how to address blocks to different
 > > endpoints.
 >
 > I am not sure we agree or disagree on this as we may have
 > different definition for 'endpoints'.
 > So I would rather say that SOAP knows how to send blocks targeted at
 > different handlers located on the same destination node.

My rephrasing would be:
"SOAP knows how to target blocks at different handlers."
They needn't be located on the same node, see intermediaries.

 > > I think that if you want to have several application-level
 > > messages directed to one endpoint and with the same handling on
 > > the part of the SOAP processor, it can easily be viewed as having
 > > one larger application-level message. This message is divided (at
 > > the application level) but the SOAP processor needn't be
 > > concerned with this.
 >
 > I agree that it could be done, but at the cost of more processing
 > at the application level.
 > Whereas if we have blocks, the SOAP processor will have a dispatching
 > mechanism able to direct each block to the right handler. In this way,
 > your application will receive each application-level message
 > separately and will not have to split a larger application-level
 > message into its sub-components.
 > Furthermore, I think it is easier for an application to say 'you can
 > send me StockQuote, StockSell and StockPurchase messages' rather that
 > say 'you can send me StockQuote, StockSell and StockPurchase messages
 > and also StockProcessing messages which can contain any combination
 > of the former ones'.

See before, the point against multiple application payloads is
the faulting model. The point against just having Blocks is
unability to stream since we have agreed that we want to do the
mustUnderstand check before any more processing. More on this
especially in the second last paragraph in [2].

Please understand that I could live with most of the choices here
but I think that if SOAP has some level of complexity built-in,
people won't have to reinvent the wheel everytime they do
something that's mostly one-application-payload-oriented. And if
we keep the ability to do streaming in special cases, that's just
an added plus here.

Jacek

 > Best regards,
 >
 > Hervé.
 >
 > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0084.html
   [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0111.html

Received on Wednesday, 13 June 2001 17:17:56 UTC