Re: Issue 25 Proposal

Hervé, my comments inside.

                            Jacek Kopecky
                               Idoox



On Tue, 12 Jun 2001, Herve Ruellan wrote:

 > Jacek,
 >
 > My comments are interleaved.
 >
 > Jacek Kopecky wrote:
 > >
 > >  Hi, please see my post re: 'Issue 25 Proposals from the f2f'
 > > first.
 > >
 > >  Christopher, there has been agreement on first checking for mU
 > > faults and only when every header is known to be known to the
 > > processor can the processing begin.
 > >
 > >  I agree that your approach would be a simplification, but only
 > > for those who don't mind mathematical abstractions. Sometimes a
 > > little bit of additional complexity adds a lot to clarity of the
 > > purpose. That's one point for keeping Body separate.
 >
 > Whereas Chris' approach is different and enforce us to readjust
 > our way of thinking about SOAP messages, I don't think it is harder
 > to understand.
 >
 > However, I am afraid that the current state of SOAP with a separate
 > Body may lead us to add much more complexity to solve specific problems
 > created by separation of Headers and Body. In particular, I think that
 > handling trailers will add complexity to this approach.

Please, can you show me the specific problems created by
separation of Headers and Body?

If we disallow XMLP blocks after the Body I think that this
separation divides the message in a meaningful way. In some cases
though we'd like to carry some metadata _after_ the body, if only
in some special cases (the use of trailers should be
discouraged). We won't add XMLP blocks after the body so no more
handling complexity comes in, we just add plain old addressable
data.

 > >  Your simpler approach also completely kills the possibility of
 > > streaming, which is arguably a useful optimization. Why can't you
 > > stream any more? Because you have to see the end tag
 > > (</SOAP:Envelope> in your case) before being sure that you will
 > > understand all the headers - that's because only the ending
 > > SOAP:Envelope tag tells you there is no more SOAP:Block.
 > >
 > >  If we had SOAP:Header, SOAP:Body and SOAP:Trailer (the last
 > > with the same handling rules as the first) with sequential mU
 > > checking and processing, we could encounter a situation where the
 > > body has been processed successfully but then you don't
 > > understand one of the mU trailers.
 > >
 > >  As for why streaming only the Body seems sufficient to me: I
 > > have an opinion and a feeling that headers are going to be used
 > > for relatively small metadata only. Then the body can bear the
 > > bulk of the data and streaming can be more important to you than
 > > knowing beforehand the data is proper XML. If encountering a
 > > parser error mid-stream would cause you a head-ache, you wouldn't
 > > even consider streaming. On the other hand when memory is limited
 > > and where rollback is either simple or unnecessary altogether,
 > > you'll be glad if you know "from now on I can stream if I will".
 >
 > I think that even with the current SOAP specification, there will
 > be may case when streaming will not be allowed. If you have a header
 > containing a digital signature of the body that requires you to check
 > the content of the body, you would have to parse the body while
 > processing this header.

I'm not saying streaming is an everyday thing, but if a simple
separation allows us to do streaming in the special cases where
it would be useful, and if the separation doesn't add
considerable complexity (which IMO this doesn't), I'm all for it.

 > >  Even in messaging environments, where you argue your simpler
 > > approach "might prove quite valuable", I think I have reasons why
 > > Body is special:
 > >
 > >  I'd naturally map one SOAP message to one application-level
 > > message. This application-level message would live in the Body,
 > > possibly decorated with headers.
 > >
 > >  If you kept your simple model with only Blocks, you could easily
 > > start putting more application-level messages into one SOAP
 > > message, then the next simple step is to address these to
 > > different endpoints, and what you end up with is a bus structure
 > > with complex semantics due to its immense flexibility. I wouldn't
 > > like to go there.
 >
 > I think that putting several application-level messages into
 > one SOAP message is very handy. However, I think that addressing them
 > to different endpoints is a very big change to the purpose of SOAP.
 > I don't think we should address this problem in SOAP.

But SOAP already know how to address blocks to different
endpoints.

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.


Jacek

Received on Tuesday, 12 June 2001 04:48:25 UTC