You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Howell, David" <da...@uleth.ca> on 2008/10/21 19:08:40 UTC

Versioning a service deployed on Axis2

Hi,

 

Is there a recommended or commonly used approach to versioning a service
(SOAP, doc/literal) that is to be deployed on Axis2? I'm trying to
provide some means of not breaking consumers of an existing service if I
have to deploy a new version that isn't backwards compatible. We're
using AXIOM / no data binding for the service consumers and producers.

 

In a lot of cases I think I'll just want to move from deploying
MyService_V1.aar to deploying MyService_V2.aar. V1 can stay deployed on
the Axis2 server until the consumers have all moved on to V2. 

 

I've been looking at including version information in the target
namespace specified in the WSDL for the service as a mechanism for
consumers to specify which version of the service they want to use. I'm
struggling to understand what my options are for deploying the old and
new versions of my service. Specifically:

 

- I don't seem to need to deploy MyService_V1 and MyService_V2 on
different endpoint addresses, but

- I assume I do have to give them different names in the <service>
element of the wsdl.

 

Is this correct?

 

Finally, is there any way of using a single endpoint and service name
that accepts requests from consumers that may have different XML
namespaces depending on the version of the service they are using?

 

Thanks,

 

Dave

 


RE: Versioning a service deployed on Axis2

Posted by "Kraus, David" <dk...@MicroStrategy.com>.
Wouldn't it be possible to create a new schema namespace for the next
version of a webservice, and then manage the changes internally in one
web service?

So your first version of the web service might have a schema namespace
of:
<wsdl:types>
    <s:schema elementFormDefault="qualified"
targetNamespace="http://xxx.com/webservices/V1">

.....

The process of creating the next version would involve creating new
versions of each datatype which changes, or API call (if parameter list
changes), and defining these new types, APIs, in a new namespace in the
same WSDL file.

<s:schema elementFormDefault="qualified"
targetNamespace="http://xxx.com/webservices/V2">

So, the V1 schema of your service might define XXXType, and the V2
schema would define an XXXType2 type to represent XXXType with changes.
Your web service would need to handle both.

Obviously, this could get messy over time, but guidelines that manage
the deprecation and removal of support for past versions could be used
to handle that.

-----Original Message-----
From: Deepal jayasinghe [mailto:deepalk@gmail.com] 
Sent: Tuesday, October 21, 2008 4:42 PM
To: axis-user@ws.apache.org
Subject: Re: Versioning a service deployed on Axis2

Barry Alexander wrote:
>
> Other than "you're on your own" advice, can you provide some
> guidelines or best practices regarding versioning?
>
The only way to get the service version support in Axis2 is to deploy
two different services. And then use their service addresses to
differentiate the two services. If we use this way then the service
version will be automatically visible to outside as well. So for example
if you want to have two version of "foo" service , then you need to have
two different aar files in the repository , called (eg.) foo-1.aar and
foo-2.aar, in addition to that remember the service name of the two
services.xml file should also be different. In other word those will be
two different services in Axis2.

If you want to have the client transparent version support then one
solution could be  to write a handler which does the version based
dispatching. Meaning when a client send a request it will send the
request to the latest service.

