Loading ...
Sorry, an error occurred while loading the content.
 

Re: [soapbuilders] Processing Headers

Expand Messages
  • Bob Cunnings
    Hello, Yes, it makes sense. I think that I have had too narrow a view of the subject, it seems that the processing model admits of more flexibility than I
    Message 1 of 8 , Nov 13, 2001
      Hello,

      Yes, it makes sense. I think that I have had too narrow a view of the subject, it seems that the processing model admits of more flexibility than I imagined. This is good food for thought, a worthy goal will be to realize as much of this model in the implementation as possible.

      Thanks,

      RC

      > Thank you for this note, which clarifies a lot. On point "b", I do think
      > it is important to focus on what can be seen from outside, in
      > interoperability terms. I think it's hard to pin down what it means "that processing should stop once a fault occurred, for whatever reason". I think all we can say is that there is at most one fault, and we're
      > agreeing on that. Taking transactions as an example again, and making the
      > arbitrary assumption that begin and end transaction are modelled as
      > separate headers. I would think that I can indeed commit or abort after
      > determining that a SOAP fault is to be sent. So, in that sense, I want to
      > be able to process a header after a fault has occurred. Whether all SOAP
      > implementations will be built to make this easy to code is a different
      > question; I don't think the SOAP spec should preclude it.
      >
      > As I said before, the specifications for particular headers can indeed
      > require order in processing; I would think it would be those
      > specifications that could meaningfully determine what processing can
      > happen after either a fault or any other outcome. For example, a spec ofr
      > transaction commit header might indicate certain types of processing not
      > to occur after a commit or abort has occurred. Does this make sense?
      >
      > ------------------------------------------------------------------------
      > Noah Mendelsohn Voice: 1-617-693-4036
      > Lotus Development Corp. Fax: 1-617-693-8676
      > One Rogers Street
      > Cambridge, MA 02142
      > ------------------------------------------------------------------------
      >
      >
      >
      >
      >
      >
      >
      > "Bob Cunnings" <cunnings@...>
      > 11/12/01 06:55 PM
      > Please respond to soapbuilders
      >
      >
      > To: soapbuilders@yahoogroups.com
      > cc: (bcc: Noah Mendelsohn/CAM/Lotus)
      > Subject: Re: [soapbuilders] Processing Headers
      >
      >
      > Hello,
      >
      > Ok, I've always understood that the order of processing for header
      > entries is undefined. Unfortunately, I've thought that the processing of
      > the body did occur at a specified point... (it certainly does in the
      > implementation here, but that is irrelevant) namely *after* all header
      > entries were processed. Thanks for making that clear.
      >
      > More specifically:
      >
      > 1) I was thinking in terms of dispatch at the implementaton level,
      > not application terms. Of course there may be interdependencies
      > between header blocks as part of application design.
      >
      > a) Again, thinking in runtime terms, there will be a definite order to the
      > processing (however unpredictable in advance) that does get realized. In
      > this context, i and i+1 are interpreted as positions in the actual
      > execution order at runtime, not positions in the lexical ordering of the
      > blocks in the message. My point was simply that processing should stop
      > once a fault occurred, for whatever reason. If, as you say, each message
      > may result in only one fault, then isn't the game up at that point? That
      > is, processing of blocks would halt?
      >
      > b) I stand corrected, as mentioned above, I had believed that
      > header processing always precedes body processing.
      >
      > c) ditto.
      >
      > I thought I was sufficiently careful to preface my remarks with the
      > disclaimer that these processing rules were the reflection of the
      > design choices made in just one implementation. I understand the concern
      > that
      > the broader discussion not get hung up on implementation specific
      > processing
      > rules.
      >
      > Thanks!
      >
      > RC
      >
      > Noah M. writes:
      >
      > > As Doug notes, it's very important that you read the latest
      > specification
      > > carefully. See especially [1]. The important thing to realize is that
      > the
      > > only order imposed on processing is to check for all mustUnderstand
      > > failures before doing anything else. Other than that, order of
      > processing
      > > of the various header and body entries targeted to a particular node is
      > > not specified in SOAP itself. Of course, it is specified that you must
      > > "understand" the specification for any header that you process (this is
      > a
      > > formal term: see [2]) and those specifications may indeed say something
      > > about order. For example, the specification for a transaction
      > processing
      > > extension may indicate that the "BeginTransaction" header is to be
      > > processed before any body entries, and that the "CommitTransaction"
      > header
      > > is to be processed after.
      > >
      > > As has been discussed several times recently, it is also possible to
      > > create headers whose only purpose is to determine the order of
      > processing
      > > for other headers. So, for example, if someone wanted to define a
      > header
      > > that means "process all entries in document order as they appear in the
      > > envelope", that is quite possible to do. If you put "mustUnderstand" on
      >
      > > such a header, then you are assured it will be noticed before any real
      > > work is done.
      > >
      > > Note also that the rule about order being undefined applies also to a
      > node
      > > serving in multiple roles (e.g. it recognizes the transactionProcessing
      > > actor and is also the endpoint. There is no rule that says all entries
      > > for one actor first, then others. There is certainly no rule that says
      > to
      > > process in document order.
      > >
      > > Bob Cunnings writes:
      > >
      > > >> Hi Matt,
      > > >>
      > > >> My interpretations inline... please bear in mind that these
      > > >> positions reflect my interpretation of the spec only, and
      > > >> reflect the processing rules used by the implementation here (White
      > > Mesa).
      > > >>
      > > >>
      > > >> > All,
      > > >> >
      > > >> > To discuss headers a bit, I'd like some comments/opinions on the
      > > following
      > > >> > subject matter.
      > > >> >
      > > >> > 1) Each header is an independent unit of work.
      > > >>
      > > >> Yes.
      > > Not necessarily. To find out whether headers are independent, you must
      > > read their specifications, which your SOAP node is obligated to
      > > "understand" [2] before processing them. It is easy to come up with
      > > important examples where one header entry would modify or interact with
      > > the behavior of others. Even the transaction example above can easily
      > > modify the behavior of other headers (which may have to participate in
      > the
      > > transaction) or the body. Soap supports these cases.
      > >
      > > >>
      > > >> > a) a fault created by header i, does not mean to not process header
      > i
      > > + 1
      > > >>
      > > >> False. If processing of a header results in a fault,
      > > >> no further processing of headers occurs, and a fault
      > > >> message is returned to the client immediately. It
      > > >> would be unsafe to proceed since some subsequent
      > > >> header entry might depend on successful handling
      > > >> of an antecedent to work properly.
      > > >>
      > > I'm sorry, but I disagree. Since the order of processing of header
      > > entries is undefined, it's quite possible that headers following the one
      >
      > > causing a fault, or the body itself can be processed before the header
      > > causing a fault. It is also possible that certain faults result from
      > > combinations of headers (e.g. I can't do CommitTransaction if
      > > BeginTransaction doesn't appear.) It is true, I believe, that a given
      > > soap message can result in at most one fault.
      > >
      > > >> > b) a fault created by header i, does not mean to not process body
      > > block
      > > >>
      > > >> False. A counterexample is in order here... the case
      > > >> of authentication header processing. I definitely do
      > > >> *not* want the body processed if the authentication
      > > >> mechanism (implemented as an extension, i.e. header) fails!
      > > >>
      > > Again I disagree. Order of processing is not defined in general. If
      > you
      > > want your authentication example to work, then either the specification
      > > for the authentication header, or for some other mustUnderstand header,
      > > must require that the authentication header indeed be processed before
      > the
      > > body. Then you do know, and your use case can be met.
      > >
      > > >> > c) a fault created by header i and a processed body block should
      > > return a
      > > >> > soap:header with header fault and the processed soap:body
      > > >> > block (this would
      > > >> > imply a fault in soap:body if the body block faulted or a results
      > of
      > > a
      > > >> > processed soap:body block)
      > > >>
      > > >> Well, the way it works here, a header fault results
      > > >> in *no* body processing, but *should* result in a soap
      > > >> header entry which carries fault details. The aplication
      > > >> may be designed, of course, so that a simple fault message
      > > >> is returned, devoid of details (in the form of a specific
      > > >> header entry). This would be analogous to the case in which
      > > >> body processing results in a fault, but no details are
      > > >> placed in the fault message.
      > > >>
      > > >> My position is that at whatever point in the SOAP processing
      > > >> model a fault is generated, processing halts and the resulting
      > > >> SOAP Fault message is returned to the sender immediately.
      > > >> This, I think, has the virtues of both safety and simplicity.
      > > >>
      > > >> RC
      > >
      > > I think my feelings on us have been made clear by the comments above. I
      >
      > > do expect that some headers will be invented and widely deployed to
      > > provide useful constraints on the order of processing. One to require
      > > document order would be sensible for certain purposes, but too
      > restrictive
      > > in other important cases. In any case, I think it's very important to
      > > have this discussion in the context of what the specification actually
      > > says, and not to have every implementation take its own view. I know
      > that
      > > there have been changes from 1.1 to the 1.2 draft, but the latter is
      > > fairly clear on what is and is not ordered. Thank you.
      > >
      > > [1] http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383605
      > > [2] http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383604
      > >
      > > Noah Mendelsohn
      > >
      > > -----------------------------------------------------------------
      > > This group is a forum for builders of SOAP implementations to discuss
      > implementation and interoperability issues. Please stay on-topic.
      > >
      > > To unsubscribe from this group, send an email to:
      > > soapbuilders-unsubscribe@yahoogroups.com
      > >
      > >
      > >
      > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      > >
      >
      >
      >
      >
      > -----------------------------------------------------------------
      > This group is a forum for builders of SOAP implementations to discuss
      > implementation and interoperability issues. Please stay on-topic.
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
      >
      >
      >
      >
      > -----------------------------------------------------------------
      > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.