Service Oriented Architecture and evolving objects shared between applications

Question

I'm about to begin writing a suite of WCF services for a variety of business applications. This SOA will be very immature to begin with and eventually evolve into a strong middle-ware layer.

Unfortunately I do not have the luxury of writing a full set of services and then re-factoring applications to use them, it will be a iterative process done over time. The question I have is around evolving (changing, adding, removing properties) business objects.

For example: If you have a SOA exposing a service that returns obj1. That service is being consumed by app1, app2, app3. Imagine that object is changed for app1, I don't want to have to update app2 and app3 for changes made for app1. If the change is an add property it will work fine, it will simply not be mapped but what happens when you remove a property? Or change a property from a string to an int? How do you manage the change?

Thanks in advance for you help?

PS: I did do a little picture but apparently I need a reputation of 10 so you will have to use your imagination...

Answer 1

The goal is to limit the changes you force your clients to have to make immediately. They may eventually have to make some changes, but hopefully it is only under unavoidable circumstances like they are multiple versions behind and you are phasing it out altogether.

Non-breaking changes can be:

1. Adding optional properties
2. Adding new operations

Breaking changes include:

1. Adding required properties
2. Removing properties
3. Changing data types of properties
4. Changing name of properties
5. Removing operations
6. Renaming operations
7. Changing the order of the properties if explicitly specified
8. Changing bindings
9. Changing service namespace
10. Changing the meaning of the operation. What I mean by this, for example, is if the operation always returned all records but it was changed to only return certain records. This would break the clients expected response.

Options:

1. Add a new operation to handle the updated properties and logic. Modify code behind original operation to set new properties and refactor service logic if you can. Just remember to not change the meaning of the operation.
2. If you are wanting to remove an operation that you no longer want to support. You are forcing the client to have to change at some point. You could add documentation in the wsdl to let client know that it is being deprecated. If you are letting the client use your contract dll you could use the [Obsolete] attribute (it is not generated in final wsdl so that's why you can't just use it for all)
3. If it is a big change altogether, a new version of the service and/or interface and endpoint can be created easily. Ie v2, v3, etc. Then you can have the clients upgrade to the new version when the time is right

Here is also a good flowchart from “Apress - Pro WCF4: Practical Microsoft SOA Implementation” that may help.