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

Re: [soapbuilders] A note about mustUnderstand + actor semantics

Expand Messages
  • Andrew Layman
    The model is that a SOAP message contains various headers within a single envelope, each header potentially addressed to a different actor along that message s
    Message 1 of 18 , Apr 4, 2001
    • 0 Attachment
      The model is that a SOAP message contains various headers within a single
      envelope, each header potentially addressed to a different actor along that
      message's route. Each actor will process those headers addressed to it.
      Some of the headers it processes it will "understand" -- that is, the actor
      will have been coded to carry out the intent of the header. Other headers
      it will not have been coded for. Of those in the latter class, the
      mustUnderstand attribute distinguishes whether the proper action is to do
      nothing with the header or to fault the message.

      The metaphor that I find helpful is that a SOAP message is like a sheaf of
      envelopes, each addressed to a different actor, and held together by a
      rubber band. As the sheaf arrives (by some unspecified means) at each
      actor, he opens the envelope and finds several letters. Some are in a
      language he understands. Some are in a language he does not understand. If
      any of the incomprehensible ones are marked "mustUnderstand" he Faults the
      message.

      Regarding the scenario below in which the message contains an important
      header addressed to an intermediate actor, yet the message somehow never
      went to the intermediate actor, this is a problem. But it is not a problem
      in the actor model, it is a failure of message routing and should be
      addressed at that level.

      Applying this to the metaphor above, SOAP 1.1 does not by itself provide a
      routing slip, nor does it provide any tracking or proof-of-delivery
      mechanism. But SOAP does allow these things to be added. That is good use
      of headers.

      There is a lengthier discussion of (optional!) extensions to SOAP at
      http://www.w3.org/2001/03/WSWS-popa/paper51 .


      ----- Original Message -----
      From: "Doug Davis" <dug@...>
      To: <soapbuilders@yahoogroups.com>
      Sent: Wednesday, April 04, 2001 5:29 AM
      Subject: Re: [soapbuilders] A note about mustUnderstand + actor semantics


      I would tend to agree - mustUnderstand should probably
      take precedence. The way I read the spec is that if I
      put a mustUnderstand header in a message that means that
      this header *must* be processed/understood and if its
      not then something will fault and my message will not
      be processed. Simply ignoring the header, to me, is like
      lying about whether the message was fully and properly
      processed. I would think more clients would prefer to
      be told (thru a fault) that the header wasn't going to
      be processed (and they can then choose to remove it the
      next time) than to have it simply ignored and under the
      false impression that it was actually processed.

      -Dug


      "Glen Daniels" <gdaniels@...> on 04/04/2001 12:50:21 AM

      Please respond to soapbuilders@yahoogroups.com

      To: <soapbuilders@yahoogroups.com>
      cc:
      Subject: Re: [soapbuilders] A note about mustUnderstand + actor semantics



      Henrik:

      I can see your point here, and agree wrt the simplicity of the model, but I
      can
      also see a lot more opportunity for problems if we go this route. Imagine
      a
      case where a client has inserted a mustUnderstand header which triggers a
      third-party non-repudiation intermediary to log a request so that legal
      recourse can be taken should problems arise with the service provided by
      the
      ultimate destination of the message. If for some reason this message
      doesn't
      get to the intermediary, or if the header isn't processed and removed,
      ignoring
      it at the endpoint could product some very unfortunate results.

      It's a tricky area - you could just as well say that if you really want
      this
      kind of contract, you should have the service provider involved as well,
      and
      they should fault if they don't see a header from the intermediary directed
      at
      THEM confirming the request logging. But even in this case, the
      intermediary
      should have removed the original header, so perhaps it should still be a
      fault
      if it remains....

      It feels more comfortable to me, although it's slightly more work for the
      ultimate destination, to let mustUnderstand have precedence, although I'm
      sure
      there are edge cases there too.

      What do other folks think? This isn't apparently as cut-and-dried as I
      thought....

      --Glen

      ----- Original Message -----
      From: "Henrik Frystyk Nielsen" <frystyk@...>
      To: <soapbuilders@yahoogroups.com>
      Sent: Tuesday, April 03, 2001 5:58 PM
      Subject: RE: [soapbuilders] A note about mustUnderstand + actor semantics


      >
      > >When a SOAP message moves through a message path, it can
      > >encounter various actors. These actors somehow magically know
      > >if they are the "ultimate destination", or just intermediaries.
      > >
      > >For an intermediary, the processor should deal with all
      > >headers with an appropriate SOAP-ENV:actor attribute (either
      > >your particular URI, or the special "next" actor). Any
      > >headers, even those marked "mustUnderstand='1'", which aren't
      > >addressed to you should simply be ignored.
      > >
      > >At the ultimate destination, however, the spec isn't very
      > >clear on what to do if you receive a "mustUnderstand='1'"
      > >header whose actor is NOT set to you.
      >
      > In some sense it is - if one takes the processing model described in
      > section 2 [1] then it says what any processor has to do:
      >
      > 1. Identify all parts of the SOAP message intended for that application
      > (see section 4.2.2)
      >
      > 2. Verify that all mandatory parts identified in step 1 are supported by
      > the application for this message (see section 4.2.3) and process them
      > accordingly. If this is not the case then discard the message (see
      > section 4.4). The processor MAY ignore optional parts identified in step
      > 1 without affecting the outcome of the processing.
      >
      > 3. If the SOAP application is not the ultimate destination of the
      > message then remove all parts identified in step 1 before forwarding the
      > message.
      >
      > Given this, it is a consistent to say that the ultimate destination
      > should ignore the mustUnderstand when the header entry it is not
      > intended for it.
      >
      > I don't expect the SOAP processor by itself to know whether it is the
      > ultimate destination or not as this is more likely given by some routing
      > mechanism. One could therefore say that it is up to the routing
      > mechanism to ensure that if there are actors then that those are
      > included in the message path.
      >
      > The advantage of this is that the basic processing model is dirt simple
      > and doesn't change regardless of what role (intermediary or ultimate
      > destination) any given SOAP processor takes on.
      >
      > >I believe (and I've heard this from other parties as well)
      > >that the correct thing to do here is produce a mustUnderstand
      > >fault. The rationale is that someone in the message path
      > >inserted a header that MUST be understood for successful
      > >processing - if it didn't get to someone who could understand
      > >it during its flight, that's an error.
      >
      > [1] http://www.w3.org/TR/SOAP/#_Toc478383491
      >
      > Henrik
      >
      >
      >
      > 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/
      >
      >



      Yahoo! Groups Sponsor

      Click Here to Find Software Faster
      Click Here to Find Software Faster

      [IMAGE]



      To unsubscribe from this group, send an email to:
      soapbuilders-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.





      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/
    • Andrew Layman
      One of my paragraphs below is missing a few words I had intended. ;-/ Here is a better version of paragraph two: The metaphor that I find helpful is that a
      Message 2 of 18 , Apr 4, 2001
      • 0 Attachment
        One of my paragraphs below is missing a few words I had intended. ;-/

        Here is a better version of paragraph two:

        The metaphor that I find helpful is that a SOAP message is like a sheaf of
        envelopes, each addressed to a different actor, and held together by a
        rubber band. As the sheaf arrives (by some unspecified means) at each
        actor, he removes from the sheaf the envelope addressed to him, opens it and
        finds several letters inside. Some are in a language he understands. Some
        are in a language he does not understand. If any of the incomprehensible
        ones are marked "mustUnderstand" he faults the message. Else, if all is
        well, he forwards the remaining letters to the next actor (again by some
        unspecified means).

        ----- Original Message -----
        From: "Andrew Layman" <yahoo@...>
        To: <soapbuilders@yahoogroups.com>
        Sent: Wednesday, April 04, 2001 7:58 AM
        Subject: Re: [soapbuilders] A note about mustUnderstand + actor semantics


        The model is that a SOAP message contains various headers within a single
        envelope, each header potentially addressed to a different actor along that
        message's route. Each actor will process those headers addressed to it.
        Some of the headers it processes it will "understand" -- that is, the actor
        will have been coded to carry out the intent of the header. Other headers
        it will not have been coded for. Of those in the latter class, the
        mustUnderstand attribute distinguishes whether the proper action is to do
        nothing with the header or to fault the message.

        The metaphor that I find helpful is that a SOAP message is like a sheaf of
        envelopes, each addressed to a different actor, and held together by a
        rubber band. As the sheaf arrives (by some unspecified means) at each
        actor, he opens the envelope and finds several letters. Some are in a
        language he understands. Some are in a language he does not understand. If
        any of the incomprehensible ones are marked "mustUnderstand" he Faults the
        message.

        Regarding the scenario below in which the message contains an important
        header addressed to an intermediate actor, yet the message somehow never
        went to the intermediate actor, this is a problem. But it is not a problem
        in the actor model, it is a failure of message routing and should be
        addressed at that level.

        Applying this to the metaphor above, SOAP 1.1 does not by itself provide a
        routing slip, nor does it provide any tracking or proof-of-delivery
        mechanism. But SOAP does allow these things to be added. That is good use
        of headers.

        There is a lengthier discussion of (optional!) extensions to SOAP at
        http://www.w3.org/2001/03/WSWS-popa/paper51 .


        ----- Original Message -----
        From: "Doug Davis" <dug@...>
        To: <soapbuilders@yahoogroups.com>
        Sent: Wednesday, April 04, 2001 5:29 AM
        Subject: Re: [soapbuilders] A note about mustUnderstand + actor semantics


        I would tend to agree - mustUnderstand should probably
        take precedence. The way I read the spec is that if I
        put a mustUnderstand header in a message that means that
        this header *must* be processed/understood and if its
        not then something will fault and my message will not
        be processed. Simply ignoring the header, to me, is like
        lying about whether the message was fully and properly
        processed. I would think more clients would prefer to
        be told (thru a fault) that the header wasn't going to
        be processed (and they can then choose to remove it the
        next time) than to have it simply ignored and under the
        false impression that it was actually processed.

        -Dug


        "Glen Daniels" <gdaniels@...> on 04/04/2001 12:50:21 AM

        Please respond to soapbuilders@yahoogroups.com

        To: <soapbuilders@yahoogroups.com>
        cc:
        Subject: Re: [soapbuilders] A note about mustUnderstand + actor semantics



        Henrik:

        I can see your point here, and agree wrt the simplicity of the model, but I
        can
        also see a lot more opportunity for problems if we go this route. Imagine
        a
        case where a client has inserted a mustUnderstand header which triggers a
        third-party non-repudiation intermediary to log a request so that legal
        recourse can be taken should problems arise with the service provided by
        the
        ultimate destination of the message. If for some reason this message
        doesn't
        get to the intermediary, or if the header isn't processed and removed,
        ignoring
        it at the endpoint could product some very unfortunate results.

        It's a tricky area - you could just as well say that if you really want
        this
        kind of contract, you should have the service provider involved as well,
        and
        they should fault if they don't see a header from the intermediary directed
        at
        THEM confirming the request logging. But even in this case, the
        intermediary
        should have removed the original header, so perhaps it should still be a
        fault
        if it remains....

        It feels more comfortable to me, although it's slightly more work for the
        ultimate destination, to let mustUnderstand have precedence, although I'm
        sure
        there are edge cases there too.

        What do other folks think? This isn't apparently as cut-and-dried as I
        thought....

        --Glen

        ----- Original Message -----
        From: "Henrik Frystyk Nielsen" <frystyk@...>
        To: <soapbuilders@yahoogroups.com>
        Sent: Tuesday, April 03, 2001 5:58 PM
        Subject: RE: [soapbuilders] A note about mustUnderstand + actor semantics


        >
        > >When a SOAP message moves through a message path, it can
        > >encounter various actors. These actors somehow magically know
        > >if they are the "ultimate destination", or just intermediaries.
        > >
        > >For an intermediary, the processor should deal with all
        > >headers with an appropriate SOAP-ENV:actor attribute (either
        > >your particular URI, or the special "next" actor). Any
        > >headers, even those marked "mustUnderstand='1'", which aren't
        > >addressed to you should simply be ignored.
        > >
        > >At the ultimate destination, however, the spec isn't very
        > >clear on what to do if you receive a "mustUnderstand='1'"
        > >header whose actor is NOT set to you.
        >
        > In some sense it is - if one takes the processing model described in
        > section 2 [1] then it says what any processor has to do:
        >
        > 1. Identify all parts of the SOAP message intended for that application
        > (see section 4.2.2)
        >
        > 2. Verify that all mandatory parts identified in step 1 are supported by
        > the application for this message (see section 4.2.3) and process them
        > accordingly. If this is not the case then discard the message (see
        > section 4.4). The processor MAY ignore optional parts identified in step
        > 1 without affecting the outcome of the processing.
        >
        > 3. If the SOAP application is not the ultimate destination of the
        > message then remove all parts identified in step 1 before forwarding the
        > message.
        >
        > Given this, it is a consistent to say that the ultimate destination
        > should ignore the mustUnderstand when the header entry it is not
        > intended for it.
        >
        > I don't expect the SOAP processor by itself to know whether it is the
        > ultimate destination or not as this is more likely given by some routing
        > mechanism. One could therefore say that it is up to the routing
        > mechanism to ensure that if there are actors then that those are
        > included in the message path.
        >
        > The advantage of this is that the basic processing model is dirt simple
        > and doesn't change regardless of what role (intermediary or ultimate
        > destination) any given SOAP processor takes on.
        >
        > >I believe (and I've heard this from other parties as well)
        > >that the correct thing to do here is produce a mustUnderstand
        > >fault. The rationale is that someone in the message path
        > >inserted a header that MUST be understood for successful
        > >processing - if it didn't get to someone who could understand
        > >it during its flight, that's an error.
        >
        > [1] http://www.w3.org/TR/SOAP/#_Toc478383491
        >
        > Henrik
        >
        >
        >
        > 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/
        >
        >



        Yahoo! Groups Sponsor

        Click Here to Find Software Faster
        Click Here to Find Software Faster

        [IMAGE]



        To unsubscribe from this group, send an email to:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.





        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/






        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/
      • Paul Kulchenko
        Hi, Glen! I agree with Henrik. Case that you, Glen, describes should be resolved imho on application layer, and even on SOAP layer you may use actor
        Message 3 of 18 , Apr 4, 2001
        • 0 Attachment
          Hi, Glen!

          I agree with Henrik. Case that you, Glen, describes should be
          resolved imho on application layer, and even on SOAP layer you may
          use actor '...../next', so if destination will get it and if header
          is still there failed this request (it won't work if there is more
          than one intermediary). I'd rather take another approach, like keep
          stack of intermediaries in some field with mustUnderstand, so every
          intermediary will take next address from this field and if everything
          is right this stack should be empty for ultimate destination. If
          something is missed, then this header will be presented and
          destination will fail this request. It may work in case of static and
          dynamic route, if intermediary wants to route according his own
          table, just ignore values in this table and pass it to the next
          point.

          Speaking about mustUnderstand, we had similar discussion on DM's list
          and I was convinced that SOAP processor should fail only on headers
          with mustUnderstood that are for him, because logic behind it could
          be pretty complex and I'd rather don't play with it on general SOAP
          level. Only fail if it's for you.

          Best wishes, Paul.

          --- Glen Daniels <gdaniels@...> wrote:
          > Henrik:
          >
          > I can see your point here, and agree wrt the simplicity of the
          > model, but I can
          > also see a lot more opportunity for problems if we go this route.
          > Imagine a
          > case where a client has inserted a mustUnderstand header which
          > triggers a
          > third-party non-repudiation intermediary to log a request so that
          > legal
          > recourse can be taken should problems arise with the service
          > provided by the
          > ultimate destination of the message. If for some reason this
          > message doesn't
          > get to the intermediary, or if the header isn't processed and
          > removed, ignoring
          > it at the endpoint could product some very unfortunate results.
          >
          > It's a tricky area - you could just as well say that if you really
          > want this
          > kind of contract, you should have the service provider involved as
          > well, and
          > they should fault if they don't see a header from the intermediary
          > directed at
          > THEM confirming the request logging. But even in this case, the
          > intermediary
          > should have removed the original header, so perhaps it should still
          > be a fault
          > if it remains....
          >
          > It feels more comfortable to me, although it's slightly more work
          > for the
          > ultimate destination, to let mustUnderstand have precedence,
          > although I'm sure
          > there are edge cases there too.
          >
          > What do other folks think? This isn't apparently as cut-and-dried
          > as I
          > thought....
          >
          > --Glen
          >
          > ----- Original Message -----
          > From: "Henrik Frystyk Nielsen" <frystyk@...>
          > To: <soapbuilders@yahoogroups.com>
          > Sent: Tuesday, April 03, 2001 5:58 PM
          > Subject: RE: [soapbuilders] A note about mustUnderstand + actor
          > semantics
          >
          >
          > >
          > > >When a SOAP message moves through a message path, it can
          > > >encounter various actors. These actors somehow magically know
          > > >if they are the "ultimate destination", or just intermediaries.
          > > >
          > > >For an intermediary, the processor should deal with all
          > > >headers with an appropriate SOAP-ENV:actor attribute (either
          > > >your particular URI, or the special "next" actor). Any
          > > >headers, even those marked "mustUnderstand='1'", which aren't
          > > >addressed to you should simply be ignored.
          > > >
          > > >At the ultimate destination, however, the spec isn't very
          > > >clear on what to do if you receive a "mustUnderstand='1'"
          > > >header whose actor is NOT set to you.
          > >
          > > In some sense it is - if one takes the processing model described
          > in
          > > section 2 [1] then it says what any processor has to do:
          > >
          > > 1. Identify all parts of the SOAP message intended for that
          > application
          > > (see section 4.2.2)
          > >
          > > 2. Verify that all mandatory parts identified in step 1 are
          > supported by
          > > the application for this message (see section 4.2.3) and process
          > them
          > > accordingly. If this is not the case then discard the message
          > (see
          > > section 4.4). The processor MAY ignore optional parts identified
          > in step
          > > 1 without affecting the outcome of the processing.
          > >
          > > 3. If the SOAP application is not the ultimate destination of the
          > > message then remove all parts identified in step 1 before
          > forwarding the
          > > message.
          > >
          > > Given this, it is a consistent to say that the ultimate
          > destination
          > > should ignore the mustUnderstand when the header entry it is not
          > > intended for it.
          > >
          > > I don't expect the SOAP processor by itself to know whether it is
          > the
          > > ultimate destination or not as this is more likely given by some
          > routing
          > > mechanism. One could therefore say that it is up to the routing
          > > mechanism to ensure that if there are actors then that those are
          > > included in the message path.
          > >
          > > The advantage of this is that the basic processing model is dirt
          > simple
          > > and doesn't change regardless of what role (intermediary or
          > ultimate
          > > destination) any given SOAP processor takes on.
          > >
          > > >I believe (and I've heard this from other parties as well)
          > > >that the correct thing to do here is produce a mustUnderstand
          > > >fault. The rationale is that someone in the message path
          > > >inserted a header that MUST be understood for successful
          > > >processing - if it didn't get to someone who could understand
          > > >it during its flight, that's an error.
          > >
          > > [1] http://www.w3.org/TR/SOAP/#_Toc478383491
          > >
          > > Henrik
          > >
          > >
          > >
          > > 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/
          > >
          > >
          >
          >
          > ------------------------ Yahoo! Groups Sponsor
          >
          > 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/
          >
          >


          __________________________________________________
          Do You Yahoo!?
          Get email at your own domain with Yahoo! Mail.
          http://personal.mail.yahoo.com/
        • Henrik Frystyk Nielsen
          ... Yes, but is the ultimate destination really special in this regard or could this not be the case for any SOAP receiver along the way that it might depend
          Message 4 of 18 , Apr 4, 2001
          • 0 Attachment
            >I can see your point here, and agree wrt the simplicity of the
            >model, but I can also see a lot more opportunity for problems
            >if we go this route. Imagine a case where a client has
            >inserted a mustUnderstand header which triggers a third-party
            >non-repudiation intermediary to log a request so that legal
            >recourse can be taken should problems arise with the service
            >provided by the ultimate destination of the message. If for
            >some reason this message doesn't get to the intermediary, or
            >if the header isn't processed and removed, ignoring it at the
            >endpoint could product some very unfortunate results.

            Yes, but is the ultimate destination really special in this regard or
            could this not be the case for any SOAP receiver along the way that it
            might depend on something having already been carried out?

            If the (routing) mechanism for getting the message to the intermediary
            and further on to the ultimate destination is "mustUnderstand" and that
            mechanism doesn't allow for an intermediary to get skipped then we have
            a mechanism for catching this directly. Btw, I talk a bit about what the
            requirements for such a routing mechanism might look like in [1].

            However, if one uses an out-of-band mechanism for routing messages then
            one possibility for dealing with this would be to have another
            mustUnderstand header for the ultimate destination (or some
            intermediary) saying that it should look out for this and that has been
            dealt with.

            The benefit of this is that this would also apply to intermediaries
            which may be in the same position of only accepting a message if
            something has already been carried out.

            Henrik

            [1] http://www.w3.org/2001/03/WSWS-popa/paper41
          • Oisin Hurley
            [deletia] ... Is it fair to say then that the ultimate destination , i.e. the body handler, should assume that all headers that have mustUnderstand=1 have
            Message 5 of 18 , Apr 5, 2001
            • 0 Attachment
              [deletia]
              >Given this, it is a consistent to say that the ultimate destination
              >should ignore the mustUnderstand when the header entry it is not
              >intended for it.

              Is it fair to say then that the ultimate 'destination', i.e. the
              body handler, should assume that all headers that have mustUnderstand=1
              have been successfully processed?

              >I don't expect the SOAP processor by itself to know whether it is the
              >ultimate destination or not as this is more likely given by some routing
              >mechanism. One could therefore say that it is up to the routing
              >mechanism to ensure that if there are actors then that those are
              >included in the message path.
              >
              >The advantage of this is that the basic processing model is dirt simple
              >and doesn't change regardless of what role (intermediary or ultimate
              >destination) any given SOAP processor takes on.

              It also means that there is no standard way to resolve the issue of
              what to do when actors decide to fail silently :) And isn't the
              processor that processes the body element the ultimate destination?

              --oh
            • Oisin Hurley
              ... Well, if the integrity of the message depends on all of the mustUnderstand headers been processed in some fashion then for a oneshot message the
              Message 6 of 18 , Apr 5, 2001
              • 0 Attachment
                >It feels more comfortable to me, although it's slightly more work for the
                >ultimate destination, to let mustUnderstand have precedence,
                >although I'm sure
                >there are edge cases there too.
                >
                >What do other folks think? This isn't apparently as cut-and-dried as I
                >thought....

                Well, if the integrity of the message depends on all of the mustUnderstand
                headers been processed in some fashion then for a oneshot message the
                responsibility to ensure that all of the intermediaries have behaved
                appropriately belongs to the ultimate recipient. In the case of a
                request/response style interaction pattern, the ultimate recipients
                in either direction must do the job.

                If an intermediary fails in its processing, a fault is generated. If
                the intermediary succeeds, then there is no expected behaviour. Should
                the intermediary remove the headers it processes and relay the remainder?
                Or should it remove the headers and replace them with a signed token to
                indicate that it has successfully processed the header? The ultimate
                recipient can then contact the source of each token in the message to
                ensure that they are who they say they are. This intermediary stuff
                gets more interesting as we go along...

                cheers
                --oh
              • Doug Davis
                ... Not necessarily. I can see cases where intermediaries and ultimate destinations both process (or use might be a better term) the body. Imagine taking
                Message 7 of 18 , Apr 5, 2001
                • 0 Attachment
                  >>The advantage of this is that the basic processing model is dirt simple
                  >>and doesn't change regardless of what role (intermediary or ultimate
                  >>destination) any given SOAP processor takes on.
                  >It also means that there is no standard way to resolve the issue of
                  >what to do when actors decide to fail silently :) And isn't the
                  >processor that processes the body element the ultimate destination?

                  Not necessarily. I can see cases where intermediaries and ultimate
                  destinations both process (or "use" might be a better term) the body.
                  Imagine taking the work of a single web service and splitting it
                  across two machines (for some reason) where the 1st one (from a
                  SOAP perspective) is view as an intermediary. Both process/use the
                  body.

                  To me an interesting question is: can there be intermediaries on the
                  outgoing side of the message flow? And if so, can you have headers
                  targeted for those? I'm guessing "no" because SOAP is one-way
                  messaging and those intermediaries might be considered to be on the
                  returning one-way message not on the outgoing one-way message, but
                  is it legal to view the entire message flow as a one-way message to
                  myself where one of the intermediaries is what we would normally
                  call the ultimate destination? If this were legal then I suspect
                  having headers targeted for an intermediary after what we used to
                  call the "ultimate destination" seems perfectly valid.

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