As a .NET developer it’s becoming increasingly tempting to create service layers for our application and utilize some of the strengths in Windows Communication Foundation in our solutions. With the power WCF brings to the table and all the messages about SOA in general, it’s easy get swept into it all and default to distribution.
In this post I will try to outline some scenarios where a service layer might be beneficial and alternatives that might suite that scenario better sometimes.
Other applications needs to integrate with you
If there is other applications that want to integrate with you, chances are that services might be your solution. Before you start writing your service layer you owe yourself to think about why the other application is integrating with you.
Pushing data to or from you
If other applications are solely interested in pushing data to or from you, a service might not be the best answer. There is other tools such as Sql Server Integration Services that is better suited for data import / export of this kind.
If all you want to do is share some piece of information, like your product catalog, it might even be as simple as exposing a XML-document. No need for a service layer. (all though WCF does a good job exposing XML-documents with the REST starter-kit).
You want to expose a business process
This is the block-buster feature of a service. Create a service and expose your business processes. Does this mean you will have to expose all of your business processes as services and have a service layer in your applications? Usually no. Usually it’s enough to create an integration point, a anti-corruption layer or a small service exposing exactly what you want integrated. There is no real need for a full blown tier separation.
Wait a minute, is there no reasons for the service tier?
Of course there is. There is a couple of really good reasons. Most of them tied into the word “tier”. When do I need a separate “tier”? A couple of of reasons:
Lightweight UI’s like Silverlight or Flash
Advanced business logic is usually heavy weight. It involves a lot of code and usually it doesn’t belong on the client side. For lightweight UI’s, or Rich Internet Applications (RIA), this is very true. You want the full power of the CLR and the .NET framework for your applications and to get that you’ll need to separate the application into at least two tiers.
Wanting “middleware” in your application
Often there is the need for integration with other systems, orchestration of some sort or interesting conversation patterns like publish / subscriber. This is not the job for a client but for middleware. Or a “server”. In this case, separating the back-end into it’s own tier is a really good idea.
Summary
So use your service tier wisely, there isn’t one pattern and one usage of it and often it’s not the only solution or even the best. The extra tier will bring extra complexity so make sure it will carry it’s own weight.