What is the advantages and disadvantages of using services over components?

Question

Hi,

From past few months I am working on projects in latest dot net frameworks.

I feel that in latest dot net versions "services" are encouraged over components. Is that correct?

I have seen in silver light (I am a beginner in silver light) all the DB layer operations are exposed as services. I don't know right now component programs also are available?

What is the advantages? What about the performance if all the layers are exposed as services instead of DLLS?

Please through some light on this subject that where should I begin to understand this concept correctly?

Thanks

SC

Answer 1

It's really all to do with a Service Oriented Architecture - something that's been common for a while and is very popular.

The idea is that distinct operations are decoupled from each other so they can be reused and modified without recompiling the apps that use it. Rather than a piece of code in a DLL being modified and copied everywhere, a service can be deployed that represents a single point of access for a particular piece of processing or source of information.

Say you had a credit card validation component. You may write this code and compile it into a DLL and start including that in all your applications. Nothing wrong with that unless you notice a bug or the rules for CC validation change. Or maybe you want to upgrade it to check it against a blacklist. You can't do any of those things without recompiling the apps that use it.

If your credit card validation is exposed as a service however, you can make the changes and deploy to one location. Provided the signature is the same (same parameters and response), the applications don't even have to know it's changed.

Another advantage of using services over components is that the services can be hosted anywhere. They can be on the local server or on the other side of the world.

Having said this, like everything you should decide the architecture on a case-by-case basis. While the credit-card validation was a good example of when a service is useful, providing a service to render HTML controls doesn't make much sense.

Answer 2

Something else to consider -- just because functionality is exposed as a "service" doesn't mean that it has to be hosted somewhere or exposed as a webservice.

You could very well access a service directly, in memory.

Exposing related functionality as a service is more about the interaction between various pieces of your application. It doesn't say anything about how you deploy/access these pieces.

Answer 3

"Cross-language" compatibility is another advantage. You can write a service in C#.net which can be accessed also from Java. So reusing goes beyond programming language usage.

What is the advantages? What about the performance if all the layers are exposed as services instead of DLLS?

I would pay attention to this point here. What do you mean by "all layers"? Application layers such as Business and Data Access Layer?? I doubt that this may be useful (of course it depends on your context) but usually a service is something that may be reused in many different contexts. An example could be a service for validating the Fiscal code. You would then call this service from your application's business layer. I cannot imagine of a case where you would expose the business layer as separate service and the data access layer as another separate one. Usually they are quite specific for your application that you're developing. What could be is that you have an application that is for instance accessible through the web (as web application) and there is another entry point through a web service that other apps can use (some kind of API). That would make sense, however you wouldn't directly expose your business layer but rather create some kind of "gateway" which is your webservice (a lightweight facade that delegates to your business logic classes).