In this post, i’d like to take the chance to explain the downsides to exposing entities through services.  Though i’ll probably miss quite a few of the downsides (feel free to add to the list through comments), the ones i will mention are IMO important enough to take note of.

Exposing entities to clients means your clients are very tightly coupled to your service(s)

Entities are a part of your domain.  These entities in your domain can change for various reasons.  Sometimes because functional changes are required, but quite often also for optimizations (whether they are for performance reasons or to improve the clarity and maintainability of your domain).  Functional changes can impact your clients, though that is not necessarily the case.  Optimizations hardly ever have an impact on your clients (other than possibly improved response times from your service calls obviously).  If your service layer accepts and returns domain entities, each possible change is highly likely to have an impact on your clients.  And this impact is not cheap.  In the best case scenario, it means updating your service contracts, regenerating your service proxies and redeploying your clients.  In the worst case scenario, it means making actual changes to the code of your clients.  And for what? Because of changes that shouldn’t have impacted your clients in the first place?

Ideally, your clients are as dumb as they can be.  They should know as little as possible about the actual implementation of the domain because that implementation is simply not relevant to them.  They should present users with data and give them the option to modify that data, to trigger actions and to perform certain tasks.  They should focus squarely on those tasks and pretty much everything else is typically better suited to be done behind your service layer.  If you build your clients with no real knowledge of the actual domain model, but of DTO’s and possible actions to be performed then you can reduce the level of coupling between your clients and your services substantially.

Many of the people who prefer to expose entities often claim that going for the DTO approach introduces too much extra work and too many extra, seemingly unnecessary classes.  For starters, they don’t want to write code that maps entities to DTO’s.  First of all, the amount of code that this requires is in reality very small, not to mention very easy.  Secondly, you can just as well use a library such as AutoMapper to take that pain away from you.  And contrary to what you might think, there is a big performance gain to be had from returning DTO’s over entities, but i’ll get to that in the next section.

Entities are hardly ever the most optimal representation of data

I think we can safely say that most applications need to show data in the following 3 ways:

• In a grid view, either as a total listing of all instances of a certain type of data or the result of a search query or some kind of filtering action
• In dropdown controls or anything else that lets users select pieces of data
• In edit screens where a piece of data needs to be displayed in its entirety, perhaps even to be modified by the user

There are undoubtedly more ways in which data can be presented to the user but i think it’s safe to say that most business applications will certainly rely on the following 3 ways quite heavily.

In the case of a grid view, you’re frequently showing data that is related to more than one entity.  You’ll often need to include the name or the description of some associated entities.  So what exactly is it that you want to do in this situation?  Do you want to return a list of the main entities of the grid view, which all have their required association properties filled in so you can display the columns that you need in the grid view?  Do you actually need all of the properties of these entities (for both the main entities and the associated entities)?  Odds are high that you’re going to be returning a lot more data to the client than you actually need.  And that is what is realistically going to hurt the performance of your system.  Any piece of unnecessary data that you transmit to your clients has a cost associated with it.  The unnecessary data is retrieved from the database.  The entities are then serialized at the service end.  Then they are transmitted to the client.  Then they are deserialized by your client.  All of this is pretty costly, so the more unnecessary data that is included in this operation, the more your performance and the responsiveness of your client (not to mention your database and your server) is impacted negatively.

In the case of dropdown controls or anything else that lets users select pieces of data, you typically only need very few of the properties of that piece of data.  In many cases, the primary key and a name or a description are sufficient.  Do you really need to transmit the entire entity every time for usages like this? Again, keep in mind that all of that extra data that will never be used by your client needs to be retrieved, serialized, transmitted and deserialized again.  Surely, this is an awful waste, no? 

And then there’s the case where a piece of data needs to be displayed in its entirety.  In these cases, you will almost always need all of the properties of the entity that is displayed, but you’ll most often also need to show other data (things that can be selected, or linked to the main entity).  This other data will in most cases fall into the previous category where you’ll only need very little information about the actual entity.  If you’re smart, you’ve chosen the DTO approach to retrieve this data for the data that can be selected, and in that case, you already have all of the infrastructural code in place to project entities or data into DTO’s.  So you might as well reuse it for the main entity as well since you already have the capability to do this.

Always keep in mind that your entities will frequently either contain more data than needed, or less data than needed.  As such, it just doesn’t make much sense to expose entities to your clients since they are hardly ever optimal for client-side usage.  If you really want to think about performance, stop worrying about the supposed cost of mapping to DTO’s (which is truly negligible) and start focusing on what your actually sending to and from your service because this is far more costly than any kind of DTO-mapping really is.

Must your data really come from entities?

If you are displaying data to your user, does that data really need to come from your domain model?  Does it really need to be retrieved by populating a collection of entities to then return them to the client?  Again, keep the form of the data in mind when thinking about this.  In many cases, as i mentioned above, an entity is not the most optimal form of the data that your client needs.  So why even retrieve it through entities? Sure, asking your ORM to retrieve a set of entities based on a set of criteria is often the easiest thing to do, but if the easiest path were the best path, the overall quality of software projects wouldn’t be in the sad state that it’s in today.  If the form of the required data is not identical to the structure of an entity, it’s often far more optimal to simply populate a DTO directly from the data.  With NHibernate, you can easily do this by adding a list of projections to your query and then using a ResultTransformer to populate the DTO’s based on the direct output of the query.  In this case, no entity instance ever needs to be created when you’re just retrieving data, and no extra mapping between the entity and the DTO’s needs to be performed.  Your data access code simply retrieves the resulting data from a query, and puts that data directly in your DTO’s.  There’s no reason why usage of an ORM should prevent you from doing this.   Once again, this approach will offer far more performance benefits than avoiding DTO mapping at all costs ever can.

What about the behavior of your entities?

Do your entities have any behavior in them?  If not, they are already more of a DTO than a true entity.  In fact, if your entities have no behavior at all, you could even wonder why you’re using an ORM in the first place.  Now, behavior can mean many things.  It could mean lazy loading of associations.  It could mean actual business logic.  Obviously, lazy-loading doesn’t (and shouldn’t!) work client-side, but what about your business logic? Do you have business logic that can be executed client-side? Or is it business logic that should only be executed behind the service layer? If so, how do you make the distinction between this to prevent client-side usage from these entities? Whatever you do, you’re pretty much opening up a can of worms that really is better avoided in the first place.

How are you going to deal with technical issues?

