- From: Tom Rutt <tom@coastin.com>
- Date: Fri, 26 Nov 2004 11:13:45 -0500
- To: Christopher B Ferris <chrisfer@us.ibm.com>
- CC: Rich Salz <rsalz@datapower.com>, Martin Gudgin <mgudgin@microsoft.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Christopher B Ferris wrote: > >Ok, let's say I have a gateway that serves as the external facing endpoint >for all of my internal services, which are hidden behind a firewall. >I could expose an EPR that has the wsa:Address URI of my external gateway >and include ref prop(s) that are targetted at the soap:role of >http://example.org/gateway which is the role of my Gateway. It knows only >to look for an element <gw:RouteTo> or something like that, of type >xs:anyURI with a >soap:MustUnderstand='true', and forwards the message to that URI, which >could >be an HTTP URI or possibly a URI for a WebSphereMQ queue from which the >service endpoint will dequeue messages to be processed (asynchronously, >of course! It's the only way babe... :-) If the ref props/params are >wrapped, >then somehow the soap:role and soap:mustUnderstand of the ref prop/param >will need to be >propogated to that wrapper element or else this use of ref props/params >doesn't work. > > In your example above, does the gateway reside at the "destination address" of the wsa:to element? If so why cannot the bundled header element (which contains all the ref props and ref parms) be targeted to the gateway as the destination, with soap must understand =1. I do not understand why the gateway cannot be treated as the soap destination, whether it does behind the scenes forwarding or not? Tom Rutt. > > > > > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
Received on Friday, 26 November 2004 16:17:18 UTC