Today there is no standard way to do a redirect that all (or even most) WS clients will understand. Some tools will follow a HTTP redirect, some will not. At one point I had hopes that WS-Addressing would enable this kind of functionality, but I think they decided this kind of scenario was out of scope for WS-A.
Cheers Simon -----Original Message----- From: Jarmo Doc [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 1:22 PM To: [email protected] Subject: WS design question, redirection A design question: I plan to have 3 instances of my web service, each logically residing in a different resource domain and none of which has direct access to the resources in the other 2 domains. Clients can connect to any of the 3 domains and get the majority of the information that they need. Sometimes, however, a client will request information about a resource that's not in the local domain and will need to be redirected. What's a good way to handle this? I seem to have two choices: 1. have each web service act as a form of proxy, being a client to the other domains, or 2. redirect the client himself to the other domain (and ideally authorize him and re-issue his original request). Architecturally I prefer option #1 but for performance reasons I need to investigate #2. If this were a regular web server situation, I would probably issue a temporary redirect to the client. What are the best options in the web services world? Presumably 307 redirect is not relevant (and perhaps not even understood by WS clients?) Do I raise a custom exception that indicates to the client where he should redirect himself (and re-authorize himself, and re-issue his request) to or can I somehow automate the whole process (redirect, re-authorize, re-issue request) using SOAP headers? Thanks very much. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