Accepting and returning entities from services introduces a host of technical issues that can be quite substantial.  Serialization and deserialization specifically are issues that you need to be worried about.  If you’re using an ORM which does lazy-loading of associations, this will certainly cause serialization issues that you need to work around.  You can either disable lazy loading, or you can make sure that your entities are always fully initialized (as in: always have their associations fully loaded) before they are sent back to the client.  Disabling lazy-loading will cause performance problems in your service layer, either in places where you don’t expect them to be or in places that you haven’t thought of before it’s too late.  Fully loading your entities and their associates before returning them is another performance nightmare waiting to happen so that’s really not an ideal solution either.  You can try to hook into the serialization process or even the lazy-loading features of your ORM but whatever you do in that case will be a hack that will cause issues sooner or later.  And again, all of these problems can very easily be avoided with a solution which, i hope you realize by now, offers plenty more benefits than any solution where you accept/return entities in your service.

Conclusion

Every single downside to exposing entities through services are issues that i have myself encountered in past projects, either ones i’ve worked on myself, or ones that i’ve seen other people work on.  If that’s not enough for you, then maybe you’ll find it interesting to know that some of the brightest and most respected people (like Udi Dahan and Ayende for instance) in the .NET community also actively recommend against exposing entities through services because of the same downsides that i mentioned, though they could probably give you even more downsides that i forgot to cover in this post.  These downsides are not figments of anyone’s imagination.  They are very real, and you really, really ought to think twice before dismissing this advice. 

My architecture at works requires a web app and a windows app to talk to the application server via WCF. The Application server being where all the Data access and Service libraries live. I intend to implement NHibernate into the project. But wanted to get some pointers if your approach above is recommended for Web and Windows clients alike when sending and receiving data via WCF?

The short answer to that question is simply: It sure as hell is!

But you know i always prefer the longer answer .  The type of client always has an impact on the usage patterns of the service(s) that it needs.  A web client will often have a different usage pattern than a windows client or a mobile client will.  Each client should be able to consume the service in the manner that is most suitable to its requirements and constraints.  A web client is (or should be) completely stateless so a service that is meant to be used by a web client is typically geared towards that stateless model.   Windows clients or mobile clients are typically not entirely stateless and as such, the way they could use a service in the most optimal way often differs from how a web client would use the service.

One of the most important SOA principles is that there should be no implicit coupling between a service and its client(s) at all.  Generally speaking, coarse-grained operations are favored over fine-grained ones due to the cost of the communication overhead.  Yet, that easily conflicts with the usage patterns of different clients.  Since a web client is stateless, it often needs more coarse grained operations than a windows client which can retain data in its own process memory and thus, might benefit more from calling a fine-grained operation here and there.

Obviously, my solution to that problem is Agatha which makes it possible to implement each operation (or call them actions or commands and queries or whatever else you can think of) in the way that just makes the most sense, no matter what kind of client is going to call them.  Each client can consume the service operations in a manner that is optimal to the client, without the typical design impact and overhead that you have with traditional WCF services.

We have a few services that serve multiple types of clients.  ASP.NET pages.  Silverlight applications. Windows Services.  WPF tools.  Outlook add-ins.  And guess what?  Those services don’t have a clue as to who or what is using them and they are all implemented in the same way.  And it hasn’t caused a single problem or difficult design decision (as to the service API) yet.

There are probably a few answers to that question, but one reason that can’t really be disputed is that a lot of the tooling that Microsoft offers to developers simply encourage this kind of stuff.  Let’s go over a little example.

I wanted to see what some of Microsoft’s recommended tools would create for me if i wanted to create a Silverlight application which uses a database.  Obviously, a Silverlight application can’t use a database directly so the application will need to communicate with a service.  The service obviously does have access to the database.  RIA Services is a solution that Microsoft seems to be pushing a lot for this specific scenario so i figured i’d give this a shot.

I created a RIA Services Class Library project in my solution and tried to add a ‘Domain Service Class’ (as the RIA Services templates call it) to the project.  If you already have a DataContext or an ObjectContext defined within the same assembly, you can immediately select the database tables that you want to expose.   So i canceled the dialog and quickly added an ADO.NET Entity Data Model to the solution for which i selected my Chinook database.  I tried to create a ‘Domain Service Class’ again and got the following window:

Well, now that sure is easy isn’t it? I can immediately select all my ‘Entities’ and i can even check whether i want to be able to edit them through the service, and apparently i can also generate associated classes for metadata (which would be useful for validation according to the tooltip).  I checked the Album table, and left the ‘Enable editing’ option unchecked.  This created a service with the following code:

I don’t know about you, but i love those TODO statements.  After all, you really do might want to consider constraining the resultset that could be returned by the GetAlbum method.   Who knows, perhaps you have certain use cases where you don’t want all of the ‘entities’ in the Album table to be returned by your ‘domain service’.  Hopefully, this service will be used by developers who are smart enough to realize that they should modify this method, instead of using client-side LINQ statements to filter the returned Album ‘entities’ as i’m sure we’ve all seen in too many Microsoft demo’s already.

It gets better if you recreate the service and check the ‘Enable editing’ option.  Now you’re ‘domain service’ will also contain the following methods:

Man, this sure is easy, isn’t it? I now have a service that offers me full CRUD access to the Album table in my database.  If i wanted to, i could now start implementing a screen in my Silverlight application which allows my users to list the albums, edit them, delete them, create new ones, etc… and i wouldn’t even have to change anything in my ‘service layer’.   The problem is that too many developers actually will do exactly that.   After all, why should they doubt any code that was generated by a tool which comes from Microsoft?  If the tool can generate this, then certainly some people actually want you to use it like this, no?  If not, why would it even generate code like this?

I’m sure this kind of stuff gets a lot of ooh’s and aah’s during the product demo’s at Microsoft events, but other than that, what good does this really bring?  Is this really the way you want people to develop their services?  Do you really want developers to pretty much expose the database as-is to remote clients?  And those TODO statements simply won’t cut it, you know that all too well.  I simply don’t think there’s any good reason to generate code like this because a lot of people will simply take it as is and use it like that directly from their client code.  Oh sure, most of them will hook up the authentication but i’m willing to bet that very few people will actually put real business logic in there.  Why would they?  The message that a lot of people will get from the resulting code is that a service is merely a way to provide CRUD for your database tables.  What’s business logic to these people?  Right, the stuff they’ll implement in their presentation layer because this service doesn’t really encourage people to consider implementing it there.

The only benefit that i can see from using RIA services is that you don’t really have to deal with your service contracts, and your operation contracts or any of that stuff.   No, we won’t be doing any of that.  We simply use a [EnableClientAccess] attribute and we’re done!  I don’t really consider that a benefit, though i can certainly understand why people would not want to deal with the pain of classic WCF services.  RIA Services is simply a solution to the wrong problem.

I haven’t looked at ADO.NET Data Services (which will be renamed to WCF Data Services in .NET 4.0) yet, but i suppose it’ll be more of the same: something that makes it incredibly easy to create services directly on top of your database data.

Seriously though: who on earth actually wants that?

