SOA has been quite popular in recent years and is something to strive for. However, there are so many technology options for creating and hosting services. In addition, there exists many SOA definitions and ways of implementing SOA standards. We have bumped our heads and came close many times to slitting our wrists by using WCF. Below are my opinions on WCF and 2 other of the main technologies used to build services.
Requires the creation of DataContracts and OperationContracts. It follows a RPC style architecture.This has been for many years the defacto standard of implementing services using the Microsoft Stack.
- Huge support in .NET community as it is included by default in Visual Studio Templates.
- Big support from Microsoft.
- Lots of resources available.
- Add Service Reference is very easy to use.
- Many features
- Inflexible and brittle
- Difficult configuration and setup
- Huge learning curve
- Difficult to debug and host
- Difficult to add REST and JSON support
- Very limited content negotation support
- Lots of configuration required
- Add Service Reference provides many problems with re-use of code.
- As a developer, I hate working with this technology.
Microsoft’s answer to support REST. Use controllers to setup REST endpoints. Used within a Web project only.
- Built in Visual Studio templates.
- Similar programming style to MVC controllers.
- Easy to use and reasonably easy learning curve.
- Lots of resources available.
- Supports JSON, XML and FormData content types out of the box.
- Very new technology.
- Complicated Route configuration.
- Dependency Injection is difficult.
- Only REST is supported – Need to maintain separated code bases to support REST and SOAP.
- No code re-use between MVC types (controllers) and WebAPI types.
- Limited hosting options.
- Difficult to add custom content negotiation types.
ServiceStack is a bit of a different mind set as it is built using HTTP handlers. This is an open source project (stable since 2008) that was built using SOA and Integration best practices. It is built around Message Contracts (rather than OperationContracts) to which many big companies adhere to – such as Amazon and Google.
Benefits of message contracts: https://github.com/ServiceStack/ServiceStack/wiki/Advantages-of-message-based-web-services
For more info: https://github.com/ServiceStack/ServiceStack/wiki
- Metadata page that exposes all services and usages.
- Supports content negotiation
- Built-in data and content negotiation types: JSON, XML, CSV, JSV, SOAP, ProtoBuf, HTML, Text, byte, Stream, IStreamWriter
- Easily add custom content negotiation types.
- Multiple hosting options – Website, Console App, Windows Service
- One of the fastest serializers in .NET.
- One of the fastest ORMs in .NET.
- Plug-in model that allows the addition of features on global or service level (pipe and filter model).
- Support for most clients and formats.
- OSS from 2008 – free and many contributions
- Strong security model – built in support for OpenId 2.0 providers.
- OSS – most corporate companies prefer paid support structures.
- Lack of built-in Visual Studio templates – need to use NuGet
My conclusion is that ServiceStack looks very promising and as a development team we would love to through away WCF because of all the issues we have experienced over the years. We are currently building some prototypes and so far it looks good.