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

RE: [soapbuilders] WS-Routing + Endpoint usage

Expand Messages
  • 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 1 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 2 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.