I have no doubt that there are some people out there that are using RIA Services in a responsible manner and are sticking by responsible architectural guidelines.  I also have no doubt that those people are ignoring most of the tooling that is offered by Microsoft around it.  So really, why not get rid of this kind of tooling, and spend the effort that normally goes into those tools (or anything else which encourages bad practices for that matter) on providing actual guidance to the developers of your platform?  The last thing we need are more developers who think that this is ‘ok’, or projects that have been delivered based on this kind of ‘architecture’, or customers that are turned off by .NET projects because “they all have maintenance problems”. 

First of all, you need to make sure that your IIS installation has support for Windows Authentication. Go to Add/Remove Programs (appwiz.cpl), click on Turn Windows Features on or off, select Internet Information Services - World Wide Web Services - Security and make sure that Windows Authentication is checked.

Next, you need to make sure that the virtual directory where you're hosting the WCF service has Windows Authentication enabled. Open Internet Information Services Manager (inetmgr), select the virtual directory where the WCF service is hosted, click on the Authentication icon and enable Windows Authentication.

After that, you need to add the following to the binding configuration of the service endpoint (in the host, obviously):

          <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Windows" />
          </security>

I only got it working with basicHttpBinding, so unfortunately i can no longer use the customBinding to use binary XML...

In your Silverlight project, open the ServiceReferences.ClientConfig file and add the following to the binding configuration:

          <security mode="TransportCredentialOnly" />

After that, you should be able to do this in your WCF service:

            WindowsIdentity myuser = ServiceSecurityContext.Current.WindowsIdentity;

And that should return the Windows user of the user running the Silverlight client.

For the record: this is with Silverlight 3... i have no idea if it'll work with Silverlight 2

My biggest issue with typical WCF usage is that of service contract design. It's very hard to get this 'right' and most people simply don't. First of all, you need to decide between fine-grained and coarse-grained operations. Fine-grained operations typically lead to chatty communication between the client and the service, which could seriously impact performance and scalability. Then again, fine-grained operations do offer a lot of flexibility when it comes to reusing functionality in various parts in the client. Coarse-grained operations typically don't have the same negative effect on performance, but they can easily introduce implicit coupling between your service and the client which can get pretty annoying when you need to deal with a new kind of client, like a Silverlight application for instance (which tends to have different service usage patterns than typical ASP.NET applications). It can also lead to duplication when parts of functionality offered by a coarse-grained operation are needed somewhere else.

Even if you do get the granularity of your operations right, you have to figure out where to put them. Are you going to create a service for each kind of functional subdomain (billing, invoicing, registrations, etc...), for each entity that is 'known' to the client (there are many people who do this, unfortunately) or on a per-feature basis (story or use case driven)? Every possible variation you can think of is already being used today, and they almost always come with a lot of disadvantages. Get this part wrong and you can end up with clients that might need 2 or more service proxies just to show some related data on a screen (or worse, to complete a business transaction). Whether you get it right or wrong, odds are high that you'll have spent quite a bit of time defining your service contracts. Time that might have been better off being spent on other parts.

The second thing that bothers me a lot about typical WCF usage is the quality of the code in service implementations. In the worst cases, these classes actually contain true business logic to implement the service operations. That's not just breaking the Single Responsibility Principle, it's more like assaulting it. Whether they contain actual business logic or merely delegate to other classes, these service implementations will need to talk to instances of classes or components that they depend on sooner or later. My question is, where do these instances come from? Do you manually resolve them through your IOC container? Do you have them injected in your service instance (if creation of the service instance is controlled by an IOC container, that is)? What if the granularity of the service contract forces the service implementation to depend on components that might not be used together in all operations?

