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

WS-Routing + Endpoint usage

Expand Messages
  • Matt Long
    The WS-Routing specification is a bit confusing (to me) regarding the use of via . What are the hard rules that determine whether use of |
    Message 1 of 5 , Feb 14, 2003
    • 0 Attachment

       

      The WS-Routing specification is a bit confusing (to me) regarding the use of ‘via’. 

      What are the hard rules that determine whether use of <prefix:via/> | <prefix:via>some-URI</prefix:via> when used of http.

       

       

      I see three potential cases of which 1,2 only make sense to me.  Is there any reason to assume that 3 would be possible?

      (1) Endpoint that supports WS-Routing may only be the ultimate destination.

      (2) Endpoint may be a router and never the ultimate destination.

      (3) Endpoint may be the ultimate destination AND a router.

       

      -Matt Long

    • Bob Cunnings
      Matt, I m of the opinion that it s matter of application design. Empty elements placed in a reverse message path are just indicate that a node send the
      Message 2 of 5 , Feb 14, 2003
      • 0 Attachment
        Matt,

        I'm of the opinion that it's matter of application design. Empty <via>
        elements placed in a reverse message path are just indicate that a
        node send the response message back on the same connection
        on which the request was received. This only makes sense for
        protocols that are request/response on a single connection such
        as HTTP, where an implicit WS-Routing reverse path exists. In the
        case of an application taking advantage of the "free" implicit reverse
        path offered by HTTP, the sender and intermediaries in the forward
        path would construct a reverse path like this:

        <rev>
        <via />
        <via />
        <via />
        </rev>

        OTH, even if HTTP is used, the designer may wish the response
        message to flow back to the sender through a series of nodes
        different from that used to propagate the request. In this case the
        intermediary nodes might construct a reverse path like this:

        <rev>
        <via>http://a.com/logger</via>
        <via>http://b.com/monitor</via>
        <via>http://c.com/toll-booth</via>
        </rev>

        When confronted with an explicit reverse path like this the ultimate
        receiver must open an HTTP connection to a.com and use it to
        send along the response. The ultimate receiver would also send an
        HTTP 204 No Content response over the HTTP connection on
        which it received the request message in the first place. This 404
        response would propagate all the way back to the original sender
        while at the same time the response message follows its own path.

        This path:

        <rev>
        <via />
        <via />
        <via>http://foo.com/new-dest</via>
        </rev>

        might be useful if the response needs to flow back through the
        forward path intermediaries but be routed to an ultimate destination
        other than the originator of the request message for processing.

        No matter what, the WS-Routing nodes must obey the message
        path in use, or fault. Since the composition of that path is
        determined by the sender and any intermediary nodes, it seems
        like an application design issue. One constraint seems to be that
        WS-Routing requires that each intermediary make an entry in the
        reverse path or fault, so the reverse path must have the same
        number of nodes as the forward path. Or so it appears to me.

        The base WS-Routing implementation here isn't so flexible... it is
        only capable of inserting implicit path entries (<via/>) into reverse
        message paths, which satisfies what is arguably the most
        common requirement when HTTP is involved. To do otherwise
        requires a specialized WS-Routing header handler derived from the
        generic one.

        The old HP WS-Routing test tool had several tests like this where
        the ultimate receiver being tested was required to send the
        response message along an explicit reverse path. The test involved
        verifying that the message arrived at the listener specified in the
        reverse path, and that a 204 arrived back at the original sender. So
        in a sense I suppose you could think of the ultimate receiver as
        acting as a "router" although it is really just a WS-Routing
        "ultimate receiver" as it is the node which acts as sender of the
        response message.

        RC

        >
        > The WS-Routing specification is a bit confusing (to me) regarding the
        > use of 'via'.
        > What are the hard rules that determine whether use of <prefix:via/> |
        > <prefix:via>some-URI</prefix:via> when used of http.
        >
        >
        > I see three potential cases of which 1,2 only make sense to me. Is
        > there any reason to assume that 3 would be possible?
        > (1) Endpoint that supports WS-Routing may only be the ultimate
        > destination.
        > (2) Endpoint may be a router and never the ultimate destination.
        > (3) Endpoint may be the ultimate destination AND a router.
        >
        > -Matt Long
        >
      • Wes Moulder
        Matt, An empty via means that the path to the next destination is provided by the underlying protocol layer. Take, for instance, HTTP as the underlying
        Message 3 of 5 , Feb 14, 2003
        • 0 Attachment
          Message
          Matt,
          An empty via means that the path to the next destination is provided by the underlying protocol layer.  Take, for instance, HTTP as the underlying protocol layer.  Since HTTP defines messages in terms of request and response, the rev path could define an empty via to say use the http response.  If you want the next intermediary/endpoint to open a new HTTP connection to you, you would instead specify via with a soap actor.  In this case, it would almost certainly be advisable to close the connection upon receipt and confirmation of a valid message by the intermediary (IE it should still be possible to return a fault down the return path if something is wrong with the message (bad routing header, next destination invalid, things like that)).
           
          That being said, the second half of your message makes no sense with regards to the first half (unless you switched topics on me mid stream).  I tend to agree that 1 and 2 are the most immediately useful cases, but I disagree that 3 isn't possible.  (Consider a router that handles protocols other than soap, it may want to route an incoming soap message to a different layer which is not expressible in the routing header.  This would make the intermediary also the routing endpoint.
           
          Hope that is clear enough,
          --Wes
          -----Original Message-----
          From: Matt Long [mailto:mlong@...]
          Sent: Friday, February 14, 2003 10:52 AM
          To: soapbuilders@yahoogroups.com
          Subject: [soapbuilders] WS-Routing <via> + Endpoint usage

           

          The WS-Routing specification is a bit confusing (to me) regarding the use of ‘via’. 

          What are the hard rules that determine whether use of <prefix:via/> | <prefix:via>some-URI</prefix:via> when used of http.

           

           

          I see three potential cases of which 1,2 only make sense to me.  Is there any reason to assume that 3 would be possible?

          (1) Endpoint that supports WS-Routing may only be the ultimate destination.

          (2) Endpoint may be a router and never the ultimate destination.

          (3) Endpoint may be the ultimate destination AND a router.

           

          -Matt Long


          -----------------------------------------------------------------
          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 the Yahoo! Terms of Service.
        • Matt Long
          Thanks Bob, Ok, that s pretty clear. Is this inline with regard to http? ... //fwd/via | (1) EXPLICIT | copy of (3) ... //rev/via | (3) IMPLICIT
          Message 4 of 5 , Feb 14, 2003
          • 0 Attachment
            Thanks Bob,

            Ok, that's pretty clear. Is this inline with regard to http?

            ----------------------------------------------------
            | forward path | reverse path
            ----------------------------------------------------
            //fwd/via | (1) EXPLICIT | copy of (3)
            ----------------------------------------------------
            //rev/via | (3) IMPLICIT | EXPLICIT
            ----------------------------------------------------

            *** with exception that last //rev/via element in forward path
            may be EXPLICIT which would indicate an async response to the
            initial sender at the explicit uri.


            Much thanks,

            -Matt







            > -----Original Message-----
            > From: Bob Cunnings [mailto:cunnings@...]
            > Sent: Friday, February 14, 2003 12:47 PM
            > To: soapbuilders@yahoogroups.com
            > Subject: Re: [soapbuilders] WS-Routing <via> + Endpoint usage
            >
            > Matt,
            >
            > I'm of the opinion that it's matter of application design. Empty <via>
            > elements placed in a reverse message path are just indicate that a
            > node send the response message back on the same connection
            > on which the request was received. This only makes sense for
            > protocols that are request/response on a single connection such
            > as HTTP, where an implicit WS-Routing reverse path exists. In the
            > case of an application taking advantage of the "free" implicit reverse
            > path offered by HTTP, the sender and intermediaries in the forward
            > path would construct a reverse path like this:
            >
            > <rev>
            > <via />
            > <via />
            > <via />
            > </rev>
            >
            > OTH, even if HTTP is used, the designer may wish the response
            > message to flow back to the sender through a series of nodes
            > different from that used to propagate the request. In this case the
            > intermediary nodes might construct a reverse path like this:
            >
            > <rev>
            > <via>http://a.com/logger</via>
            > <via>http://b.com/monitor</via>
            > <via>http://c.com/toll-booth</via>
            > </rev>
            >
            > When confronted with an explicit reverse path like this the ultimate
            > receiver must open an HTTP connection to a.com and use it to
            > send along the response. The ultimate receiver would also send an
            > HTTP 204 No Content response over the HTTP connection on
            > which it received the request message in the first place. This 404
            > response would propagate all the way back to the original sender
            > while at the same time the response message follows its own path.
            >
            > This path:
            >
            > <rev>
            > <via />
            > <via />
            > <via>http://foo.com/new-dest</via>
            > </rev>
            >
            > might be useful if the response needs to flow back through the
            > forward path intermediaries but be routed to an ultimate destination
            > other than the originator of the request message for processing.
            >
            > No matter what, the WS-Routing nodes must obey the message
            > path in use, or fault. Since the composition of that path is
            > determined by the sender and any intermediary nodes, it seems
            > like an application design issue. One constraint seems to be that
            > WS-Routing requires that each intermediary make an entry in the
            > reverse path or fault, so the reverse path must have the same
            > number of nodes as the forward path. Or so it appears to me.
            >
            > The base WS-Routing implementation here isn't so flexible... it is
            > only capable of inserting implicit path entries (<via/>) into reverse
            > message paths, which satisfies what is arguably the most
            > common requirement when HTTP is involved. To do otherwise
            > requires a specialized WS-Routing header handler derived from the
            > generic one.
            >
            > The old HP WS-Routing test tool had several tests like this where
            > the ultimate receiver being tested was required to send the
            > response message along an explicit reverse path. The test involved
            > verifying that the message arrived at the listener specified in the
            > reverse path, and that a 204 arrived back at the original sender. So
            > in a sense I suppose you could think of the ultimate receiver as
            > acting as a "router" although it is really just a WS-Routing
            > "ultimate receiver" as it is the node which acts as sender of the
            > response message.
            >
            > RC
            >
            > >
            > > The WS-Routing specification is a bit confusing (to me) regarding
            the
            > > use of 'via'.
            > > What are the hard rules that determine whether use of <prefix:via/>
            |
            > > <prefix:via>some-URI</prefix:via> when used of http.
            > >
            > >
            > > I see three potential cases of which 1,2 only make sense to me. Is
            > > there any reason to assume that 3 would be possible?
            > > (1) Endpoint that supports WS-Routing may only be the ultimate
            > > destination.
            > > (2) Endpoint may be a router and never the ultimate destination.
            > > (3) Endpoint may be the ultimate destination AND a router.
            > >
            > > -Matt Long
            > >
            >
            >
            >
            > ------------------------ Yahoo! Groups Sponsor
            >
            > -----------------------------------------------------------------
            > 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/
            >
          • Matt Long
            Wes, The point to me is that WS-Routing is neither asynchronous or synchronous in nature and does not prevent the coexistence of async and sync interaction
            Message 5 of 5 , Feb 14, 2003
            • 0 Attachment
              Message

              Wes,

               

              The point to me is that WS-Routing is neither asynchronous or synchronous in nature and does not prevent the coexistence of async and sync interaction along the message path.  I doubt that few if any WS-R routers actually handle this type of marriage.

               

              If any explicit URI is contained  in //rev/via along the forward message path, it indicates to me that the reverse path is not ‘different’ rather it is asynchronous at this explicit uri.  This would indicate that an http enabled WS-R router must handle both async and sync requests and responses in combination, e.g., receive an async request, send a sync request-response, then respond async along the reverse message path.   My not sure that this is “state-of-the-art” yet.

               

              -Matt

               

              -----Original Message-----
              From: Wes Moulder [mailto:wes@...]
              Sent: Friday, February 14, 2003 12:57 PM
              To: soapbuilders@yahoogroups.com
              Subject: RE: [soapbuilders] WS-Routing <via> + Endpoint usage

               

              Matt,

              An empty via means that the path to the next destination is provided by the underlying protocol layer.  Take, for instance, HTTP as the underlying protocol layer.  Since HTTP defines messages in terms of request and response, the rev path could define an empty via to say use the http response.  If you want the next intermediary/endpoint to open a new HTTP connection to you, you would instead specify via with a soap actor.  In this case, it would almost certainly be advisable to close the connection upon receipt and confirmation of a valid message by the intermediary (IE it should still be possible to return a fault down the return path if something is wrong with the message (bad routing header, next destination invalid, things like that)).

               

              That being said, the second half of your message makes no sense with regards to the first half (unless you switched topics on me mid stream).  I tend to agree that 1 and 2 are the most immediately useful cases, but I disagree that 3 isn't possible.  (Consider a router that handles protocols other than soap, it may want to route an incoming soap message to a different layer which is not expressible in the routing header.  This would make the intermediary also the routing endpoint.

               

              Hope that is clear enough,

              --Wes

              -----Original Message-----
              From: Matt Long [mailto:mlong@...]
              Sent: Friday, February 14, 2003 10:52 AM
              To: soapbuilders@yahoogroups.com
              Subject: [soapbuilders] WS-Routing <via> + Endpoint usage

               

              The WS-Routing specification is a bit confusing (to me) regarding the use of ‘via’. 

              What are the hard rules that determine whether use of <prefix:via/> | <prefix:via>some-URI</prefix:via> when used of http.

               

               

              I see three potential cases of which 1,2 only make sense to me.  Is there any reason to assume that 3 would be possible?

              (1) Endpoint that supports WS-Routing may only be the ultimate destination.

              (2) Endpoint may be a router and never the ultimate destination.

              (3) Endpoint may be the ultimate destination AND a router.

               

              -Matt Long


              -----------------------------------------------------------------
              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 the Yahoo! Terms of Service.


              -----------------------------------------------------------------
              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 the Yahoo! Terms of Service.

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