Configuring WCF Services and Getting Them Ready to Ship : Page 2

Figure 1. WCF Config Editor View of BareBones Configuration File: WCF Service Configuration Editor is currently the best way to modify WCF configurations.

WCF Service Configuration Editor (config editor) is a Visual Studio tool that is currently the best way to modify WCF configurations. Its one flaw is that it doesn't enable you to add comments to the configuration sections. If you add comments and then use the config editor, it overwrites everything. Nevertheless, it does provide a host of features out of the box. Figure 1 shows the BareBones configuration file in its current state as seen through the config editor.

The following are the specifics for modifying the WCF configuration.

1. Give the endpoint a valid name.
Notice that BareBones contains a service that has an endpoint called [Empty Name]. Every endpoint should have a name. Although not required, naming your endpoints makes maintenance easy. In the endpoint discussed here, the code for a name is name="OrderService".

Figure 2. OrderServiceTCPBinding: Shows a New Binding Section: Create a new binding section called OrderServiceTCPBinding to the BareBones config file.

2. Add a new binding section.
Create a new binding section called OrderServiceTCPBinding to the BareBones config file. Figure 2 shows OrderServiceTCPBinding.

3. Associate the endpoint to the binding created.
This allows you to make changes to a number of properties on the endpoint and not be limited only to the default ones. Figure 3 shows a screenshot of associating a binding with an endpoint.

4. Change the max buffer size and max received message size (if needed).
At run time you may encounter two errors related to the amount of data being served by the server:

1. The maximum message size quota for incoming messages (65536) has been exceeded.
2. Maximum number of items that can be serialized or deserialized in an object graph is '65536'.

WCF limits the amount of data you can send over the wire per call to 64K, which is why the first error occurs. If your endpoint has methods that return more data than that (such as a collection), you have to change the buffer size and max received size from 64K to a suitable number.

Figure 3. Associating a Binding with an Endpoint: Create a new binding section called OrderServiceTCPBinding to the BareBones config file.

If you add a service by using the add service reference option, the values added on the server won't always reflect on the client. The client always defaults to 64K, which can cause a lot of confusion if many developers are changing the client configuration. A binding value that is updated on the server will have to be changed again on the client.

To fix the second error mentioned above, you can add the following element to the client config file in the service behavior section (2147483647 is used as an example only):

<dataContractSerializer maxItemsInObjectGraph="2147483647" /> 

5. Add a service behavior.
Apply a new behavior (called OrderServiceBehavior) to all the endpoints in your service. Four properties in OrderServiceBehavior (serviceDebugging, serviceMetaData, serviceThrottling, and maxConcurrentSession) are of particular interest (see Figure 4):

Figure 4. Four Must-Know Sections in serviceBehavior: Four properties in OrderServiceBehavior are of particular interest.

• serviceDebugging: This property is essential for troubleshooting when issues arise in production. The IncludeExceptionDetailsInFaults attribute should be set to false in production. If set to true (as it might in a development or staging box), it will actually show what the exception is on the client side. This gives extremely critical details about issues happening in a service.
• serviceMetaData: This property contains a property called HttpGetEnabled that will have to be set to HttpEndpoint to allow for discovery with the ?wsdl option. This option does not apply to this example as it uses a TCP endpoint.
• serviceThrottling: This is a mechanism to control the resource usage in a service.
• maxConcurrentSession: Of the four properties, this one is the most important. It controls the maximum number of simultaneous sessions accepted by the client. Each time a client opens a TCP connection to a server, it counts as one session. If the caller forgets to close a TCP connection on the client side, then the session limit can be reached very easily. The service will queue all incoming requests until the client requests that are not served time out. The service then closes the open session abruptly. As a good code review step, make sure all open connections in the client are closed, or use a using block for the client to dispose the connection as soon as it is no longer required.

  Set the maxConcurrentSession to as high as number as possible. You can adjust the serviceTimeout property to affect serviceThrottling as well.

6. Associate the endpoint with the new behavior.
After defining OrderServiceBehavior, associate the endpoint with that behavior.

Figure 5. Adding a MEX TCP Endpoint: In order for the TCP endpoint to be discoverable, you have to add a mexTcpBinding.

7. Add a metadata exchange (MEX) endpoint.
In order for the TCP endpoint to be discoverable, you have to add a mexTcpBinding (see Figure 5). This is a requirement of the WS-MetadataExchange (WS-I) specification. With this endpoint, you will be able to add a service reference or generate a client proxy.

If you are using an HTTP endpoint, a MEX endpoint is not required. Enabling HttpGetEnabled in the service behavior will suffice.

All MEX endpoints have to implement a contract called IMetadataExchange. Visual Studio is not smart enough to add this interface for you. If you make a typo, this endpoint will error out. Also, a mexTcp endpoint cannot run under the same port as the real service unless port sharing is enabled. When a service contains more than one endpoint, it is better to use a base address and a relative addressing scheme for the endpoints.