To follow up on the post about SOA from the other week, one of the SOA related things I find myself discussing with customers / colleagues / people in general, again and again is whether there is an equal sign between SOA and Web Services?
Put in another way – do you have to have Web Services in your architecture to be able to give it the big SOA label?
… as such the post could end there, but OK, let’s dig a little deeper into things.
Am I against Web Services? No, that’s not it. Web Services are great and the right solution in many scenarios. They are easy to implement and have the ability to work across platforms – when implemented correctly.
The problem is that for years already whenever there was a need to expose a service there has been a tendency to default to achieving this through implementing a Web Service. Often without considering what’s already there.
I have even seen cases where a certain operation existed within a legacy system but because it wasn’t exposed in a satisfactory way (read through a web service) and that wasn’t possible from the legacy system – the entire operation was reimplemented and exposed in the wanted way.
As I wrote the other week, to me, one of the important points when designing a SOA architecture, is to utilize existing functionality. This also goes for interfaces. If there is a way to access existing functionality – be it through an old API, a stored procedure or even exchanging files – if it meets the requirements utilize the existing interface.
Of course the old interfaces will often come short some way or the other when presented with an up to date set of requirements, and then we can implement a new interface and if there is really no other way, the entire operation behind the interface.
And then I agree that web services might be the better, faster approach to a new interface … or is it!? WCF is looking good, more on that in the future.