IT:AD:WCF/Concepts:The Whole Picture:Service Endpoints

If using IIS to host a netTcp endpoint, * Install WCF Activation, (Http activation and Non-Http Activation)
* Set [inetsvr]/Advenced settings/Enabled Protocols to http,net.tcp
* In [inetsvr]/{website}/Bidnings * as usual add one for http, * add a new binding net.tcp and put port/virtual directory as 8001:* </WRAP> <WRAP tip> it's often overlooked (and we'll cover it in more detail later on) but notice that identity is a sub element of endpoint element. In other words, it truly is part of equation used to match up the client to the service. </WRAP> ### Setting the Service Endpoint's Address ### In most cases the endpoint's address can be left blank, as it can be inferred from the Service's base service host address, which was derived from the location of the page within the IIS website. (eg: http://localhost:12485/Service1.svc) The only time it needs to be set is if the [protocol/address] combination is already being used. In our case above, the http protocol address is being used for 3 different cases. Hence why the metadata -- which also uses http, has to be made accessible via a different address. If the given address is not absolute, it tacks it on to the base service host address (ie, http://localhost:12485/Service1.svc/mex) >Gotcha: So why is the tcp one given an address? It would be unique enough -- but you can't get to a net.tcp port with the http://that you enherited from base address -- so you have to give it a complete url in order to be able to speficy the protocol. ***FAQ:*** * Why not just use the service element for the address, and be done with it? * Because a Service is the Operations/behavior, and those Operations/methods can be exposed under using different protocols/bindings/each at their own address. As each binding endpoint needs its own unique ABC (remember the description of an endpoint as a unique composite key), an address propery is needed to allow for that. * Let me just get this straight...if I were only exposing as tcp, and exposing metadata for it, I could leave both addresses blank? * Exactly! Each 'composite key' is unique (tcp+"" != "http"+"") so it wouldn't complain. * That said, by convention Visual Studio will expect to find the WSDL at the mex address, so it's not recommended that you do it that way -- let the mex endpoint have a "mex" address, as it's always done. ### Defining Service Endpoint's Binding ### Each of the service's element's endpoints will be used to define a the communication protocol, using the binding attribute. This will be set to the *type* of one of the predefined bindings (basicHttpBinding, wsHttpBinding, netTcpBinding): <system.ServiceModel> <services> <service name="ServiceFullName"> <endpoint address="" binding="basicHttpBinding" contract="..." /> <endpoint address="ws" binding="wsHttpBinding" contract="..." /> <endpoint address="net.tcp://...." binding="netTcpBinding" contract="..." /> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- the binding refer to default binding types already built into machine.config that may or may not yet be visible in your config file, but they would look like this if visible: --> <!-- <binding> <basicHttpBinding>...</basicHttpBinding> <wsHttpBinding>...</wsHttpBinding> <netTcpBinding>...</netTcpBinding> ... <binding> --> </system.ServiceModel> Note that each endpoint is referencing a specific type of binding (basicHttpBinding, wsHttpBinding, netTcpBinding, etc). These are the name of one of the several pre-packaged binding types that the .NET framework already has defined down in the machine.config. And in the most basic POC scenarios, that's all you would need. Unfortunately, in the real world, the default settings are never quite right for the job at hand, and have to be tweaked. That's what the bindingConfiguration attribute is for. >Note: If the default bindings are not in your config file, you first have to add the default stubs, in order to in turn create your own named binding instances. Use the bindingConfiguration attribute to name a specific instance of the binding configurations: <system.ServiceModel> <services> <service name="ServiceFullName"> <endpoint address="" binding="basicHttpBinding" bindingConfiguration="myBasicConfig" contract="..." /> <endpoint address="ws" binding="wsHttpBinding" bindingConfiguration="myWsConfig" contract="..." /> <endpoint address="net.tcp://localhost:9000/ourServices/Service1" binding="netTcpBinding" bindingConfiguration="myTcpConfig" contract="..." /> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- the binding and bindingConfiguration refer to the following named instances of special cases of default binding configurations: --> <binding> <basicHttpBinding> <!- example of a named binding, overrriding default basicHttpBinding settings--> <binding name="myBasicConfig" openTimeout="60" /> </basicHttpBinding> <wsHttpBinding> <!-- same concept, (named + overridding default values) just for the wsHttpBinding --> <binding name="myWsConfig" ... /> </wsHttpBinding> <netTcpBinding> <!-- same concept, (named + overridding default values) for the netTcpBinding --> <binding name="myTcpConfig"/> </netTcpBinding> <binding> </system.ServiceModel> ***FAQ:*** * There appear to be lots of different bindings...which one should I choose? * First of all, there might be several choices (not even dealing with creating your own Custom Binding) but in 99.99% of the cases you'll be dealing with only one of only 3 (basicHttpBinding, wsHttpBinding, and netTcpBinding), and in most scenarios these web-days, it really boils down to only using wsHttpBinding, so it's really not as complex and steep of a learning curve as it might first apear. * Secondly, there are several factors that go into choosing the binding for the job. The decision process is generally based on: * Protocol needed (Http|TCP|NamedPipe) * Various requirements: * eg: basicHttpBinding uses SOAP 1.1 and WS-BasicProfile1.1 * eg: wsHttpBinding uses SOAP 1.2, (better security, but makes it inaccessible to .NET 2.0 applications) * Very importantly, security mechanism offered: * *None*: The SOAP message is not secured and the client is not authenticated. * *Transport Only*: Security requirements are satisfied at the transport layer. * *Message only*: Security requirements are satisfied at the message layer. * *Mixed Mode*: integrity and confidentiality are prvided by claims are carried in the message; * [Ref:msdn](http://msdn.microsoft.com/en-us/library/ms730879) * Do you have to use bindingConfiguration attribute? * No. Without one set, the endpoint will use the default settings for the protocol specified by the binding attribute. * But the default settings are often not enough for most real world cases: even just basicHttpBinding and wsHttpBinding barely work out of the box without fiddling around with named binding configurations. * Can bindings be hot swapped? * To a small extent...but a binding configuration is for a specific binding, and therefore endpoint. In other words, you can't reference a netTcpBinding configuration from a endpoint whose binding is set to wsHttpBinding. Just won't work (differnt enum values, etc won't translate). * Why did you put the address on the TCP Binding? * Good quesiton. It was a different binding, so it and the base address would have been unique enough...but you can't get to a TCP port using a an http:// protocol from the base. * By default Visual Studio tools makes long names for the bindings, that are the FullName of the Service type. Are the names important in any way? * Not a bit. Use any tag you prefer. In fact I think that those long names get in the way of understanding what's really going on. I'd suggest using more meaningful names such as '*basicUnsecured*, 'wsSecured' etc. * What are common binding settings that need to be twiddled with?

• Message size.
  • The default message size is quite small (something like 4K). For larger payloads, messages, etc. you'll have to open that up.
• Security! Very very important, and much more of that further down the page.

### Defining a Service Endpoint's Contract ####

The endpoint's contract is what the client application is trying to get to use, once it chooses to access it using the binding's protocol, and gets past the binding's security requirements.

All that's really needed to configure this attribute is to match the endpoint's contract attribute to the FullName of the contract backing the contract instance (ie, the IMyService in our example).

FAQ:

• Why is the Contract attribute repetively defined on the endpoint, and not once on the Service element?
  • For one, not all the endpoint contracts for a service are the same contract. Case in point: the IMetadataExchange contract is not the same as your contract (eg: IMyContract). In addition to that, in some rare cases, the service implementation may fulfill multiple contracts.
  • That said, I still asked the exact same question: Ref:SO
    • The answer is interesting in so much that it reminds us that the Service (ie implementation) is not what they came for (that's our infrastructural side of things that the client doesn't need to know anything about), it clearly is the service interface – the endpoint contract.

Next: Bindings