A view days ago I read a very interesting blogpost from Martin Fowler about an Evolutionary SOA. Which is a very interesting topic.
The main question Martin Fowler asks is whether a SOA can be done on a Agile/XP way.
I think it can be done.
If you want to start with an Service Oriented Architecture, start with baby steps (see also a post about Guerilla SOA.) Quite often I see the that a lot of components are build as a service. But services only have one consumer at development time (And will have much longer.) At the moment an components starts to represent a service delivered as a ‘physique service’, that’s the moment to start adding services. And no SOA isn’t ‘just a bunch of services’. So just adding a xml-something interface doesn’t make it better useable, if you don’t need it.
Can a service evolve an a Agile/XP way?
Yes it can, but changing your Interface contract on a frequent base, doesn’t make the consumer of your service very happy. It can be handy to implement Consumer Driven Contracts.
If you use BizTalk the WCF LOB Adapter SDK can be a help. (And can also be used without BizTalk). Within WCF there’s support for the Extensible object. What happens is that upfront the service is designed with options to extend the interface contract. So consumers who wishes not to upgrade to your newest contract version, can still use the service as of before, but newer consumers can make use of the extension classes.
Those were my 2 cents. Any other ideas please feel free to share them.