Only if there is some way to distinguish the messages based on content. The systems are loosely coupled. The only information available to the service is the information conveyed in the message. If you can't distinguish the versions based on the message, there's no way to determine the version of the client.
You could force a differentiation by including a version id in either the header or the body, but if the systems truly are compatible, then it seems inappropriate to impose that kind of system information on the client. Anne On 1/6/07, Bo Xie <[EMAIL PROTECTED]> wrote:
Thanks Ann. In the case where the updated version is backward compatible, but I still want to know the version level the client is at, what's the best way of doing that, does the framework itself provide any support? Thanks, -Bo On 1/6/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > If the message formats for the messages are incompatible, then you > should change the namespace of the top-level message element between > versions. > > Anne > > On 1/6/07, Bo Xie < [EMAIL PROTECTED]> wrote: > > Hi all, > > > > I need some advice on handling client using old WSDL. Say I made some > > change in WSDL and publish a updated service. > > - How can we tell if the client request is based on the old WSDL or new > > WSDL so the service can act accordingly? > > - What's the best practice to deal the client that is still using the old > > WSDL in case the new WSDL is or is not compatible with the old one? > > > > Thanks in advance for your time. > > > > -Bo > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