-Deepal
>
>  
>
> I thought this was an excellent question and currently of hot
> discussion with my co-workers.
>
>  
>
> Some further questions:
>
>  
>
> Should message version be embedded as part of SOAP headers using
> WS-Addressing standards?  Or part of the wsdl?
>
> Can end point resolution be used during in-flow phases/handlers to
> route services of various versions end points?
>
> Should versioning be handled as part of a 'mediator'?
>
>
>
> On Tue, Oct 21, 2008 at 10:12 AM, Deepal jayasinghe <deepalk@gmail.com
> <ma...@gmail.com>> wrote:
>
>     Howell, David wrote:
>     >
>     > Hi,
>     >
>     > Is there a recommended or commonly used approach to versioning a
>     > service (SOAP, doc/literal) that is to be deployed on Axis2? I'm
>     > trying to provide some means of not breaking consumers of an
>     existing
>     > service if I have to deploy a new version that isn't backwards
>     > compatible. We're using AXIOM / no data binding for the service
>     > consumers and producers.
>     >
>     Actually we had some discussion on how to do the version support
in
>     Axis2 (for service) , but we have not implement that. So only
>     option is
>     to manage service yourself.
>     >
>     > In a lot of cases I think I'll just want to move from deploying
>     > MyService_V1.aar to deploying MyService_V2.aar. V1 can stay
deployed
>     > on the Axis2 server until the consumers have all moved on to V2.
>     >
>     > I've been looking at including version information in the target
>     > namespace specified in the WSDL for the service as a mechanism
for
>     > consumers to specify which version of the service they want to
use.
>     > I'm struggling to understand what my options are for deploying
>     the old
>     > and new versions of my service. Specifically:
>     >
>     > - I don't seem to need to deploy MyService_V1 and MyService_V2
on
>     > different endpoint addresses, but
>     >
>     > - I assume I do have to give them different names in the
<service>
>     > element of the wsdl.
>     >
>     > Is this correct?
>     >
>     > Finally, is there any way of using a single endpoint and service
>     name
>     > that accepts requests from consumers that may have different XML
>     > namespaces depending on the version of the service they are
using?
>     >
>     > Thanks,
>     >
>     > Dave
>     >
>
>
>     --
>     Thank you!
>
>
>     http://blogs.deepal.org
>
>
>
---------------------------------------------------------------------
>     To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     For additional commands, e-mail: axis-user-help@ws.apache.org
>     <ma...@ws.apache.org>
>
>


-- 
Thank you!


http://blogs.deepal.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Re: Versioning a service deployed on Axis2

Posted by Barry Alexander <ba...@gmail.com>.
Thanks Deepal, this aligns with our thinking here so good to here your
views.  If you know of any examples out there, I would be interested to see.

On Tue, Oct 21, 2008 at 4:41 PM, Deepal jayasinghe <de...@gmail.com>wrote:

> Barry Alexander wrote:
> >
> > Other than "you're on your own" advice, can you provide some
> > guidelines or best practices regarding versioning?
> >
> The only way to get the service version support in Axis2 is to deploy
> two different services. And then use their service addresses to
> differentiate the two services. If we use this way then the service
> version will be automatically visible to outside as well. So for example
> if you want to have two version of "foo" service , then you need to have
> two different aar files in the repository , called (eg.) foo-1.aar and
> foo-2.aar, in addition to that remember the service name of the two
> services.xml file should also be different. In other word those will be
> two different services in Axis2.
>
> If you want to have the client transparent version support then one
> solution could be  to write a handler which does the version based
> dispatching. Meaning when a client send a request it will send the
> request to the latest service.
>
> -Deepal
> >
> >
> >
> > I thought this was an excellent question and currently of hot
> > discussion with my co-workers.
> >
> >
> >
> > Some further questions:
> >
> >
> >
> > Should message version be embedded as part of SOAP headers using
> > WS-Addressing standards?  Or part of the wsdl?
> >
> > Can end point resolution be used during in-flow phases/handlers to
> > route services of various versions end points?
> >
> > Should versioning be handled as part of a 'mediator'?
> >
> >
> >
> > On Tue, Oct 21, 2008 at 10:12 AM, Deepal jayasinghe <deepalk@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> >     Howell, David wrote:
> >     >
> >     > Hi,
> >     >
> >     > Is there a recommended or commonly used approach to versioning a
> >     > service (SOAP, doc/literal) that is to be deployed on Axis2? I'm
> >     > trying to provide some means of not breaking consumers of an
> >     existing
> >     > service if I have to deploy a new version that isn't backwards
> >     > compatible. We're using AXIOM / no data binding for the service
> >     > consumers and producers.
> >     >
> >     Actually we had some discussion on how to do the version support in
> >     Axis2 (for service) , but we have not implement that. So only
> >     option is
> >     to manage service yourself.
> >     >
> >     > In a lot of cases I think I'll just want to move from deploying
> >     > MyService_V1.aar to deploying MyService_V2.aar. V1 can stay
> deployed
> >     > on the Axis2 server until the consumers have all moved on to V2.
> >     >
> >     > I've been looking at including version information in the target
> >     > namespace specified in the WSDL for the service as a mechanism for
> >     > consumers to specify which version of the service they want to use.
> >     > I'm struggling to understand what my options are for deploying
> >     the old
> >     > and new versions of my service. Specifically:
> >     >
> >     > - I don't seem to need to deploy MyService_V1 and MyService_V2 on
> >     > different endpoint addresses, but
> >     >
> >     > - I assume I do have to give them different names in the <service>
> >     > element of the wsdl.
> >     >
> >     > Is this correct?
> >     >
> >     > Finally, is there any way of using a single endpoint and service
> >     name
> >     > that accepts requests from consumers that may have different XML
> >     > namespaces depending on the version of the service they are using?
> >     >
> >     > Thanks,
> >     >
> >     > Dave
> >     >
> >
> >
> >     --
> >     Thank you!
> >
> >
> >     http://blogs.deepal.org
> >
> >
> >     ---------------------------------------------------------------------
> >     To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >     <ma...@ws.apache.org>
> >     For additional commands, e-mail: axis-user-help@ws.apache.org
> >     <ma...@ws.apache.org>
> >
> >
>
>
> --
> Thank you!
>
>
> http://blogs.deepal.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