And then there's the thorny issue of cross cutting concerns within service implementations. How many times have you seen the same old tired logging and exception handling code repeated in every service operation? How about transaction handling, auditing, authorization or resource management? True, you can plug into WCF's extensibility model (if you're willing to look for it...) or use AOP tricks to minimize that kind of code duplication but that in turn limits your possibilities when you want to add just a little bit of custom code to some of the cross cutting concern's logic when needed. In most cases, service implementations simply contain a lot of smelly code, the large majority of which is essentially a form of waste.

That's already an important list of problems when designing and implementing typical WCF services. But what about using typical WCF services? This is somewhat problematic as well, IMHO. First of all, you'll need a proxy to access the service. You can either develop these proxies yourself, or you can generate them through visual studio, svcutil, or custom tools that you (or others) developed. Whatever way you choose to use, you can't escape the fact that you constantly have to keep those proxy implementations in synch with their respective service contract. Every single time one of the developers adds an operation to a service (which is pretty often once there are a few people working on a large project), you're going to have to do something to make sure you can access that operation through your proxy. It's usually not a lot of work, but it does kinda disrupt your coding flow. Over and over again. It can also be a pain in the ass when it comes to source control conflicts.

Then there's the actual matter of using the proxy instances. Can you implement your story or use case with just one client proxy type? Great! Do you reuse the channel when making multiple service calls? You do? Great! Do you make sure you handle faulted channels properly? And if you need multiple client proxy types (depending on your service contract granularity), are you aware of the fact that you are using multiple WCF channels (and yes, they are expensive) which are often kept open longer than they should be if you're not careful? Are you generally careful about chatty communication? Obviously, that last one depends on the contract of the service and not really the implementation of the client proxy. There are quite a lot of things you need to keep in mind when using these proxies.

My final thing on the list of 'dislikes' is the configuration that is required to use these services. For every service you expose you'll need to add some XML to your configuration file. Twice even (server and client)! Most of this XML configuration is extremely tedious and very repetitive which just invites minor mistakes to be made. Those minor mistakes could lead to a lot of debugging/problem solving time though.

I've been subjected to each and every one of the issues i've mentioned in projects that made typical use of WCF (or classic ASP.NET Web Services for that matter). This type of service layer implementation is, IMHO, hurtful for productivity, detrimental to code quality and i don't really like the implicit trade-off between reusability and performance/scalability (depending on the granularity of your operations).

About a year ago, i really wanted to figure out a way to implement services which would enable me to keep fine-grained operations on my service layer without having to pay the performance/scalability penalty for that. As some of you already know, that led to the whole WCF call batching thing (more info here and here) which i later on called the Request/Response Service Layer. Some people liked the approach, but i don't think anyone else actually uses it. At least, i've never heard of anyone using it in a real project.

Well obviously, we've been using this at work for about a year now and while i won't claim that it's perfect (hint: nothing is), it has worked very well for us in several projects. More specifically, this approach has offered us the following benefits, which heavily contrast all of the downsides of typical WCF usage that i listed above:

• Since we only have one service contract with one service operation, we don't need to spend time thinking about how to design and implement our service contracts and our operations. After all, every operation that the service layer must support is a specific request type that can be added, together with its requesthandler.
• We can keep our operations as fine-grained as we want (which increases reusability and overall flexibility), without having to pay the cost for chatty network communication by batching multiple requests per roundtrip as much as possible in a transparent manner.
• The actual implementation of our service is very minimal. It's just a small class which resolves the appropriate requesthandler through the IOC container, based on the type of the incoming request. It then delegates to the requesthandler by passing the request to it, and it returns the response to the client. We can simply add 'operations' by adding request types and requesthandlers to our assemblies... everything gets registered automatically when the application starts up
• We avoid repetitive code for cross cutting concerns by putting it in a base requesthandler class that the other ones inherit from. That kind of code now only occurs once, and we can plug in custom code at any point of the execution by simply using the Template Method pattern.
• The implementation of our requesthandlers doesn't contain any code that doesn't have to be there. Each requesthandler simply implements the Handle method to handle the incoming request, and can do as it pleases to fulfill the request. All dependencies are injected automatically by the IOC container. It's usually nothing more than using the dependencies to execute the necessary business logic and then returning a response-derived object.
• Since we only have one service, we only need one client proxy which never needs to be updated (technically, we have 2: one which is entirely asynch and mostly used in Silverlight clients, and one which is strictly synchronous and is mostly used by ASP.NET applications and Windows Services or command line tools.
• This single client proxy implementation can make sure that underlying WCF resources are utilized as efficiently as possible and cleaned up properly throughout the client application(s).
• The client proxy is easy to stub during unit tests which increases the testability of our client side code.
• Very little configuration. We only have to configure one client-side endpoint, and one server-side endpoint. That's it.
• All of this is very easy to put in some kind of reusable library. Our applications simply reference the library, inherit from the base requesthandler types, make sure everything is registered properly upon application startup, add a couple of lines of XML and we can start the development of our service layer without any friction.

The only downside to this approach that i can think of after using it for a year, is interoperability with other platforms. I haven't used it in that situation yet, and while i do think it can be made to work i don't think it'll be easy nor pretty.

Now, just to be clear: this entire post was not a rant against WCF. I actually do like WCF as a technology, it's just the typical usage patterns of WCF that i really dislike. I love the fact that WCF is very extensible, configurable and flexible, but i merely consider it as a communication technology. Nothing more, nothing less.

There is a big problem with this. Well, at least one that i know of, possibly more. The ToString() method on the Message class returns the nicely formatted content of the message. Including all whitespace. This obviously increases the reported size of the SOAP message by a significant number, even though it's not sent over the wire with all that whitespace. A better way to calculate the size is like this:

One thing to keep in mind is that you need to be careful with writing the contents of a SOAP message. If you write the content of a SOAP message without copying it first, you'll run into other problems further along the WCF pipeline. So the MessageInspector now looks like this:

As you can see, you're better off creating a buffered copy of a message, and then creating a new message out of that copy before doing anything with it.

I obviously already had my service, so i just needed something that i could plug in at the appropriate moment to record the size of incoming and outgoing SOAP messages. Turns out this was extremely easy to do. First, you need to write an inspector for the messages (which has to implement WCF's IDispatchMessageInspector interface):

After that, you need a way to inject the MessageInspector into the behavior of your service. So you need to define your own behavior first:

And then you apply that to your service:

And that was it! I was afraid i was going to have to figure out which one of WCF's 12.4 billion configuration options would make this possible but this actually didn't require any configuration at all. Which is very nice, IMO.

On a side note, if anyone knows of a better way to calculate the real size of a SOAP message, please let me know

If your code executes in an ASP.NET environment, you can safely use the HttpContext.Current.Items dictionary for this. If your code executes in a WCF environment, you can store these things in the OperationContext. I don't want my code to be tightly coupled to either ASP.NET or WCF, so i wanted some kind of abstraction. This is the approach that i came up with.

First, we have the IRequestState interface:

    public interface IRequestState
    {
        T Get<T>(string key);
        void Store(string key, object something);
    }

This just offers a way to store objects and retrieve them. That's pretty much al we need, right?

Then we have the ASP.NET implementation:

    public class AspNetRequestState : IRequestState
    {
        public T Get<T>(string key)
        {
            return (T)HttpContext.Current.Items[key];
        }
 
        public void Store(string key, object something)
        {
            HttpContext.Current.Items[key] = something;
        }
    }

Very simple stuff... the AspNetRequestState implementation simply uses the HttpContext.Current.Items dictionary underneath to store and retrieve the objects.

For WCF, it is slightly more complicated. Every WCF call is an operation and it has a context as well, which is provided through the OperationContext class. The OperationContext class doesn't have an Items dictionary like HttpContext does, but it does have a way to add extensions to the context. We can use this extensions mechanism to store state which should be kept around for the duration of the current WCF operation. First, we need to define our Extension:

    public class MyExtension : IExtension<OperationContext>
    {
        public MyExtension()
        {
            State = new Dictionary<string, object>();
        }
 
        public IDictionary<string, object> State { get; private set; }
 
        // we don't really need implementations for these methods in this case
        public void Attach(OperationContext owner) { }
        public void Detach(OperationContext owner) { }
    }

The IExtension interface that we must implement defines the Attach and Detach methods but we don't really need them for what we're trying to do. This extension simply initializes a Dictionary instance and exposes it with a public getter. Now we can easily create our WcfRequestState implementation:

    public class WcfRequestState : IRequestState
    {
        private static IDictionary<string, object> State
        {
            get
            {
                var extension = OperationContext.Current.Extensions.Find<StateExtension>();
 
                if (extension == null)
                {
                    extension = new StateExtension();
                    OperationContext.Current.Extensions.Add(extension);
                }
 
                return extension.State;
            }
        }
 
        public T Get<T>(string key)
        {
            if (State.ContainsKey(key))
            {
                return (T)State[key];
            }
 
            return default(T);
        }
 
        public void Store(string key, object something)
        {
            State[key] = something;
        }
    }

Pretty simple as well, and pretty similar to the AspNetRequestState implementation. The AspNetRequestState implementation is able to simply use the HttpContext.Current.Items dictionary, which we can't use here. So when we want to access the 'State' dictionary in this implementation, we look it up in the current OperationContext's Extensions collection. If it's not there yet, we add a new instance of our MyExtension class to the OperationContext's Extensions collection.

Now we can use this wherever we need to store something for the duration of the current request, regardless of whether we're executing in an ASP.NET or WCF context. Just configure your IoC container to create instances of AspNetRequestState whenever an IRequestState instance is needed in your WebApplication, or configure it to return WcfRequestState instances in your WCF service. The code that needs to store some request state will no longer have to resort to using ThreadStatic fields, and it doesn't need to know about it's runtime environment either. It merely needs an instance of IRequestState.

We were clueless as to why the calls were actually blocking. We had a few scenarios that would usually (but not always) trigger the bug, but it also occurred in other situations, seemingly at random. So my coworker spent many hours trying to find out why it was happening. After a lot of debugging on his part, he found out that sometimes our WCF proxies weren't being disposed, which left Channels to the service open which caused new proxies to block whenever the number of allowed concurrent channels was reached. My first reaction was "huh, how could that be? i'm disposing of them in the page's PreRender event...".

First of all, i'm far from an ASP.NET guru, so those of you who do know a lot about it probably already understand the problem. I figured that the PreRender event would always occur, and that it would be the best place to dispose the WCF proxy. That turned out to be a two-for-one brain fart on my part. First of all, the PreRender event is obviously not fired when you do a Server.Redirect or Server.Transfer, so whenever we navigated to another page, we did not dispose our WCF proxy. Secondly, Page inherits IDisposable, which i completely missed apparently. So, had i simply overridden the Dispose method and dispose the proxy in there before calling base.Dispose() and then we would've never had this problem to begin with.

Lesson of the day: no matter how careful you try to be, you can still fuck up pretty bad sometimes

Update: i actually used the PreRenderComplete event instead of the PreRender event... still, a bad place to dispose of disposable objects

I typically use the following options:

For my binding configuration i usually set the maxReceivedMessageSize, maxStringContentLength and the maxArrayLength properties to their maximum values:

This example shows these settings for the netTcpBinding... i've also used them with the wsHttpBinding. Not sure how well it works with other bindings though.

I also set the maxItemsInObjectGraph setting of the DataContractSerializer to make sure i don't hit the default limit if i have to send a large object graph over the wire:

You have to apply these settings both server and client side to get it working properly and you need to refer to these settings in your service and endpoint settings:

Now, i don't recommend sending such large amounts of data through WCF services... but in the case of using my Request/Response service layer, the amount of data you're sending over the wire pretty much depends on which kind of requests (and how many of them) you're batching so i think it's better to make sure that at least the configuration allows for it. So obviously, it's best to keep an eye on the size of your messages to make sure you're not doing anything crazy. Being able to send your entire database over the wire doesn't mean it's a good idea to actually do so

Ever got a client-side exception that looked like this?

[SocketException (0x2746): An existing connection was forcibly closed by the remote host]
   System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) +73
   System.ServiceModel.Channels.SocketConnection.ReadCore(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, Boolean closing) +110

[CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:29:59.8590000'.]
   System.ServiceModel.Channels.SocketConnection.ReadCore(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, Boolean closing) +183
   System.ServiceModel.Channels.SocketConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout) +54
   System.ServiceModel.Channels.DelegatingConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout) +32
   System.ServiceModel.Channels.ConnectionStream.Read(Byte[] buffer, Int32 offset, Int32 count, TimeSpan timeout) +32
   System.ServiceModel.Channels.ConnectionStream.Read(Byte[] buffer, Int32 offset, Int32 count) +53
   System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count) +37
   System.Net.Security.NegotiateStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) +131
   System.Net.Security.NegotiateStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) +28
   System.Net.Security.NegotiateStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) +223

