Getting OrderService Ready to Ship
|Figure 1. WCF Config Editor View of BareBones Configuration File: WCF Service Configuration Editor is currently the best way to modify WCF configurations.|
While the configuration entries shown in BareBones
are just enough to get going, they are in no way ready to ship. This section looks at some of the specific requirements of the config section.
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:
- The maximum message size quota for incoming messages (65536) has been exceeded.
- 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.|
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.