Re: Versioning a service deployed on Axis2

Posted by Deepal jayasinghe <de...@gmail.com>.
Barry Alexander wrote:
>
> Other than "you're on your own" advice, can you provide some
> guidelines or best practices regarding versioning?
>
The only way to get the service version support in Axis2 is to deploy
two different services. And then use their service addresses to
differentiate the two services. If we use this way then the service
version will be automatically visible to outside as well. So for example
if you want to have two version of "foo" service , then you need to have
two different aar files in the repository , called (eg.) foo-1.aar and
foo-2.aar, in addition to that remember the service name of the two
services.xml file should also be different. In other word those will be
two different services in Axis2.

If you want to have the client transparent version support then one
solution could be  to write a handler which does the version based
dispatching. Meaning when a client send a request it will send the
request to the latest service.

-Deepal
>
>  
>
> I thought this was an excellent question and currently of hot
> discussion with my co-workers.
>
>  
>
> Some further questions:
>
>  
>
> Should message version be embedded as part of SOAP headers using
> WS-Addressing standards?  Or part of the wsdl?
>
> Can end point resolution be used during in-flow phases/handlers to
> route services of various versions end points?
>
> Should versioning be handled as part of a 'mediator'?
>
>
>
> On Tue, Oct 21, 2008 at 10:12 AM, Deepal jayasinghe <deepalk@gmail.com
> <ma...@gmail.com>> wrote:
>
>     Howell, David wrote:
>     >
>     > Hi,
>     >
>     > Is there a recommended or commonly used approach to versioning a
>     > service (SOAP, doc/literal) that is to be deployed on Axis2? I'm
>     > trying to provide some means of not breaking consumers of an
>     existing
>     > service if I have to deploy a new version that isn't backwards
>     > compatible. We're using AXIOM / no data binding for the service
>     > consumers and producers.
>     >
>     Actually we had some discussion on how to do the version support in
>     Axis2 (for service) , but we have not implement that. So only
>     option is
>     to manage service yourself.
>     >
>     > In a lot of cases I think I'll just want to move from deploying
>     > MyService_V1.aar to deploying MyService_V2.aar. V1 can stay deployed
>     > on the Axis2 server until the consumers have all moved on to V2.
>     >
>     > I've been looking at including version information in the target
>     > namespace specified in the WSDL for the service as a mechanism for
>     > consumers to specify which version of the service they want to use.
>     > I'm struggling to understand what my options are for deploying
>     the old
>     > and new versions of my service. Specifically:
>     >
>     > - I don't seem to need to deploy MyService_V1 and MyService_V2 on
>     > different endpoint addresses, but
>     >
>     > - I assume I do have to give them different names in the <service>
>     > element of the wsdl.
>     >
>     > Is this correct?
>     >
>     > Finally, is there any way of using a single endpoint and service
>     name
>     > that accepts requests from consumers that may have different XML
>     > namespaces depending on the version of the service they are using?
>     >
>     > Thanks,
>     >
>     > Dave
>     >
>
>
>     --
>     Thank you!
>
>
>     http://blogs.deepal.org
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>     <ma...@ws.apache.org>
>     For additional commands, e-mail: axis-user-help@ws.apache.org
>     <ma...@ws.apache.org>
>
>