[IOException: The read operation failed, see inner exception.]
   System.Net.Security.NegotiateStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) +333
   System.Net.Security.NegotiateStream.Read(Byte[] buffer, Int32 offset, Int32 count) +79
   System.ServiceModel.Channels.StreamConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout) +72

[CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:29:59.8590000'.]
   System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) +7594687
   System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) +275

Rather messy, no? Does it give you any clue as to what could possibly be wrong? Nope. This particular client-side exception occurs when something goes wrong server-side, at some point after you've already returned your return value in your service implementation. Of course, you don't actually see it happening server-side. So i tried setting IncludeExceptionDetailInFaults to true on the service implementation... didn't make a difference. I set IncludeExceptionDetailInFaults to true on the service host but that didn't work either. Sigh.

After some Live Searching (i was actually googling, but let's make Microsoft think at least someone outside of Redmond uses Live Search) i discovered that you can enable WCF tracing. Bingo! Why didn't Juval Lowy's book mention this? It's supposed to be the WCF Bible.... Oh well, thanks to Google, i mean Live Search, we now know how to enable WCF's tracing:

  <system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.ServiceModel"
              switchValue="Information, ActivityTracing"
              propagateActivity="true">
        <listeners>
          <add name="wcfTraceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="WcfTrace.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>

You can also use the Service Configuration Editor tool which is available in the Windows SDK, but spare yourself the pain of that tool and just copy/paste this xml in your config file.

Now run the service again, and do whatever it was that triggered the weird client-side exception. After the exception occurred, open the WcfTrace.svclog file with either an editor (it's not very readable though) or with the Microsoft Service Trace Viewer tool (which is not too bad actually).

When i opened my trace output, i immediately saw a red item in the Activity list... so i clicked on it, and i finally saw the problem:

There was an error while trying to serialize parameter http://tempuri.org/:ProcessReadOnlyRequestsResult. The InnerException message was 'Maximum number of items that can be serialized or deserialized in an object graph is '65536'. Change the object graph or increase the MaxItemsInObjectGraph quota. '. Please see InnerException for more details.

There we go... the client-side exception was terribly useless, but this is the best kind of exception: not only is it clear about what's wrong, it even gives you the solution to the problem. Btw, if you get that client-side exception, it doesn't mean that your problem will be the same as the one listed here. It could literally be anything if it doesn't happen inside of your service implementation. I've seen the same client-side exception when one type somewhere in the object graph didn't have a DataContract attribute, for instance.

So anyways, do yourself a favor and enable WCF tracing while you're still in development... it could save you a lot of time.

Oh and bonus points go to whoever points out which of WCF's many configuration settings actually make the real exception appear in the client-side stacktrace

Thanks to my request/response service layer, those are two service requests that will be performed in one service call. On the server side, these two requests are dealt with separately. But they merely retrieve data from the database. Wouldn't it be cool if those 2 queries were performed in one database roundtrip instead of two? Wouldn't it be cool if we could batch the queries that will be performed by read-only service requests into a single database roundtrip? It sure as hell would be. Implementing this was one of those irresistible challenges you just can't say no to, so from now on we can actually do this. I'm not gonna get into the actual implementation of how I got it working (check the code in the library for that if you're interested), but i will show you how you can do this in your application.

First of all, if you have requests that merely return data, inherit from ReadOnlyRequest instead of the usual Request type:

The handlers for these requests should inherit from the ReadOnlyRequestHandler base class instead of the usual RequestHandler class. Btw, my ReadOnlyRequestHandler class inherits from my UoWRequestHandler class, which requires a IUnitOfWork instance to be passed to the constructor. So we need to put an IUnitOfWork parameter into the constructor along with our other dependencies if we want the IOC container (or the request processor) to pass us a valid IUnitOfWork instance.

The ReadOnlyRequestHandler class defines two abstract methods: the AddQueries and GetResults method. Both are passed an instance of IQueryBatcher and the actual request object so you can use the request parameters if there are any.

In the AddQueries method, you simply add the queries this request needs to perform to the batcher (with a string key value of course for later retrieval), and in the GetResults method you can get the results (with the key values used in AddQueries) back from the batcher and you can construct your Response object. The GetResults method will be called after each ReadOnlyRequestHandler for the current request batch has added the queries to be performed to the batcher. The queries are then all executed, and each ReadOnlyRequestHandler will have its GetResults method called so each handler can construct the proper response.

And that's it basically... The calling code doesn't even change.

Now there are obviously some limitations. If you mix ReadOnlyRequests with other Requests, then each ReadOnlyRequest will be handled as if it were a regular Request and they will each get their very own IQueryBatcher instance. I don't think there's any strategy to automagically determine which ReadOnlyRequests can be batched together while still correctly executing the other Requests since those requests might influence the results of ReadOnlyRequests that are present further in the batch.

Anyways, you can find an updated version of the library here. Check it out, it's some pretty slick shit, if i do say so myself

Note: i only added this stuff today, so the previous build (080729) doesn't have this yet, in case you only downloaded that today, and the stats show that some of you actually did download it

Introduction

When you're trying to design a service layer API, there are two things you always need to be very careful of. The first is making sure the API isn't chatty. A service layer is usually deployed on another physical machine than the client layer, so you want clients to be able to do everything they need to do with a minimum of roundtrips, because those are after all rather expensive. The second thing you want to avoid is the implicit coupling between the client of the service and the service itself. In your quest to avoid the chatty interface, you might start grouping several service operations together in more coarse-grained operations to avoid the chatty communication that might otherwise occur. This can be good from a performance point of view, but it usually introduces a certain implicit coupling between the service and the client, because a specific grouping of operations might be beneficial to one client, but might be completely inappropriate to another type of client of the service.

I really had difficulties coming up with an approach that offered nice coarse-grained service interfaces while at the same time making sure the interfaces weren't too 'driven' by a client's specific requirements. So i basically wanted a way to keep my service operations as specific as they could be (very fine-grained), while avoiding the pitfall of chatty communication by batching calls to the service layer together whenever it makes sense from the client's point of view. I eventually ended up with an approach that i've already documented here and here. Read those posts first before continuing with this post because the rest of this post builds upon the content of the previous posts.

The idea is to basically consider each service operation as a request which can have a response. For each request that you define, you need to provide a handler which does whatever it needs to do to handle the request and returns a response, or an empty response if no response is needed for a specific request. You then only need one service method which receives incoming requests, delegates them to the proper handlers, and returns each response in the order of the incoming requests. On a side note: this approach probably doesn't sit well with many SOA people, but then again, i couldn't care less about SOA. I just want good software no matter what acronym i can use to describe it.

Anyway, i like this approach so much that i wanted to make it available to whoever is interested in it. You can find it in my open source library which you can find here. I won't go into the details of the implementation, because those have mostly been covered already in my previous posts on this subject. The rest of this post focuses solely on how you can use this approach in your projects.

Defining Requests and Responses

The following two base classes need to be used to define request and response types:

Suppose you have a service operation that retrieves a list of products based on some parameters the user could provide in the UI. You would define the request like this:

And the response would look like this:

Keep in mind that these types always need to be marked with the Serializable attribute and that these types need to be in an assembly that you can share between both the client and the service.

Handling Requests

Incoming requests are handled by a class which implements the IRequestProcessor interface:

For each request that is received, the request processor will create a request handler which must be of the type IRequestHandler<TRequest> where TRequest is the type of the request instance. The request object is then passed along to the handler's Handle method, which will return a proper Response object.

The simplest way to create a request handler is to inherit from the RequestHandler<TRequest> class, like this:

The request processor uses the Castle Windsor Inversion Of Control container to resolve and create the instances of the request handler types. This allows you to use dependency injection for your request handlers. In the example posted above, you can see that the constructor of the handler takes an IProductRepository instance. Because the Windsor container also knows about the IProductRepository component in my application, it can correctly instantiate the GetProductOverviewsHandler instance with a valid IProductRepository instance. Keep in mind that this is optional though. You don't have to use dependency injection for your request handlers if you don't want to.

If you do want to use it, your application will have to use the same Windsor container instance as this library does. To make this possible, the library contains the following class:

By default, an empty container is created which you can access (and thus, configure) through the IoC.Container property. Or if you want the library to use your own Windsor container instance you can simply set the instance and then the library will use your container. For the moment, it is not possible to use another container (like StructureMap or Unity) yet, but that possibility might be added if people want it, or if someone submits a patch

Obviously, you need to register your request handlers somewhere in your application code, preferably before you start hosting the service layer. You can do that like this:

That basically registers each valid request handler (each type that inherits from the RequestHandler class provided by the library) that is present in the given assembly. You can also very easily provide your own custom base request handler, in case you want to provide some extra stuff. You'd simply need to inherit from the library's RequestHandler class, add whatever it is you need, and let your request handlers inherit from your new class instead of directly inheriting from the library's RequestHandler.

Hosting The Service Layer

There are a lot of options for hosting the service layer. Most people will probably host it as a WCF service so we'll cover that scenario here. The service contract looks like this:

This is practically identical to the IRequestProcessor interface shown earlier in the article. The difference is that IRequestProcessor uses no WCF attributes. The actual implementation of IRequestProcessor is completely decoupled from WCF as well so you can use this approach without having to use WCF if you want to. The implementation of the IWcfRequestProcessor simply forwards each call to the real request processor.

Notice the usage of the KnownTypeProvider class. This makes sure that each of your Request or Response derived types will be properly recognized as a KnownType. All you have to do is register them, like this:

This registers each Request or Response derived type from the sharedAssembly reference (which is a reference to the shared assembly containing the request and response types) with the KnownTypeProvider. You need to do this before you start hosting the service. It's best to combine this task with the registration of your request handlers.

The actual hosting of the service is typical WCF and is entirely up to you. Here's a simple example of self-hosting the service in a console app:

You'll most likely prefer an alternative way of hosting the service, but again, that is entirely up to you and is typical WCF stuff. All you need to know is that the service contract is the Brion.Library.Common.WCF.IWcfRequestProcessor interface, and the actual implementation of the service is the Brion.Library.ServerSide.WCF.WcfRequestProcessor class.

Communicating With The Service Layer

In your client layer, you can choose between using a direct proxy type for the IWcfRequestProcessor service, or you can use the Dispatcher class. The Dispatcher class is somewhat of a wrapper around the direct proxy to make it easier to use and to get a nicer syntax. The Dispatcher class implements the IDispatcher interface:

There are 3 implementations of this interface. The first is the Dispatcher class itself, which has a dependency on an IRequestProcessor instance. The second is the WcfDispatcher class which inherits from the Dispatcher class and will supply its base class with a RequestProcessorProxy instance to satisfy the IRequestProcessor dependency. The third implementation is the DispatcherStub class, which is only useful for your tests. If you want to use dependency injection through the container, you can register the correct components at client start-up time like this:

The container will then have the correct configuration to provide you with IDispatcher instances that will correctly use the RequestProcessorProxy underneath. If you don't want to use the container client-side, you can simply instantiate instances of the WcfDispatcher class.

So, how do you use the dispatcher? It's pretty easy really. Suppose you want to dispatch two requests to the service, you could do so like this:

The requests won't be dispatched to the service until you actually call one of the Get method overloads for the first time. So you can add as much requests as you like, they won't be dispatched until you try to retrieve a response. And when those requests are dispatched, it is done in only one roundtrip.

If you just want to dispatch a single request, you could do so like this:

Keep in mind that you do need to define the service endpoint in your client-side application's configuration file. You also need to register the KnownTypes client-side before you start using the Dispatcher or the service proxy in the manner discussed earlier.

Stubbing The Service Layer During Testing

If you write tests for your client-side code, you'll be glad to hear that i've included a DispatcherStub class which makes it easy to prepare responses to return and to inspect requests that were sent from the code you're testing. The approach i outlined in this post doesn't really lend itself to easy mocking, so the DispatcherStub class makes it all much easier.

First of all, make sure your client code always uses references of the IDispatcher type instead of directly using the Dispatcher or WcfDispatcher types. Then in your tests, inject DispatcherStub instances instead of real Dispatchers. The DispatcherStub class provides a few extra methods which you can use in your tests:

The SetResponsesToReturn and GetRequest methods make it much easier to stub the service layer than traditional mocking would.

Something you'll often want to test is that requests have been sent with the correct parameters:

Time to wrap it up

Again, i really like this approach. Unfortunately i haven't had the chance to use this in a real project yet, but based on my experiments i'm already very happy with it and am looking forward to use this in a real project. If you'd like to use this approach, download the library here, play around with it, try it out, try to break it, and let me know what needs to be fixed/changed/added. Or send patches

This works, but i don't want to write a class every time i want to specify some known types of a base type in a service method. So i modified that KnownTypeProvider class so that we can now do the following:

This registers each derived type of Request and Response in the mySharedAssembly reference (of type Assembly) with the KnownTypeProvider. You can register as many known types for as many base types as you want. Obviously, you have to do this before you start hosting your service. You also need to do this client-side, before you start using your service proxies.

You're probably thinking "wait, won't that return all registered known types for every service call where you use this stuff?". That wouldn't be good, so i took care of that. The ServiceKnownType attribute of WCF requires your class to implement a method which receives a parameter of type ICustomAttributeProvider and which returns a list of types. The ICustomAttributeProvider parameter is actually a MethodInfo instance at runtime. This makes it possible to inspect the current service method's parameters and return type. That information makes it possible to only return the KnownTypes that are relevant to the current service call. All of this sounds expensive with regards to performance, so obviously this is all cached... so you only take the performance hit on the very first request of each service method where you use this.

The KnownTypeProvider makes it extremely easy to register your KnownTypes in a generic way, can be reused across multiple service methods and it only returns the relevant KnownTypes for each service method. And it does so with a minimum of performance overhead.

You can find the code in my public svn repository as a part of my utility library (the tests can be found here). At this moment it is one of the only classes in the library, because i still have to add some other stuff before i'll put a 'proper release' online

I wanted to keep providing specific service methods for each kind of request, but each service implementation would delegate the handling of the requests to the Process method, which in turn would delegate the handling of the request to a specific request handler type which was associated with the request type. So basically, all of these specific service contracts which extend this service don't really offer me anything extra.

So now i'm wondering why i'm even bothering with the specific services anymore... it only leads to more work: more service interfaces and more proxies and in the end, everything is routed to the Process method. So what's the point of these specific services anymore if you don't have batching support out of the box? If i have to go with a generic Process method to get batching support (again, which i consider a MUST-HAVE feature), why am i even bothering with Services at all? Essentially, i'm using a service bus with WCF. Why shouldn't i just move to NServiceBus which is actally perfectly suited for this kind of work?

For the record, i'm not trying to flame or anything... i really want to get some answers to the following question: why shouldn't i drop WCF and the whole service layer thing in favor of a real service bus and Messaging in general?

The first take was pretty good, after all it got Ayende-d which is the highlight of my blogging career so far . In his post, he was pretty positive about my implementation, with one small exception:

"About the only thing that I would strive to improve there would be the need to explicitly register request & replies. I would try to get something convention based there. Maybe something like Request, and then have IHandler and route the whole thing through the container again."

Let's give that a shot

Previously, the base implementation of the service routed the call to the correct RequestHandler like this:

And then the service implementation would provide an implementation of the GetHandlerTypeFor method. In that implementation, you somehow had to map the type of the incoming Request to a handler. In the code that i posted i used a dictionary-based approach. You could've used a couple of if statements as well. The point is that you had to do that mapping which is indeed somewhat annoying.

First, we'll add a new interface on top of the IRequestHandler interface:

We also modify the base RequestHandler class to provide a derived generic class:

The only reason why i still have the base RequestHandler type is to make it easier to register the RequestHandler types with the container (which i'll show below).

A specific RequestHandler can now be defined like this:

Right, now we can register all of our RequestHandler types with the container:

So now each generic RequestHandler type is registered through the generic IRequestHandler type.

Our base Service implementation now looks like this:

And now you no longer need to map the Request type to the RequestHandler type yourself since the container now takes care of that for us.

Similar to my query batcher, i wrote this simple WCFCallBatcher class:

and now we can rewrite the client code like this:

Yes, we've got more lines of code now, but i like this block of a code a lot more than the earlier one. This is much more readable.

What happens if you have the following code client-side:

The service variable is a reference to a WCF service proxy. This means that this causes 2 remote service calls. I really hate unnecessary/excessive roundtrips, so i would rather retrieve this data from the service in one roundtrip. Unfortunately, this is not something that is supported by WCF out of the box, so if you want to do this you have to do it yourself. There are a couple of options, so i started browsing the web. Once again, it's Ayende to the rescue. The approach he suggests is a bit cumbersome compared to how you'd normally design your services, but it does offer a great deal of flexibility and it allows you to nicely batch your requests. So i figured i should try implementing this approach.

The idea is to provide a service method that looks like this:

Each Request corresponds to what used to be a normal service method, and this method returns a Response for each Request. In Ayende's post, he suggest offering this as the only service method. I won't go that far though. I'll offer this method, and each 'normal' method allthough those methods will also use Request types as input variables and Response types as return values. The idea is to be able to use each service method individually, or to have multiple service methods executed in one roundtrip through the Process method.

We need a way to define Requests and Responses, so we create the following classes:

For now, these are empty but i'm pretty sure i'll add a few members to these later on. Then we define specific Request and Response types for the functionality our service needs to offer:

We then create a base interface that each service will implement (along with more specific service interfaces):

The KnownTypeProvider is responsible for providing a list of types that should be treated as KnownTypes during serialization/deserialization. We could also list each type that derives from Response/Request but that will become a long list, so i went for this approach. The code of the KnownTypeProvider class looks like this:

Our real service now looks like this:

To handle these requests, i came up with the following RequestHandler type:

And the implementation of one of these concrete RequestHandlers looks like this:

Now we have to make sure we can actually use this RequestHandlers in a generic manner. I came up with the following base class for my services:

And the real service then looks like this:

At this point, using a dictionary to map the Request types to the RequestHandler types seems silly, but this is just a small part of the service, more methods will be added so more Request and RequestHandlers will be handled, and in that case i prefer to use a dictionary lookup over a big if statement

So now i can do this client-side:

And it only uses one remote call which will be much better for performance. At this point, the syntax is not so nice, but i'll probably provide something similar to my query batcher class so that should improve readability.

So that's pretty much it... it takes some effort to set this up, and there's still more to be done (dealing with exceptions in one of the requests for instance) but once you've got it set up, i kinda like it. Sure, implementing service methods takes more code than it used to because of the extra classes involved, but they do offer a few very important benefits. You may have noticed that the RequestHandler types receive all of their dependencies through the constructor, and that they are created through the IoC container. This means i can very easily add/remove/change dependencies in my handlers without having to modify code in other places. It also means i can test my service implementations in a thorough manner while providing mocked dependencies instead of the real ones. Another big advantage is that i can add optional parameters to my Request types and thus, offer more functionality through my RequestHandlers without having to update the services and the proxies.

So all in all, while this approach requires to you write more code at first, i think it might actually end up giving you more flexibility for changes later on, while offering you much more control over certain performance characteristics.

That's a lot of code, even though only ONE line will differ from the other service methods in this service. Let's clean up this mess, shall we? Exception handling is a cross cutting concern so we might as well put it in one place (at least, one place for each different kind of exception handling that you need). We'll use PostSharp to define an ApplyServiceExceptionHandling aspect:

And now we can modify the earlier service method to this:

That's a lot cleaner than the previous version right? Actually, this service has more than one service method so we're better off moving the ApplyServiceExceptionHandling attribute to the class level instead of the method level:

now we can get rid of all of the exception handling code in each service method, but each one will have exception handling applied to it because the exception handling aspect is applied to the class, and thus, to each method of that class. And if you need to modify your exception handling (to handle TargetInvocationExceptions with BusinessExceptions as InnerExceptions for instance?) you'd only have to do this in one place.

Btw, i'm aware of WCF's IErrorHandler interface (which allows you to handle exceptions in a general manner as well)... i just don't like it

Last year, Tim Scott posted this very good article on how to distribute NHiberate entities through WCF services. In it, he mentions this:

We should mention that this application uses NHibernate 1.02. As of this writing, NHibernate has released version 1.2. We tested the application with NHibernate 1.2 before changing to the NetDataContractSerializer, and verified that it exhibits the same problem. We have not verified that the solution described here will work with NHibnerate 1.2, although we expect it will.

I created a small sample that uses his solution with NHibernate 1.2 and my Northwind example and in this post, we'll walk through the sample. But first, a little bit of background information. By default, WCF services use the DataContractSerializer to serialize/deserialize types. But when you're using NHibernate, you're most likely using some of the persistent collection types and proxies. Some people just want to use the same types serverside and clientside. For instance, retrieving a Customer object with his Orders collection through a service, manipulating one of the Order objects clientside, perhaps remove an order from the collection, send the object graph back to the server, attach it to an nhibernate session, persist the whole thing and be done with it. I'm still somewhat undecided as to whether or not this is a good way of doing things but that's beside the point of this post. Default WCF services do not make this possible but you can make it work rather easily. WCF includes the NetDataContractSerializer which differs from the normal DataContractSerializer in that it includes CLR type information in the serialized data. This makes the above scenario possible. You do lose all interoperability with other platforms, and your clients need the same types you use server side.

First of all, this is the service contract:

The [UseNetDataContractSerializer] is not a standard WCF attribute, but is a part of Tim Scott's solution. You can find the implementation of the attribute in his post, or in my code which you can download at the bottom of this post. It basically comes down to this: the serialization behavior of operations decorated with this attribute is modified to use the NetDataContractSerializer instead of the default DataContractSerializer.

The implementation of the service contract looks like this:

First of all, this is just an example, that's why the ISessionFactory is created within the service implementation, in a real system i wouldn't do this. Anyway, the GetCustomersWithTheirOrders method returns a list of all Customers, with their Orders. An Order contains references to an Employee and a Shipper. The Employee and Shipper will not be retrieved from the database, but NHibernate will initialize them with proxy objects to enable lazy-loading. Obviously, the lazy-loading won't work once you're outside of the scope of the NHibernate session, but it's important to note that there will be proxies in our object graph.

At first i had decorated my entity classes with the [DataContract] and [DataMember] attributes but that really messed up the deserialization of the proxies. Now my Entity classes are only decorated with the [Serializable] attribute. NetDataContractSerializer should work in both cases, but i only got it working properly when they were [Serializable].

Right, so now we have the service contract and the implementation, it's time to host it. My solution contains an example of a console host as well as a service hosted in IIS. For this post, i'll just go over the console host and console client. You can find the IIS example (which is practically identical anyway) in the downloadable solution.

So, in the console host project, i have the following in my app.config file:

The service is then started like this:

As you can see, nothing special here... it's pretty much your typical self-hosting WCF example. Except that the maximum message size has been increased since we'll be sending large object graphs over the wire.

The client configuration looks like this:

And the client uses the service like this:

I didn't write a test for this to prove it works, but if you step through it and you explore the returned object graph using the debugger, you'll see that everything is of the correct type... even the proxies make it through correctly. Manipulating the graph and using the PersistCustomer method also works, but it's not in this example anymore because i didn't wanna pollute my database every time i ran it to test it.

I did have problems when i was hosting the service both in the console and through IIS at the same time... some requests would then fail to deserialize the returned graph properly. If you don't run both hosts at the same time, it works. I have no idea why this caused issues, but after wasting a few hours trying to figure it out, i just gave up. You can reproduce it by running the ServiceConsoleHost, ServiceClient and ServiceWebClient projects in the solution. Sometimes that just works as well, so you may have to try a few times to get it to fail. So if anyone can shed some light on that issue, i'd be most interested in hearing about it

You can download the solution here. Note that this is a Visual Studio 2008 solution...