WCF Service Layer in n-layered application: performance considerations

Question

Hi all. When I went to University, teachers used to say that in good structured application you have presentation layer, business layer and data layer. This is what I heard for more than 5 years.

When I started working I discovered that this is true but sometimes is better to have more than just three layers. Two or three days ago I discovered this article by John Papa that explain how to use Entity Framework in layered application. According to that article you should have:

• UI Layer and Presentation Layer (Model View Pattern)
• Service Layer (WCF)
• Business Layer
• Data Access Layer

Service Layer is, to me, one of the best ideas I've ever heard since I work. Your UI is then completely "diconnected" from Business and Data Layer. Now when I went deeper by looking into provided source code, I began to have some questions. Can you help me in answering them?

Question #0: is this a good enterpise application template in your opinion?

Question #1: where should I host the service layer? Should it be a Windows Service or what else?

Question #2: in the source code provided the service layer expose just an endpoint with WSHttpBinding. This is the most interoperable binding but (I think) the worst in terms of performances (due to serialization and deserializations of objects). Do you agree?

Question #3: if you agree with me at Question 2, which kind of binding would you use?

Looking forward to hear from you. Have a nice weekend!

Marco

Answer 1

Question #0: is this a good enterpise application template in your opinion?

Yes, for most middle-of-the-road line-of-business applications, it's probably a good starting point.

Question #1: where should I host the service layer? Should it be a Windows Service or what else?

If you're serious about using WCF services, then yes, I would recommend self-hosting them in a Windows service. Why? You don't have to have IIS on the server, you don't have to rely on IIS to host your service, you can choose your service address as you wish, and you have complete control over your options.

Question #2: in the source code provided the service layer expose just an endpoint with WSHttpBinding. This is the most interoperable binding but (I think) the worst in terms of performances (due to serialization and deserializations of objects). Do you agree?

No, the most interoperable would be a basicHttpBinding with no security. Any SOAP stack will be able to connect to that. Or then a webHttpBinding for a RESTful service - for this, you don't even need SOAP - just a HTTP stack will do.

What do we use??

• internally, if Intranet-scenarios are in play (server and clients behind corporate firewall): always netTcp - it's the best, fastest, most versatile. Doesn't work well over internet though :-( (need to open ports on firewalls - always a hassle)

• externally: webHttpBinding or basicHttpBinding, mostly because of their ease of integration with non-.NET platforms

Answer 2

Here are my 5 cents:

0: yes

1: I would start by hosting it in IIS because it's very easy and gets you somewhere fast.

2: If you need security then definitely yes, go with WSHttpBinding (or maybe even wsFederationHttpBinding if you want some more fance security). It performs quite fast in practice even though, as you say, it does have some overhead, and can be quite hard to call from other platforms (such as java).

3: N/A

Finally, remember to define your services' data-contract objects in a separate assembly that can be referenced both from the service dll and the consumer in your ui layer.

Answer 3

Did your teachers also tell you why you should create such an architecture ;-) ? What I am missing in your question are your requirements. Before any of us can tell you if this is a good architecture or template, we have to know the requirements of the application. The non functional requirements or -illities of an application should drive the design of an architecture.

I would like to know what is the most important non functional requirement of your application? (Maintainability, Portability, Reliability or ...). For example take a look at http://en.wikipedia.org/wiki/ISO/IEC_9126 or http://www.serc.nl/quint-book/

I think that we architects should create architectures based on requirements from the business. This means that we architects should make the business more aware of the importance of non functional requirements.

Question #0: is this a good enterpise application template in your opinion?

You use the layers architecture pattern, this means that layers could evolve independent of each other more easily. One of the most used architecture patterns, note that this pattern also has disadvantages (performance, traceability).

Question #1: where should I host the service layer? Should it be a Windows Service or what else?

Difficult to answer. Hosting a service in IIS has two advantages, it scales easier and traceability is easier (WCF in IIS has loads of monitor options). Hosting a service in a Windows Service gives you more binding options (Named Pipe binding/ TCP binding).

Question #2: in the source code provided the service layer expose just an endpoint with WSHttpBinding. This is the most interoperable binding but (I think) the worst in terms of performances (due to serialization and deserializations of objects). Do you agree?

Performance wise the WSHttpBinding costs more, but it scores high on interoperability. So the choice depends on your non-functional requirements.

Question #3: if you agree with me at Question 2, which kind of binding would you use?

Named Pipes and TCP binding are very fast. Name Pipe binding should only be used when communicating in a single machine. TCP binding could be an option but you have to open a special port in the firewall.