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.
Gergely Koncz's blog 