Versioning web services

[=?Utf-8?B?U2NvdHQ=?=]

I have seen many articles describing why versioning web services are
important. I have a scenario that I would like to propose to seek a solution.

I have a publicly consumable web service. Two different clients, A and B,
consume this service. I make framework and architecture modifications that
are needed to my web services. Client "A" is ready for the upgrade while
client "B" is not ready. I have to publish the update immediately for client
"A" to continue to work with me, but client "B" needs to be able to
continually operate as if nothing has been modified. Without having seperate
web service locations published, how would I accomplish this task?

To keep it simple web method GetData(int id, string Description) is consumed
by both client "A" and "B". Without changing the signature, location, or
anything that is visible to the client, except the return data for client
"A", how do I provide a mechanism for client "A" to be processed by the new
architecture and client "B" to be processed by the old architecture.

[=?Utf-8?B?RXVnZW4=?=]

Scott,

I am proposing a solution that will work if it is implemented in the web
service/client code from the very beginning, before asking the clients to use
a newer version of your service.

Define a SoapHeader in the web service that will store the version of your
service in a data member.
Apply the SoapHeader attribute to your web method.
Write code inside your web method to read the value of the SoapHeader data
member (that is set from the client code) and to perform different logic
based on the value of this data member.

On the client, write code like this:
using System;

public class Sample {

public static void Main() {
MyWebService ws = new MyWebService();

try {
MyHeader customHeader = new MyHeader();
customHeader.MyVersion = "Header Value for MyVersion";
customHeader.MustUnderstand = true;
ws.myHeader = customHeader;

int results = ws.MyWebMethod();
}
catch (Exception e) {
Console.WriteLine ("Exception: {0}", e.ToString());
}
}
}

You can set customHeader.MyVersion reading a configuration file parameter
(web.config, etc).

In this way, when you add new logic into your web method and create a new
web service version, ask the client to modify the configuration file and set
the value for the SoapHeader to your new version number.

I have to test this to see if it works.

Here is a MS link:
http://msdn2.microsoft.com/en-us/library/y4t36w86.aspx

Hope it helps,
Eugen

"Scott" wrote:

I have seen many articles describing why versioning web services are
important. I have a scenario that I would like to propose to seek a solution.

I have a publicly consumable web service. Two different clients, A and B,
consume this service. I make framework and architecture modifications that
are needed to my web services. Client "A" is ready for the upgrade while
client "B" is not ready. I have to publish the update immediately for client
"A" to continue to work with me, but client "B" needs to be able to
continually operate as if nothing has been modified. Without having seperate
web service locations published, how would I accomplish this task?

To keep it simple web method GetData(int id, string Description) is consumed
by both client "A" and "B". Without changing the signature, location, or
anything that is visible to the client, except the return data for client
"A", how do I provide a mechanism for client "A" to be processed by the new
architecture and client "B" to be processed by the old architecture.

[=?Utf-8?B?U2NvdHQ=?=]

The challenge with this approach is that the client is required to modify
exisitng code and the exisiting implementation they may have. In a situation
where I have no control or ability to dictate to the client to change, this
would not be a plausable option.

I did consider something similar to this approach and appreciate the input.
I really need a solution in which the modifcation is totally transparent to
the client in the manner of consumption. It would be OK if the client could
tell they are consuming a different service, but not OK for them to have to
modify their current base.

Would an approach of using an HTTP Handler to intercept the request, access
a hash table for the appropriate version, then route to the appropriate
version be plausable I wonder? The trick is whether or not I could determine
the "Who" in the request, then route that request to the appropriate version.
My thoughts are to implement something like an interface, where the client
is consuming a service which is nothing more than a generic signature which
determines the "who, where, and what". Any thoughts?

"Eugen" wrote:

Scott,

I am proposing a solution that will work if it is implemented in the web
service/client code from the very beginning, before asking the clients to use
a newer version of your service.

Define a SoapHeader in the web service that will store the version of your
service in a data member.
Apply the SoapHeader attribute to your web method.
Write code inside your web method to read the value of the SoapHeader data
member (that is set from the client code) and to perform different logic
based on the value of this data member.

On the client, write code like this:
using System;

public class Sample {

public static void Main() {
MyWebService ws = new MyWebService();

try {
MyHeader customHeader = new MyHeader();
customHeader.MyVersion = "Header Value for MyVersion";
customHeader.MustUnderstand = true;
ws.myHeader = customHeader;

int results = ws.MyWebMethod();
}
catch (Exception e) {
Console.WriteLine ("Exception: {0}", e.ToString());
}
}
}

You can set customHeader.MyVersion reading a configuration file parameter
(web.config, etc).