-- 
Thank you!


http://blogs.deepal.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Re: Versioning a service deployed on Axis2

Posted by Barry Alexander <ba...@gmail.com>.
Thanks Keith, I will give Synapse and WS02 ESB a look.  Your point about
lightweight is key.  We are considering high message volumes and don't want
artifical latency and heft in processing messages.

On Tue, Oct 21, 2008 at 7:32 PM, keith chapman <ke...@gmail.com>wrote:

> Hi Barry,
>
> I'd rather do it in this way. Deploy the two versions of the service as two
> separate services in Axis2. But would front Axis2 with a mediation engine,
> (you could use Apache Synapse or the WSO2 ESB<http://wso2.org/projects/esb/java>[1] which is built on Apache Synapse for this purpose). Synapse allows you
> to create what is called proxy services. So for this purpose I could create
> a proxy service on synapse and give that URL to my customers. Now depending
> on some content in the message (either a targetnamespace or a custom SOAP
> header or a HTTP Header, choice is yours) you could forward your message to
> the correct service. What your essentially doing here is hiding your service
> implementation details using synapse. Now your clients have a single URL to
> talk to.
>
> BTW synapse is lightweight and high has very good performance hence you
> need not worry about a drop in performance in this case.
>
> Thanks,
> Keith.
>
> [1] http://wso2.org/projects/esb/java
>
>
>
> On Tue, Oct 21, 2008 at 11:27 PM, Barry Alexander <
> barry.alexander@gmail.com> wrote:
>
>> Other than "you're on your own" advice, can you provide some guidelines or
>> best practices regarding versioning?
>>
>>
>>
>> I thought this was an excellent question and currently of hot discussion
>> with my co-workers.
>>
>>
>>
>> Some further questions:
>>
>>
>>
>> Should message version be embedded as part of SOAP headers using
>> WS-Addressing standards?  Or part of the wsdl?
>>
>> Can end point resolution be used during in-flow phases/handlers to route
>> services of various versions end points?
>>
>> Should versioning be handled as part of a 'mediator'?
>>
>>
>> On Tue, Oct 21, 2008 at 10:12 AM, Deepal jayasinghe <de...@gmail.com>wrote:
>>
>>> Howell, David wrote:
>>> >
>>> > Hi,
>>> >
>>> > Is there a recommended or commonly used approach to versioning a
>>> > service (SOAP, doc/literal) that is to be deployed on Axis2? I'm
>>> > trying to provide some means of not breaking consumers of an existing
>>> > service if I have to deploy a new version that isn't backwards
>>> > compatible. We're using AXIOM / no data binding for the service
>>> > consumers and producers.
>>> >
>>> Actually we had some discussion on how to do the version support in
>>> Axis2 (for service) , but we have not implement that. So only option is
>>> to manage service yourself.
>>> >
>>> > In a lot of cases I think I'll just want to move from deploying
>>> > MyService_V1.aar to deploying MyService_V2.aar. V1 can stay deployed
>>> > on the Axis2 server until the consumers have all moved on to V2.
>>> >
>>> > I've been looking at including version information in the target
>>> > namespace specified in the WSDL for the service as a mechanism for
>>> > consumers to specify which version of the service they want to use.
>>> > I'm struggling to understand what my options are for deploying the old
>>> > and new versions of my service. Specifically:
>>> >
>>> > - I don't seem to need to deploy MyService_V1 and MyService_V2 on
>>> > different endpoint addresses, but
>>> >
>>> > - I assume I do have to give them different names in the <service>
>>> > element of the wsdl.
>>> >
>>> > Is this correct?
>>> >
>>> > Finally, is there any way of using a single endpoint and service name
>>> > that accepts requests from consumers that may have different XML
>>> > namespaces depending on the version of the service they are using?
>>> >
>>> > Thanks,
>>> >
>>> > Dave
>>> >
>>>
>>>
>>> --
>>> Thank you!
>>>
>>>
>>> http://blogs.deepal.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>>
>>
>
>
> --
> Keith Chapman
> Senior Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://www.keith-chapman.org
>

Re: Versioning a service deployed on Axis2

Posted by keith chapman <ke...@gmail.com>.
Hi Barry,

I'd rather do it in this way. Deploy the two versions of the service as two
separate services in Axis2. But would front Axis2 with a mediation engine,
(you could use Apache Synapse or the WSO2
ESB<http://wso2.org/projects/esb/java>[1] which is built on Apache
Synapse for this purpose). Synapse allows you
to create what is called proxy services. So for this purpose I could create
a proxy service on synapse and give that URL to my customers. Now depending
on some content in the message (either a targetnamespace or a custom SOAP
header or a HTTP Header, choice is yours) you could forward your message to
the correct service. What your essentially doing here is hiding your service
implementation details using synapse. Now your clients have a single URL to
talk to.

BTW synapse is lightweight and high has very good performance hence you need
not worry about a drop in performance in this case.

Thanks,
Keith.

[1] http://wso2.org/projects/esb/java


On Tue, Oct 21, 2008 at 11:27 PM, Barry Alexander <barry.alexander@gmail.com
> wrote:

> Other than "you're on your own" advice, can you provide some guidelines or
> best practices regarding versioning?
>
>
>
> I thought this was an excellent question and currently of hot discussion
> with my co-workers.
>
>
>
> Some further questions:
>
>
>
> Should message version be embedded as part of SOAP headers using
> WS-Addressing standards?  Or part of the wsdl?
>
> Can end point resolution be used during in-flow phases/handlers to route
> services of various versions end points?
>
> Should versioning be handled as part of a 'mediator'?
>
>
> On Tue, Oct 21, 2008 at 10:12 AM, Deepal jayasinghe <de...@gmail.com>wrote:
>
>> Howell, David wrote:
>> >
>> > Hi,
>> >
>> > Is there a recommended or commonly used approach to versioning a
>> > service (SOAP, doc/literal) that is to be deployed on Axis2? I'm
>> > trying to provide some means of not breaking consumers of an existing
>> > service if I have to deploy a new version that isn't backwards
>> > compatible. We're using AXIOM / no data binding for the service
>> > consumers and producers.
>> >
>> Actually we had some discussion on how to do the version support in
>> Axis2 (for service) , but we have not implement that. So only option is
>> to manage service yourself.
>> >
>> > In a lot of cases I think I'll just want to move from deploying
>> > MyService_V1.aar to deploying MyService_V2.aar. V1 can stay deployed
>> > on the Axis2 server until the consumers have all moved on to V2.
>> >
>> > I've been looking at including version information in the target
>> > namespace specified in the WSDL for the service as a mechanism for
>> > consumers to specify which version of the service they want to use.
>> > I'm struggling to understand what my options are for deploying the old
>> > and new versions of my service. Specifically:
>> >
>> > - I don't seem to need to deploy MyService_V1 and MyService_V2 on
>> > different endpoint addresses, but
>> >
>> > - I assume I do have to give them different names in the <service>
>> > element of the wsdl.
>> >
>> > Is this correct?
>> >
>> > Finally, is there any way of using a single endpoint and service name
>> > that accepts requests from consumers that may have different XML
>> > namespaces depending on the version of the service they are using?
>> >
>> > Thanks,
>> >
>> > Dave
>> >
>>
>>
>> --
>> Thank you!
>>
>>
>> http://blogs.deepal.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>


-- 
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/

blog: http://www.keith-chapman.org

Re: Versioning a service deployed on Axis2

Posted by Barry Alexander <ba...@gmail.com>.
Other than "you're on your own" advice, can you provide some guidelines or
best practices regarding versioning?



I thought this was an excellent question and currently of hot discussion
with my co-workers.



Some further questions:



Should message version be embedded as part of SOAP headers using
WS-Addressing standards?  Or part of the wsdl?

Can end point resolution be used during in-flow phases/handlers to route
services of various versions end points?

Should versioning be handled as part of a 'mediator'?


On Tue, Oct 21, 2008 at 10:12 AM, Deepal jayasinghe <de...@gmail.com>wrote:

> Howell, David wrote:
> >
> > Hi,
> >
> > Is there a recommended or commonly used approach to versioning a
> > service (SOAP, doc/literal) that is to be deployed on Axis2? I'm
> > trying to provide some means of not breaking consumers of an existing
> > service if I have to deploy a new version that isn't backwards
> > compatible. We're using AXIOM / no data binding for the service
> > consumers and producers.
> >
> Actually we had some discussion on how to do the version support in
> Axis2 (for service) , but we have not implement that. So only option is
> to manage service yourself.
> >
> > In a lot of cases I think I'll just want to move from deploying
> > MyService_V1.aar to deploying MyService_V2.aar. V1 can stay deployed
> > on the Axis2 server until the consumers have all moved on to V2.
> >
> > I've been looking at including version information in the target
> > namespace specified in the WSDL for the service as a mechanism for
> > consumers to specify which version of the service they want to use.
> > I'm struggling to understand what my options are for deploying the old
> > and new versions of my service. Specifically:
> >
> > - I don't seem to need to deploy MyService_V1 and MyService_V2 on
> > different endpoint addresses, but
> >
> > - I assume I do have to give them different names in the <service>
> > element of the wsdl.
> >
> > Is this correct?
> >
> > Finally, is there any way of using a single endpoint and service name
> > that accepts requests from consumers that may have different XML
> > namespaces depending on the version of the service they are using?
> >
> > Thanks,
> >
> > Dave
> >
>
>
> --
> Thank you!
>
>
> http://blogs.deepal.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

Re: Versioning a service deployed on Axis2

Posted by Deepal jayasinghe <de...@gmail.com>.
Howell, David wrote:
>
> Hi,
>
> Is there a recommended or commonly used approach to versioning a
> service (SOAP, doc/literal) that is to be deployed on Axis2? I’m
> trying to provide some means of not breaking consumers of an existing
> service if I have to deploy a new version that isn’t backwards
> compatible. We’re using AXIOM / no data binding for the service
> consumers and producers.
>
Actually we had some discussion on how to do the version support in
Axis2 (for service) , but we have not implement that. So only option is
to manage service yourself.
>
> In a lot of cases I think I’ll just want to move from deploying
> MyService_V1.aar to deploying MyService_V2.aar. V1 can stay deployed
> on the Axis2 server until the consumers have all moved on to V2.
>
> I’ve been looking at including version information in the target
> namespace specified in the WSDL for the service as a mechanism for
> consumers to specify which version of the service they want to use.
> I’m struggling to understand what my options are for deploying the old
> and new versions of my service. Specifically:
>
> - I don’t seem to need to deploy MyService_V1 and MyService_V2 on
> different endpoint addresses, but
>
> - I assume I do have to give them different names in the <service>
> element of the wsdl.
>
> Is this correct?
>
> Finally, is there any way of using a single endpoint and service name
> that accepts requests from consumers that may have different XML
> namespaces depending on the version of the service they are using?
>
> Thanks,
>
> Dave
>


-- 
Thank you!


http://blogs.deepal.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org