WCF - Week 3

WCF is a framework for building service-oriented applications. The flexibility of the framework makes it very powerful, but that power requires some wisdom in the implementation. In this post, there will not be many answers, but I hope to help you determine what questions to ask.

Sharing assemblies between the server and the client

Many developers like to do things such as override ToString(). Not surprisingly, that code will not survive being sent over WCF. It is possible to put the objects that are sent across into a common assembly and shared on the server and client side. Using the KnownType attribute WCF will deserialize into the correct object with code intact.

This hurts a fundamental part of SOA. Ideally, you point the application at the service reference and it builds the proxies for you. If you are going to have a shared component, then way not simply ship a binary that accesses the web services itself? There are times when a shared assembly makes sense, but make sure there are really strong reasons for doing so.

Naming of methods

When you are getting started with WCF, you may decide that you have multiple methods that return the same information, but use different parameters to find the information to return – method overloading. The first time you try to run a service created this way, it will fail. It is possible to make it would using the Name parameter on the OperationContract attribute.

Avoid doing this. Most importantly, this is because there can be a different of what methods the consumer of the service will see, based on how they choose build the proxy class. Keep it simple, Keep things consistent. Architecturally, web service development is not OOP development. The concerns and methodologies are fundamentally different.

Separation of Concerns

It is tempting to write all of the code in the class that implements the interface – known as the contract in WCF terms. Instead, consider creating a separate layer where the code is implemented outside of any relationship to WCF. The contract and implementation then becomes a very thin layer responsible for handling the incoming calls, the authentication and authorization, then forwarding off to the actual implementation.

Why would you want to do it this way? The primary reason is that if you need to change how your web services interact with the outside world, you do not need to change how the service is implemented internally. For example, going from one-way communication to duplex communication is a fundamental shift in the implementation of the web services, however what the implementation does on the backend may not need to change at all. Additionally, it may be necessary to have both services up at the same time, one service is running async and the other synchronous. Having the backend code separated from the service code makes this kind of flexibility easy.

Being Restful

REST and JSON are all the rage, and WCF absolutely supports the ability to create restful services that return JSON. The result is very fast, and very nice. If your clients are web based and not using WCF then having REST and JSON is a viable option. It is possible to use rest on clients that have WCF however, you lose the benefit of having generated objects for you. This means that you would need to hand-roll all of the data objects that would normally be created automatically when creating your service reference. If there is a need to support both web pages and REST, it is possible to support two endpoints from the same code. In this way, the thick client has all the benefits of using WCF, and the web pages only need to worry about JSON. This option is much simpler if you have maintained a separation between the contract implementation and the objects that do the real work.

Bindings

Bindings are a critical consideration. The decision to use one over the other can cause issues. Bindings are only a configuration setting, but depending on the change, the binding information will require an update on the client and the server. There are many types of bindings, here are the three most likely to be encountered when getting started

BasicHttpBinding

It is based on SOAP 1.1 specifications

It has less overhead than wsHttpBinding

Primarily to communicate with older webservices

By default, does not have any security options enabled.

wsHttpBinding

It is based on SOAP 1.2 specification

Significantly more options for in security

Provides ws-addressing, reliable messaging, transactions.

By default, uses message security and windows authentication

NetTcpBinding

If you are hosting in IIS, the webserver will require configuration to support NetTcp.

By default uses windows authentication and transport security

Requires WCF on both ends

Fast, efficient protocol recommended for intranet applications.

Specify Namespace in the ServiceContract

When you are just getting started, setting the namespace on the ServiceContract does not seem like an issue to worry about. Over time, the services that your enterprise uses grows you will run the risk of name collisions. Setting the namespaces minimizes this risk. Additionally, you can use the namespace to identify versions of your services. You should make sure to specify a namespace, but choose wisely. The namespace becomes a permanent part of the contract that other developers will depend on. For that reason you shouldn’t change it once it has been published.

SessionMode, ConcurrencyMode, and InstanceContextMode

When you are getting started, these are attributes that you don’t need to worry about. If you are starting a larger project these are issues you should take the time to understand. There is a relationship between SessionMode and InstanceContextMode, MSDN does a good job describing it: http://msdn.microsoft.com/en-us/library/system.servicemodel.session...

ConcurrencyMode has to do with the threading model that the service will use. Default the concurrencyMode is Single. This means only one thread will be running the code at a time. This is important to think about, in relation to how the service is hosted. Depending on your needs, the implementation can be made simplified by keeping the ConcurrencyMode as Single, and let IIS handle the threading issues as each call comes in.

Security

What kind of security are you going to use? Open ID, Live ID, Active Directory, or something you invented yourself? Create a working prototype of your Authentication and Authorization mode before you get deep into the code. Keep the security code high up on the stack. This will keep the code fast, since you won’t need to check security issues as often, and also simplifies testing.

Conclusion

Hopefully, you now have more questions than when you started reading. These are the kind of things that you will need to be aware of when doing any significant work in WCF – and it only just scratches the surface. WCF is an easy framework to get started with, but it is still possible to paint yourself into a corner.

Next week we will look at creating callbacks using the wsDualHttpBinding, which will help illustrate some of the issues I mentioned here.