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

9032RE: [soapbuilders] WS-Routing + Endpoint usage

Expand Messages
  • Matt Long
    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/
      >
    • Show all 5 messages in this topic