Vai offline con l'app Player FM !
[Podcast] Versioning and SOA–There is no IDog2
Manage episode 65045180 series 63841
In this podcast we’ll look at the issues around versioning and SOA and how the asynchronous nature of messaging obviates the need for previously accepted interface-based versioning practices.
Jarrod asks:
Hi Udi,
I have some questions around versioning and SOA:
Over the years I’ve been fairly adamant about the practice of versioning interfaces should a method change be needed.
Hence, IDog and IDog2
Generally I would also say that a method addition would need a new interface as much as a change to an existing method or property (sometimes requiring completely deprecating the old interface).
With SOA being used more and contract first designs coming down the pipe…an addition of a method or operation to a contract in SOA does not mean its a breaking change.
So, do you continue to create a new interface and version the name within an SOA environment? Even if its just one method that is being added?
A service contract, in general…with just a single method in my opinion is a bad design. Sure, there are exceptions to that but I can just see changes made to the service contracts over the course of a few years with many 1-2 method interfaces.
Day 1 : 12 methods on interface IDog
6 months later : 1 new method, create IDog2 which implements IDog
15 months later : 2 new methods, create IDog3 which implements IDog2
Some can argue that if you’re having to add methods like this, the original design was flawed. That may be…or you could just be in a volatile business environment in which SOA must adapt.
So my main questions are:
1) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you also have control of the consumers (internal consumers)?
2) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you do not have control of the consumers (external consumers)?
3) If the answer to the above is yes, is a single method on a new interface acceptable?
4) If you know of a problem in an existing interface on a method and have control of the consumers – do you “fix” the method and redeploy to the consumers? Or do you deprecate the entire interface and begin anew?
I’m interested in seeing your responses
Jarrod
Download
Download via the Dr. Dobb’s site
Or download directly here
Additional References
Want more?
Check out the “Ask Udi” archives.
Got a question?
21 episodi
Manage episode 65045180 series 63841
In this podcast we’ll look at the issues around versioning and SOA and how the asynchronous nature of messaging obviates the need for previously accepted interface-based versioning practices.
Jarrod asks:
Hi Udi,
I have some questions around versioning and SOA:
Over the years I’ve been fairly adamant about the practice of versioning interfaces should a method change be needed.
Hence, IDog and IDog2
Generally I would also say that a method addition would need a new interface as much as a change to an existing method or property (sometimes requiring completely deprecating the old interface).
With SOA being used more and contract first designs coming down the pipe…an addition of a method or operation to a contract in SOA does not mean its a breaking change.
So, do you continue to create a new interface and version the name within an SOA environment? Even if its just one method that is being added?
A service contract, in general…with just a single method in my opinion is a bad design. Sure, there are exceptions to that but I can just see changes made to the service contracts over the course of a few years with many 1-2 method interfaces.
Day 1 : 12 methods on interface IDog
6 months later : 1 new method, create IDog2 which implements IDog
15 months later : 2 new methods, create IDog3 which implements IDog2
Some can argue that if you’re having to add methods like this, the original design was flawed. That may be…or you could just be in a volatile business environment in which SOA must adapt.
So my main questions are:
1) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you also have control of the consumers (internal consumers)?
2) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you do not have control of the consumers (external consumers)?
3) If the answer to the above is yes, is a single method on a new interface acceptable?
4) If you know of a problem in an existing interface on a method and have control of the consumers – do you “fix” the method and redeploy to the consumers? Or do you deprecate the entire interface and begin anew?
I’m interested in seeing your responses
Jarrod
Download
Download via the Dr. Dobb’s site
Or download directly here
Additional References
Want more?
Check out the “Ask Udi” archives.
Got a question?
21 episodi
Tutti gli episodi
×Benvenuto su Player FM!
Player FM ricerca sul web podcast di alta qualità che tu possa goderti adesso. È la migliore app di podcast e funziona su Android, iPhone e web. Registrati per sincronizzare le iscrizioni su tutti i tuoi dispositivi.