In this way, when you add new logic into your web method and create a new
web service version, ask the client to modify the configuration file and set
the value for the SoapHeader to your new version number.

I have to test this to see if it works.

Here is a MS link:
http://msdn2.microsoft.com/en-us/library/y4t36w86.aspx

Hope it helps,
Eugen

"Scott" wrote:

I have seen many articles describing why versioning web services are
important. I have a scenario that I would like to propose to seek a solution.

I have a publicly consumable web service. Two different clients, A and B,
consume this service. I make framework and architecture modifications that
are needed to my web services. Client "A" is ready for the upgrade while
client "B" is not ready. I have to publish the update immediately for client
"A" to continue to work with me, but client "B" needs to be able to
continually operate as if nothing has been modified. Without having seperate
web service locations published, how would I accomplish this task?

To keep it simple web method GetData(int id, string Description) is consumed
by both client "A" and "B". Without changing the signature, location, or
anything that is visible to the client, except the return data for client
"A", how do I provide a mechanism for client "A" to be processed by the new
architecture and client "B" to be processed by the old architecture.

[=?Utf-8?B?RXVnZW4=?=]

Hi Scott,

I was thinking in the same way as you, from a COM perspective, creating an
interface.

What I understand it is missing in this approach is a proxy on the server.

If I will be able to know on the server that a particular client is using
these set of methods from the service and another client is using a newer
version of the service, meaning another set of methods, than the problems
will be solved.

However, calling web services works over SOAP and the only thing you can do
is to modify the SOAP message that a client is sending to the server. So far,
I know that this means writting code on the client and server, creating SOAP
Extentions, etc. This is not the solution you are looking for.

I have found an article describing the WSDL of the web services in details
and I suggest for you to read it too. Here is the link:

http://msdn2.microsoft.com/en-gb/library/ms996434.aspx

Pay attention to Port Types: "Conceptually, portTypes are very similar to
interfaces that group together related methods, properties, fields, and
events."

I have to read better this article myself and try experiment creating some
interfaces, if possible.

Best regards,
Eugen
"Scott" wrote:

The challenge with this approach is that the client is required to modify
exisitng code and the exisiting implementation they may have. In a situation
where I have no control or ability to dictate to the client to change, this
would not be a plausable option.

I did consider something similar to this approach and appreciate the input.
I really need a solution in which the modifcation is totally transparent to
the client in the manner of consumption. It would be OK if the client could
tell they are consuming a different service, but not OK for them to have to
modify their current base.

Would an approach of using an HTTP Handler to intercept the request, access
a hash table for the appropriate version, then route to the appropriate
version be plausable I wonder? The trick is whether or not I could determine
the "Who" in the request, then route that request to the appropriate version.
My thoughts are to implement something like an interface, where the client
is consuming a service which is nothing more than a generic signature which
determines the "who, where, and what". Any thoughts?

"Eugen" wrote:

Scott,

I am proposing a solution that will work if it is implemented in the web
service/client code from the very beginning, before asking the clients to use
a newer version of your service.

Define a SoapHeader in the web service that will store the version of your
service in a data member.
Apply the SoapHeader attribute to your web method.
Write code inside your web method to read the value of the SoapHeader data
member (that is set from the client code) and to perform different logic
based on the value of this data member.

On the client, write code like this:
using System;

public class Sample {

public static void Main() {
MyWebService ws = new MyWebService();

try {
MyHeader customHeader = new MyHeader();
customHeader.MyVersion = "Header Value for MyVersion";
customHeader.MustUnderstand = true;
ws.myHeader = customHeader;

int results = ws.MyWebMethod();
}
catch (Exception e) {
Console.WriteLine ("Exception: {0}", e.ToString());
}
}
}

You can set customHeader.MyVersion reading a configuration file parameter
(web.config, etc).

In this way, when you add new logic into your web method and create a new
web service version, ask the client to modify the configuration file and set
the value for the SoapHeader to your new version number.

I have to test this to see if it works.

Here is a MS link:
http://msdn2.microsoft.com/en-us/library/y4t36w86.aspx

Hope it helps,
Eugen

"Scott" wrote:

I have seen many articles describing why versioning web services are
important. I have a scenario that I would like to propose to seek a solution.
>
I have a publicly consumable web service. Two different clients, A and B,
consume this service. I make framework and architecture modifications that
are needed to my web services. Client "A" is ready for the upgrade while
client "B" is not ready. I have to publish the update immediately for client
"A" to continue to work with me, but client "B" needs to be able to
continually operate as if nothing has been modified. Without having seperate
web service locations published, how would I accomplish this task?
>
To keep it simple web method GetData(int id, string Description) is consumed
by both client "A" and "B". Without changing the signature, location, or
anything that is visible to the client, except the return data for client
"A", how do I provide a mechanism for client "A" to be processed by the new
architecture and client "B" to be processed by the old architecture.

