You should not assume that the service access point URL could be used to identify or differentiate a service. In many cases, you might use an intermediary or proxy in front of the service, so the client never actually uses the service's actual URL. (In some cases, a client might use the same proxy to access any number of services.) Plus a service might expose multiple ports, each supporting a different binding. And a single URL might support multiple bindings.
So yes, 1- the client can use the same URL to access the new service. You might set up a proxy that handles version control for you. And 2- the URL shouldn't adversely affect the client in any way as long as the service (or its proxy) can handle both versions. Anne On 1/8/07, Bo Xie <[EMAIL PROTECTED]> wrote:
Thanks Anne. It is clear now what I should when the version is backward compatible. When the version is not backward compatible, according you suggestion. We should use new name space. Can you help on the following 1. Should the client use the same URL to access the new service? 2. If the client can use the same URL, what kind of experience he should get? An fault from the server? Is this something Axis2 provide, or it is the service implementation to check and handle? Thanks, -Bo On 1/6/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
