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

Re: [soapbuilders] Multiple WS-Addresses in multiple namespaces

Expand Messages
  • Glen Daniels
    Hi Steve: ... I agree, and I would suggest that feedback/errata be offered to the WSA working group. I haven t had time to scan the archives, but I m sure
    Message 1 of 14 , Feb 1, 2007
    • 0 Attachment
      Hi Steve:

      Steve Loughran wrote:
      > > The SOAP spec itself can't (and arguably shouldn't) handle this kind
      > > of thing itself.
      >
      > Well, then -why didnt WS-A to have some guidelines for the problem.
      >
      > Given that the WS-RF 1.0 spec depends on two different drafts of WS-A,
      > surely it should have been obvious that there were going to be legacy
      > addresses out there.

      I agree, and I would suggest that feedback/errata be offered to the WSA
      working group. I haven't had time to scan the archives, but I'm sure
      this came up during the course of the WG discussions (not that you'd
      know it by reading the specs). It would be nice to see some mention of
      how to deal with multiple versions in there.

      > Life is so much simpler with URLs. You cannot post a request to three
      > different URLs, and if you use the element in the message body to
      > select your action, its inherently impossible to hae duplicate
      > payloads.

      I don't think this is a particularly valid comparison. It would be more
      like adding multiple versioned HTTP headers rather than posting to
      different URLs. The point of SOAP headers is that they modify, not
      replace, the (potentially non-extensible) content of a message.

      --Glen
    • Steve Loughran
      ... well, I shall modify my servlet engine to support multiple Host fields in the get request to make its http layer more consistent :)
      Message 2 of 14 , Feb 1, 2007
      • 0 Attachment
        On 2/1/07, Glen Daniels <glen@...> wrote:
        >
        > > Life is so much simpler with URLs. You cannot post a request to three
        > > different URLs, and if you use the element in the message body to
        > > select your action, its inherently impossible to hae duplicate
        > > payloads.
        >
        > I don't think this is a particularly valid comparison. It would be more
        > like adding multiple versioned HTTP headers rather than posting to
        > different URLs. The point of SOAP headers is that they modify, not
        > replace, the (potentially non-extensible) content of a message.
        >

        well, I shall modify my servlet engine to support multiple Host fields
        in the get request to make its http layer more consistent :)
      • noah_mendelsohn@us.ibm.com
        ... One of my great regrets about the SOAP Recommendation is that it does not make crystal clear an aspect of the design that I considered to be very
        Message 3 of 14 , Feb 6, 2007
        • 0 Attachment
          Paul Downey writes:

          > I raised this very issue in my position paper [1] to the W3C Workshop
          > on Enterprise computing, and see it as a fundamental consequence
          > of SOAP not having a "stack", but a "bag" (actually a graph with WSS)
          > which requires meta-data such as the much trumpeted WS-Policy to
          > unravel.

          One of my great regrets about the SOAP Recommendation is that it does not
          make crystal clear an aspect of the design that I considered to be very
          important. Still, the crucial function is there IMO:

          First of all, it's not true that what SOAP has is a "bag"; the header
          elements are siblings in an envelope Infoset, and the Infoset is ordered.
          Also, headers may have interacting semantics [1] :

          "Mandatory SOAP header blocks are presumed to somehow modify the semantics
          of other SOAP header blocks or SOAP body elements."

          Furthermore, and this is crucial, while SOAP itself mandates no fixed
          order when processing, headers can be defined to control the order [1]:

          "The processing of one or more SOAP header blocks MAY control or determine
          the order of processing for other SOAP header blocks and/or the SOAP body.
          For example, one could create a SOAP header block to force processing of
          other SOAP header blocks in lexical order. In the absence of such a
          controlling SOAP header block, the order of header and body processing is
          at the discretion of the SOAP node. Header blocks MAY be processed in
          arbitrary order. Header block processing MAY precede, MAY be interleaved
          with, or MAY follow processing of the SOAP body. For example, processing
          of a "begin transaction" header block would typically precede body
          processing, a "logging" function might run concurrently with body
          processing and a "commit transaction" header block might be honored
          following completion of all other work."

          This is not an accident. It's why we require that all mustUnderstand
          checking be done before any other work. That's what ensures you that if
          you have an mU header that says "do the headers in reverse order" or
          "alphabetical order" or more likely "do signatures first" then that
          header or those headers will necessarily be checked in time to determine
          an order.

          Furthermore, and this is the part I really wish had been highlighted a bit
          more, nothing says these must be separate headers. So, IMO, if you want
          to say >in the specification for wsa:To< "if there are multiple wsa:To
          headers, here's the rule for how to process them all in the presence of
          the others", you can do so. If they are marked mU then you can be sure
          that, at least per the SOAP spec, their specifications can conspire to
          determine an order.

          In fact, what I really wanted to see in the recommendation would be a
          statement along the lines of: "The specifications for headers that may
          coexist in a SOAP message must collectively describe the correct
          interpretation of the headers in combination as well as in isolation.
          Thus, specifications may be written for families of headers designed to be
          used together, to determine operation in the case where multiple instances
          of the same header appear etc. Such specifications may call for a given
          header to be "understood" only when accompanied or only if not accompanied
          by certain other headers. etc."

          I think that is in fact implicit in what is there, but obviously many
          users have missed it. Whether the typical stacks out there provide much
          help in supporting such combined interpretation and ordering is a
          different question, but the spec definitely anticipates it IMO.

          Noah

          [1] http://www.w3.org/TR/soap12-part1/#muprocessing
          [2] http://www.w3.org/TR/soap12-part1/#procsoapmsgs
          --------------------------------------
          Noah Mendelsohn
          IBM Corporation
          One Rogers Street
          Cambridge, MA 02142
          1-617-693-4036
          --------------------------------------
        • Steve Loughran
          On 2/7/07, noah_mendelsohn@us.ibm.com wrote: . ... aah. Soap1.2. Soap 1.1 says nothing about where the headers are validated,
          Message 4 of 14 , Feb 8, 2007
          • 0 Attachment
            On 2/7/07, noah_mendelsohn@... <noah_mendelsohn@...> wrote:
            ."
            >
            > Furthermore, and this is crucial, while SOAP itself mandates no fixed
            > order when processing, headers can be defined to control the order [1]:
            >
            > "The processing of one or more SOAP header blocks MAY control or determine
            > the order of processing for other SOAP header blocks and/or the SOAP body.
            > For example, one could create a SOAP header block to force processing of
            > other SOAP header blocks in lexical order. In the absence of such a
            > controlling SOAP header block, the order of header and body processing is
            > at the discretion of the SOAP node. Header blocks MAY be processed in
            > arbitrary order. Header block processing MAY precede, MAY be interleaved
            > with, or MAY follow processing of the SOAP body. For example, processing
            > of a "begin transaction" header block would typically precede body
            > processing, a "logging" function might run concurrently with body
            > processing and a "commit transaction" header block might be honored
            > following completion of all other work."
            >
            > This is not an accident. It's why we require that all mustUnderstand
            > checking be done before any other work. That's what ensures you that if
            > you have an mU header that says "do the headers in reverse order" or
            > "alphabetical order" or more likely "do signatures first" then that
            > header or those headers will necessarily be checked in time to determine
            > an order.
            >

            aah. Soap1.2. Soap 1.1 says nothing about where the headers are
            validated, only that they must be validated

            "A env:mustUnderstand value of "true" means that the SOAP node must
            process the header with the semantics described in that header's
            specification, or else generate a SOAP fault. Processing the header
            appropriately may include removing the header from any generated SOAP
            message, reinserting the header with the same or altered value, or
            inserting a new header. The inability to process a mandatory header
            requires that all further processing of the SOAP message cease, and a
            SOAP fault be generated. The message is not forwarded any further."

            This is why the release of Axis (1.0?) that didnt do mU checking until
            after the message had been handled was within the spirit of the spec,
            and not the law.

            SOAP1.2 implies that I must check all mu headers before having any
            side effect at all. hmm. My current stack lets you declare handlers in
            a chain, as axis has done forever, and sun's stack has done since last
            week:

            AddressedEchoEndpoint extends AlpineEndpoint {
            name "wsa-echo";
            handlers [
            LogCurrentMessageHandler:classname,
            AddressHandler:classname,
            MustUnderstandChecker:classname,
            EchoHandler:classname,
            LogCurrentMessageHandler:classname
            ];
            }

            There's no way with this chain-of-resposibility design to do advance
            checking of handling, or guarantee that there are no side effects (I
            log the message -is that a side effect?), before the message is handed
            for processing.

            I suppose I could modify the handler interface to add an extra method
            in which every handler indicates if it will process a specific mU
            header. But if every handler is empowered to transform the incoming
            message during its work phase, things get complex. You need to create
            a provisionally transformed doc (transform, without side effects) just
            to make sure the mu headers get processed right.

            Or I ignore that part of the spec on the grounds that its pretty much
            impossible for interop tests to catch and retain my existing
            SOAP1.1-compatible mU processing algorithm.

            > Furthermore, and this is the part I really wish had been highlighted a bit
            > more, nothing says these must be separate headers. So, IMO, if you want
            > to say >in the specification for wsa:To< "if there are multiple wsa:To
            > headers, here's the rule for how to process them all in the presence of
            > the others", you can do so. If they are marked mU then you can be sure
            > that, at least per the SOAP spec, their specifications can conspire to
            > determine an order.
            >

            well, its a shame they dont.

            -steve
          • noah_mendelsohn@us.ibm.com
            ... Well, my reading of the ws-i basic profile is that it says the same thing regarding SOAP 1.1 [1]: R1025 A RECEIVER MUST handle messages in such a way
            Message 5 of 14 , Feb 8, 2007
            • 0 Attachment
              Steve Loughran writes:

              > On 2/7/07, noah_mendelsohn@...
              > <noah_mendelsohn@...> wrote: ."
              >
              > > Furthermore, and this is crucial, while SOAP
              > > itself mandates no fixed order when processing,
              > > headers can be defined to control the order [1]:
              >
              > > "The processing of one or more SOAP header
              > > blocks MAY control or determine the order of
              > > processing for other SOAP header blocks and/or
              > > the SOAP body. For example, one could create a
              > > SOAP header block to force processing of other
              > > SOAP header blocks in lexical order. In the
              > > absence of such a controlling SOAP header block,
              > > the order of header and body processing is at
              > > the discretion of the SOAP node. Header blocks
              > > MAY be processed in arbitrary order. Header
              > > block processing MAY precede, MAY be interleaved
              > > with, or MAY follow processing of the SOAP
              > > body. For example, processing of a "begin
              > > transaction" header block would typically
              > > precede body processing, a "logging" function
              > > might run concurrently with body processing and
              > > a "commit transaction" header block might be
              > > honored following completion of all other work."
              >
              > > This is not an accident. It's why we require
              > > that all mustUnderstand checking be done before
              > > any other work. That's what ensures you that if
              > > you have an mU header that says "do the headers
              > > in reverse order" or "alphabetical order" or
              > > more likely "do signatures first" then that
              > > header or those headers will necessarily be
              > > checked in time to determine an order.
              > >
              >
              > aah. Soap1.2. Soap 1.1 says nothing about where
              > the headers are validated, only that they must be
              > validated

              Well, my reading of the ws-i basic profile is that it says the same thing
              regarding SOAP 1.1 [1]:

              "R1025 A RECEIVER MUST handle messages in such a way that it appears
              that all checking of mandatory header blocks is performed before any
              actual processing. "

              Like so much in the basic profile, it takes the SOAP 1.2 refinements to
              the processing model, and mandates their use with SOAP 1.1.

              > > "A env:mustUnderstand value of "true" means that
              > > the SOAP node must process the header with the
              > > semantics described in that header's
              > > specification, or else generate a SOAP
              > > fault. Processing the header appropriately may
              > > include removing the header from any generated
              > > SOAP message, reinserting the header with the same
              > > or altered value, or inserting a new header. The
              > > inability to process a mandatory header requires
              > > that all further processing of the SOAP message
              > > cease, and a SOAP fault be generated. The message
              > > is not forwarded any further."
              >
              > This is why the release of Axis (1.0?) that didnt
              > do mU checking until after the message had been
              > handled was within the spirit of the spec, and not
              > the law.
              >
              > SOAP1.2 implies that I must check all mu headers
              > before having any side effect at all. hmm. My
              > current stack lets you declare handlers in a
              > chain, as axis has done forever, and sun's stack
              > has done since last week:

              Well, I'm not sure what to say. The spec is clear that you must inspect
              the headers first, and I think there are defensible reasons for that. I
              believe most of the commercial implementations (not speaking for my
              employer, IBM here) are moving toward a model in which headers are
              buffered so that mU checking can be done and header processing
              appropriately ordered, but the body is not necessarily parsed and
              processed in advance. Thus, the body can be streamed, but not the
              headers.

              > AddressedEchoEndpoint extends AlpineEndpoint {
              > name "wsa-echo";
              > handlers [
              > LogCurrentMessageHandler:classname,
              > AddressHandler:classname,
              > MustUnderstandChecker:classname,
              > EchoHandler:classname,
              > LogCurrentMessageHandler:classname
              > ];
              > }
              >
              > There's no way with this chain-of-resposibility
              > design to do advance checking of handling, or
              > guarantee that there are no side effects (I log
              > the message -is that a side effect?), before the
              > message is handed for processing.
              >
              > I suppose I could modify the handler interface to
              > add an extra method in which every handler
              > indicates if it will process a specific mU
              > header. But if every handler is empowered to
              > transform the incoming message during its work
              > phase, things get complex. You need to create a
              > provisionally transformed doc (transform, without
              > side effects) just to make sure the mu headers get
              > processed right.

              To be precise, headers are empowered to change the interpretation of other
              parts of the message, or to affect whether you can "understand" other
              headers in the message, but NOT to transform the message. In particular,
              I don't see anything that says a header can cause parts of the message to
              be decrypted or decompressed in a manner that would lead to the appearance
              of new headers that were processed as if they were there from the start.

              What I do think is there implicitly for such cases is for the
              specification of a header to say: when I am present, the SOAP processing
              model is to be rerun from the start on a new infoset constructed in the
              following way (e.g. by decrypting parts of the current.) In a given
              single use of the SOAP processing model, the input envelope infoset is
              invariant, but the interpretations of the headers present may interact.
              Indeed, it's crucial that they do. Surely a digital signature header
              affects the semantics of that which is signed, in the sense that if the
              dsig doesn't check, you may want to act as if none of the other headers
              are there (since they may be the result of tampering.) SOAP is designed
              to enable such scenarios, as long as the specification for the header (in
              this case a dsig header) is written properly.

              > Or I ignore that part of the spec on the grounds
              > that its pretty much impossible for interop tests
              > to catch and retain my existing SOAP1.1-compatible
              > mU processing algorithm.

              Whether you wish your implementation to expose that full power is up to
              you. HOWEVER, if you do not, then the only conforming response is for you
              to act as if you do not in fact "understand" any headers that might
              conceivably have such interacting semantics that you can't handle. So,
              unless you know that a header doesn't affect others, then if it's mU
              you'll either have to mU fault or be nonconforming to ws-i basic profile
              and/or SOAP 1.2.


              > > Furthermore, and this is the part I really wish
              > > had been highlighted a bit more, nothing says
              > > these must be separate headers. So, IMO, if you
              > > want to say >in the specification for wsa:To<
              > > "if there are multiple wsa:To headers, here's
              > > the rule for how to process them all in the
              > > presence of the others", you can do so. If they
              > > are marked mU then you can be sure that, at
              > > least per the SOAP spec, their specifications
              > > can conspire to determine an order.
              > >
              >
              > well, its a shame they dont.

              Yes, well, I have many concerns about how the higher level WS* specs were
              written, and whether they took sufficient care to use SOAP's details
              properly. I'm sorry that's in fact causing you trouble.

              > -steve
              >

              Noah

              [1]
              http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16468312



              --------------------------------------
              Noah Mendelsohn
              IBM Corporation
              One Rogers Street
              Cambridge, MA 02142
              1-617-693-4036
              --------------------------------------
            • Steve Loughran
              ... Sometimes I suspect complexity is the underlying problem. Like WSDL. Its almost impossible for humans to write, so what you get is a mess, compared to,
              Message 6 of 14 , Feb 8, 2007
              • 0 Attachment
                On 2/8/07, noah_mendelsohn@... <noah_mendelsohn@...> wrote:
                > Steve Loughran writes:
                >
                > > On 2/7/07, noah_mendelsohn@...
                > > <noah_mendelsohn@...> wrote: ."
                >
                >
                > > > Furthermore, and this is the part I really wish
                > > > had been highlighted a bit more, nothing says
                > > > these must be separate headers. So, IMO, if you
                > > > want to say >in the specification for wsa:To<
                > > > "if there are multiple wsa:To headers, here's
                > > > the rule for how to process them all in the
                > > > presence of the others", you can do so. If they
                > > > are marked mU then you can be sure that, at
                > > > least per the SOAP spec, their specifications
                > > > can conspire to determine an order.
                > > >
                > >
                > > well, its a shame they dont.
                >
                > Yes, well, I have many concerns about how the higher level WS* specs were
                > written, and whether they took sufficient care to use SOAP's details
                > properly. I'm sorry that's in fact causing you trouble.
                >

                Sometimes I suspect complexity is the underlying problem. Like WSDL.
                Its almost impossible for humans to write, so what you get is a mess,
                compared to, say, COM IDL interfaces.

                As for the higher order specs, well, I relish their inconsistency,
                epecially WSRF, that has explicit dependencies on two different draft
                WSA versions, and punts on the whole problem of whether not bulk
                attribute read/write operations are atomic or not.

                But that's an OASIS problem so I won't be giving my local TAG
                representative a hard time, about it, or you. Liked your W3C
                submission to the web of enterprisey services; interesting contrast to
                the IBM 'we want a single stack' story.

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