[=?Utf-8?B?RXVnZW4=?=]

Hi Scott,

I am thinking to another idea where you can use reflection.

Your web service method can have a third parameter that will contains a
collection of Interfaces or Methods defined in the web service.

Since the client call to
"method(param1,param2,service.GetType().GetInterfa ces()) "
will send a list of interfaces from the client web service proxy, that is,
only the interfaces defined at the time the client referenced the service,
you will be able to make the distinction on the server between a client
version and another.

A newer client will use a new reference of a service, hence using a new
interface defined by you that the first client will be missing.

Serialization may be a problem for the third parameter; I passed an
ArrayList in a web service call some time ago so at least this can work.

What do you think, could this idea be a possible solution?

Eugen

"Eugen" wrote:

Hi Scott,

I was thinking in the same way as you, from a COM perspective, creating an
interface.

What I understand it is missing in this approach is a proxy on the server.

If I will be able to know on the server that a particular client is using
these set of methods from the service and another client is using a newer
version of the service, meaning another set of methods, than the problems
will be solved.

However, calling web services works over SOAP and the only thing you can do
is to modify the SOAP message that a client is sending to the server. So far,
I know that this means writting code on the client and server, creating SOAP
Extentions, etc. This is not the solution you are looking for.

I have found an article describing the WSDL of the web services in details
and I suggest for you to read it too. Here is the link:

http://msdn2.microsoft.com/en-gb/library/ms996434.aspx

Pay attention to Port Types: "Conceptually, portTypes are very similar to
interfaces that group together related methods, properties, fields, and
events."

I have to read better this article myself and try experiment creating some
interfaces, if possible.

Best regards,
Eugen
"Scott" wrote:

The challenge with this approach is that the client is required to modify
exisitng code and the exisiting implementation they may have. In a situation
where I have no control or ability to dictate to the client to change, this
would not be a plausable option.

I did consider something similar to this approach and appreciate the input.
I really need a solution in which the modifcation is totally transparent to
the client in the manner of consumption. It would be OK if the client could
tell they are consuming a different service, but not OK for them to have to
modify their current base.

Would an approach of using an HTTP Handler to intercept the request, access
a hash table for the appropriate version, then route to the appropriate
version be plausable I wonder? The trick is whether or not I could determine
the "Who" in the request, then route that request to the appropriate version.
My thoughts are to implement something like an interface, where the client
is consuming a service which is nothing more than a generic signature which
determines the "who, where, and what". Any thoughts?

"Eugen" wrote:

Scott,
>
I am proposing a solution that will work if it is implemented in the web
service/client code from the very beginning, before asking the clients to use
a newer version of your service.
>
Define a SoapHeader in the web service that will store the version of your
service in a data member.
Apply the SoapHeader attribute to your web method.
Write code inside your web method to read the value of the SoapHeader data
member (that is set from the client code) and to perform different logic
based on the value of this data member.
>
On the client, write code like this:
using System;
>
public class Sample {
>
public static void Main() {
MyWebService ws = new MyWebService();
>
try {
MyHeader customHeader = new MyHeader();
customHeader.MyVersion = "Header Value for MyVersion";
customHeader.MustUnderstand = true;
ws.myHeader = customHeader;
>
int results = ws.MyWebMethod();
}
catch (Exception e) {
Console.WriteLine ("Exception: {0}", e.ToString());
}
}
}
>
You can set customHeader.MyVersion reading a configuration file parameter
(web.config, etc).
>
In this way, when you add new logic into your web method and create a new
web service version, ask the client to modify the configuration file and set
the value for the SoapHeader to your new version number.
>
I have to test this to see if it works.
>
Here is a MS link:
http://msdn2.microsoft.com/en-us/library/y4t36w86.aspx
>
Hope it helps,
Eugen
>
"Scott" wrote:
>
I have seen many articles describing why versioning web services are
important. I have a scenario that I would like to propose to seek a solution.

I have a publicly consumable web service. Two different clients, A and B,
consume this service. I make framework and architecture modifications that
are needed to my web services. Client "A" is ready for the upgrade while
client "B" is not ready. I have to publish the update immediately for client
"A" to continue to work with me, but client "B" needs to be able to
continually operate as if nothing has been modified. Without having seperate
web service locations published, how would I accomplish this task?

To keep it simple web method GetData(int id, string Description) is consumed
by both client "A" and "B". Without changing the signature, location, or
anything that is visible to the client, except the return data for client
"A", how do I provide a mechanism for client "A" to be processed by the new
architecture and client "B" to be processed by the old architecture.