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

Re: Resolution (was: Re: [soapbuilders] Frontier -> iLab matrix in a table)

Expand Messages
  • Rich Salz
    ... SOAP messages are one-way; see the opening sentence of section 2. SOAP has no mechanism for specifying routing; it must be done at the application level.
    Message 1 of 3 , Apr 13, 2001
    • 0 Attachment
      > I disagree. Imagine a case where an application is designed such that an
      > actor is added on the way to the ultimate recipient, for the purpose of
      > triggering some processing on the way *back* to the originator.

      SOAP messages are one-way; see the opening sentence of section 2. SOAP
      has no mechanism for specifying routing; it must be done at the
      application level. (Sad, but true. That's one reason for ebXML and
      XMLProtocol. :)

      /r$
    • Rich Salz
      ... Which means remove it, right? If you don t remove it and it has mustUnderstand, then we ll hit the next case and fault. Or do you remove it iff and only
      Message 2 of 3 , Apr 15, 2001
      • 0 Attachment
        > if (we can process this header (by QName)) {
        > process it

        Which means remove it, right? If you don't remove it and it has
        mustUnderstand, then we'll hit the next case and fault. Or do you
        remove it iff and only if mustUnderstand is there? That seems clunky.
        It also doesn't address the original proposal: "if you see this message
        and you do caching, here's some info for you".

        > } else if ((it's marked mustUnderstand="1") AND
        > (we're the ultimate destination)) {
        > fault (this is the equiv. of Noah's "mustHappen")
        > } else {
        > leave it in the message and continue (either it's optional,
        > or we're not the end of the message path so someone else
        > gets a crack at it)
        > }

        Unfortunately, it still seems obvious to me (based on my text above)
        that the semantics are either insufficiently specified, or
        insufficiently robust, for real use.
        /r$
      • Glen Daniels
        ... I see two cases here. 1) This header has some critical information and must be processed by SOMEONE along the message chain I would think this type of
        Message 3 of 3 , Apr 15, 2001
        • 0 Attachment
          > > if (we can process this header (by QName)) {
          > > process it
          >
          > Which means remove it, right? If you don't remove it and it has
          > mustUnderstand, then we'll hit the next case and fault. Or do you
          > remove it iff and only if mustUnderstand is there? That seems clunky.
          > It also doesn't address the original proposal: "if you see this message
          > and you do caching, here's some info for you".

          I see two cases here.

          1) "This header has some critical information and must be processed by
          SOMEONE along the message chain"

          I would think this type of header would indeed have mustUnderstand set to 1,
          and would be removed after someone (i.e. anyone who understands it)
          processes it. I can't think of a case where you'd leave it in with
          mustUnderstand set unless you required that someone further up the chain had to
          process it as well.

          2) "If you see this message and you do caching, here's some info for you"

          This wouldn't have mustUnderstand set, and whether or not it was removed by
          the caching processor would be up to said processor and the semantics of the
          extension. In either case, it shouldn't matter. If it's removed, then the
          semantics of the extension indicate that only one processor need deal with the
          header in question. If it's not removed, it'll get to the end of the line but
          no fault should be generated even if no one along the way happened to
          understand and process the thing, since it was by definition optional.

          (Note that the model where a node processes the header and doesn't remove it is
          actually just a shorthand optimization for "process it, remove it, and insert
          your own (identical) header afterwards".)

          > > } else if ((it's marked mustUnderstand="1") AND
          > > (we're the ultimate destination)) {
          > > fault (this is the equiv. of Noah's "mustHappen")
          > > } else {
          > > leave it in the message and continue (either it's optional,
          > > or we're not the end of the message path so someone else
          > > gets a crack at it)
          > > }
          >
          > Unfortunately, it still seems obvious to me (based on my text above)
          > that the semantics are either insufficiently specified, or
          > insufficiently robust, for real use.

          Hm - if the above doesn't clear this up, could you give me an example of what
          you're talking about here?

          --Glen
        Your message has been successfully submitted and would be delivered to recipients shortly.