Posts Tagged WCF
Common Service Host for Windows Communication Foundation
Posted by Patrik Löwendahl in WCF on June 14, 2010
After having to write new instance providers, host factories and service behaviors for almost every new WCF project; I decided to write a simple reusable component for WCF and dependency injection and put it on codeplex so that I never had to write that again.
The idea is simple, when creating service hosts you more often then not want a centralized controlling factory that handles your dependency wiring and life time management of said dependencies. WCF requires you to add custom code to the initialization extension points.
Enter the Common Service Host. Based on the Common Service Locator interface and model it allows for a single library with classes for any DI-Framework to automatically wire up your service instances. From the codeplex documentation:
Example host configuration:
public class AppContainer : UnityContainerProvider
{
public void EnsureConfiguration()
{
UnityContainer.RegisterType();
}
}
Example self-hosted usage:
using(var host = new CommonServiceHost()) { host.Open(); }
Example usage for a .svc file:
<%@ ServiceHost Language="C#"
Service="Sogeti.Guidelines.Examples.Service1"
Factory="Sogeti.Guidelines.WCF.Hosting.CommonServiceHostFactory`1
[[Sogeti.Guidelines.Examples.AppContainer,
Sogeti.Guidelines.Examples.Service]], Sogeti.Guidelines.WCF.Hosting" %>
Included providers in the current release for Unity and spring.net
Get your copy here: http://commonservicehost.codeplex.com
Architecture considerations: When do I benefit from services?
Posted by Patrik Löwendahl in Architecture, WCF on September 28, 2009
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.
No Comments
Is Windows Communication Foundation to complex?
Posted by Patrik Löwendahl in Architecture, WCF on September 13, 2009
Today at ALT.NET’s unconference we had a great discussion initialized by Alan Smith about the state of WCF and the complexity, if any, it imposes on developers. The thesis was that WCF was hard to learn for the “Average developer” and there was a lot of underlying details of communication that might be too visual. Alan showed an example of all the details generated by SvcUtil in it’s default settings. He compared with ASMX web services where “regular” asp.net developers could develop new services as simple as they implemented an event handler.
My view on this is kind of simple and ties into discussions I’ve had in the past about The holy abstraction level, the real question to ask is if I and my project is ready for distribution? Am I skilled enough to wield a tool for building services?
ASMX is a bit simpler, sure, if you don’t want real security. Or are looking for reliable sessions or any other more interesting service conversation pattern then request/response over HTTP.
The simple truth is that anything but request / response has a lot of underlying principles that are far from easy. These principles is what WCF aims to be an abstraction layer for. Not HTTP request / response. Sure, there is a lot of things that can be simpler. More things that tools can do for you to make you faster. Some of the simpler conversation patterns could be easier to implement.
But the problem will still be the same, building distributed applications that scale, perform are reliable and secure is not a walk in the park. It requires skill, planning and a lot of thought.
Distributed applications are hard for a reason and no tool will make architecting them easy, any tool that try will fool developers into dangerous traps.
So in short, it’s not WCF that’s too complex, WCF takes complex conversation patterns to the average developer and that makes WCF seem complex at a first glimpse.
If you want to master WCF development, your first step should be to master distributed application design and conversation patterns. When you do; WCF will be an excellent and simple enough tool for you.
4 Comments
