I think I have mentioned it before (if I haven’t, I’ll surely do now) that WCF isn’t about web services. It’s about services, as a whole. There are no restrictions on where and how you’d like to host your service. Given this, I’ll show three easy and quick ways in this post to host your WCF services in managed applications:
- Host with an application having a UI
- Host with a Windows Service
- Host with the WCF-provided host
The first two options are essentially the same, the only difference is that Windows Services don’t have a user interface, and they have their own ways of installation and running. But let’s treat them as separate objectives.
We’ll use the simplest form of applications, the Console Application to self-host our WCF service. So if you’re ready (created a console app), add the necessary code files to it (the service class, and the service contract interface, plus an app.config). I’m sure you’ll be able to write a simple service by now, and the whole purpose of this post is to show you how to host your written services, instead of how to write them, so I’ll omit the creation of a service. Let’s assume you’ve a service called MyService, with a contract interface IMyService. Given this, you’d host your service by using the ServiceHost class:
Well we’ve written a service, specified the contracts, operations, custom data object and the structure of our SOAP message, and now, it’d be time to share it with the world. But how should we do that?
The answer is easy, we need to define endpoints to which clients can connect, and gather (or post) the required information from/to us. An endpoint is built up from three things, which are the ABCs of them. These are:
- Address: the URL of the service, with which you can reach it. The address of a WCF service can expose the following properties:
- Scheme: the scheme is the very beginning of the address, typically http://, but this is not the same thing as the protocol, even though it’s called the same.
- Machine: the name of the machine, for example localhost, or http://www.somedomainname.com, or the IP address.
- Port: the optional port number (:8080).
- Path: the path of the service, can be multilevel. I think you can guess what’s it.
- Binding: the binding specifies how your service can be accessed it defines the protocol name, type, encoding, etc. You should imagine the binding as something which stores anything else than the message contract, and the address used to reach it. So security settings, metadata exposing, and a lot other things belong to here. There are some preinstalled bindings, which you can extend, or create entirely new bindings from scratch. I’ll provide a table of the installed bindings later in this post.
- Contract: you have seen it in work, we’ve defined it in the previous posts. The contract specifies the methods, operations to expose, custom data types, etc. The name of the contract is the same as the class or interface marked with the ServiceContractAttribute. If you’ve set the “Name” named parameter explicitly, then you should use the value you specified there.