3

Alright here goes nothing. After reading Best Practices on Service Versioning and Data Contract Versioning (http://msdn.microsoft.com/en-us/library/ms733832.aspx) I mostly understand how its all done. I am planning to use Agile Versioning for Data Contracts but cant figure out what the difference or better practice is between Creating a WorkRequestV2 to add new properties or just adding the new properties to WorkRequestV1. Now I tried doing both ways and it worked but when I do create WorkRequestV2 I have to modify ServiceContractor to use WorkRequestV2 why do this rather than just adding properties to WorkRequestV1? What is the difference?

The Example I looked at was here (http://msdn.microsoft.com/en-us/library/ms731138.aspx) CarV1 and CarV2 why not add HorsePower to CarV1 and not have to create a whole new Contract.

[DataContract(Name = "WorkRequest")]
public class WorkRequestV1 : IExtensibleDataObject {
    [DataMember(Name = "workrequest",Order=1,IsRequired=true)]
    public int workrequest { get; set; }
    [DataMember(Name = "CQ")]
    public string CrewHeadquarter { get; set; }
    [DataMember(Name = "JobCode")]
    public string JobCode { get; set; }
    [DataMember(Name = "JobType")]
    public string JobType { get; set; }
    [DataMember(Name = "Latitude")]
    public string Latitude { get; set; }
    [DataMember(Name = "Longitute")]
    public string Longitute { get; set; }

    private ExtensionDataObject theData;
    public ExtensionDataObject ExtensionData {
        get {
            return theData;
        }
        set {
            theData = value;
        }
    }
}
Nick Manojlovic
  • 1,171
  • 10
  • 30
  • 49

1 Answers1

1

Have another read of the Data Contract versioning (your second link)

Here is a quote from that page:

Breaking vs. Nonbreaking Changes

Changes to a data contract can be breaking or nonbreaking. When a data contract is changed in a nonbreaking way, an application using the older version of the contract can communicate with an application using the newer version, and an application using the newer version of the contract can communicate with an application using the older version. On the other hand, a breaking change prevents communication in one or both directions.

For your case, adding some additional properties is a non-breaking change. You can quite safely add the properties to the existing data contract rather than create a new one, as long as you don't have strict schema validation (such as the new properties don't have 'required' marked on them)

Old clients communicating with new services still continue to work, values of the new properties will remain the default value. New clients communicating with old services will also work, as the new properties will be ignored.

But as you can see, you will run into the problem of how can you ensure new clients communicate with new services, and old clients with old services? If this isn't an issue, then you don't have a problem. Otherwise you may need to introduce a new data contract.

Further reading:

MSDN Service Versioning

IBM Best practice for Web service versioning

Oracle Web services versioning

What are your WebService Versioning best practices?

Community
  • 1
  • 1
EdmundYeung99
  • 2,461
  • 4
  • 27
  • 43
  • Thank you! But the problem you get into when creating a new Data Contract and you have to create a new Service Contract or new Function within existing Service Contract to be able to take the new data contract am I correct? Which than requires a new End Point correct? I am trying to stay away from Creating a new endpoint. – Nick Manojlovic Mar 13 '13 at 12:55
  • Yes you would need to host a new service on the new endpoint. However if you wanted to update the existing service contract by adding an operation, which accepted the new data contract, then you could still do this on the same service/endpoint – EdmundYeung99 Mar 13 '13 at 20:08
  • Now it all comes together. Thank you much for taking time to help me understand this. You the man. – Nick Manojlovic Mar 13 '13 at 20:33