I know performance can be an issue with web services when you compare them to direct code. But with SOA on the rise, I have to wonder if I should be planning to make every business object in my apps into a web service, either WCF or .asmx.
The improvements to WCF in .NET 4 are definitely making me give is a second look.
Hi,
Regardless of 'the future', cool new technologies and the like, one principle never goes out of date: Simplicity.
My general approach is to keep things as simple as possible. The dev tools we have today makes it delightfully easy to 'upgrade' a normal business object into a webservice when you need to.
Just a few less wires inside the box that are not needed. Plus a free performance boost :)
Regardless of dogma, the correct answer is given by the answer to "does it make sense?"
Does it make sense to make your Employee business object available as a service? Maybe so. Does it make sense to have your WarehouseShelfLocationArchive business object available as a service? Maybe not. If not, it's foolish to do so only because it's fashionable.
@gabe is right that you need to make sure that making objects services makes sense. However, I've also found that once you build a service, others will consume it. I've seen this over and over again in the services I've written: "if you build it, they will come".
SOA is about independent systems talking to other independent systems. If you have a scenario where one system needs to know about the actions or data of another system, a service might be the answer, but not every object you ever create will not need to be consumed via a service. And all the other guys are exactly correct. Does it make sense? and Is it simple?