Noteworthy Items From WCF Labs

Having moved on from the windows development aspect of the certification process and diving deeply into the inner workings of WCF, I noted some items worth mentioning.  These items cover some aspects of WCF that are new to WCF, some that are old but not adequately appreciated, and some that are seemingly relevant only to certification.  This section has been much more intense and in-depth than the previous one, and the labs can last up to a half day. The practice exams have 130-140 questions and the 3-day deep dive has consisted of 2 books totaling about 900 pages.  To date, here are some noteworthy WCF items and a short description of each.

ConcurrencyMode.Reentrant
When unable to rely on a well partitioned service layer, this setting can come in handy for preventing deadlocks and time-out errors from within a service call.  To put it at the most simplistic level, allowing re-entrant concurrency will allow the same thread to re-enter the same operation without waiting on itself to complete.  Sure, if you have followed good SOA guidelines all along, you would never need this one, but since in the real world, we have not, this could be quite useful.  In the case I outlined in my SOA discussion regarding logical distribution and the possibilty of BLL -> DAL - >BLL collisions, this could be a very good stop gap to keep your customers running while you work toward a more correct logical design.  This will avoid the deadlocks and timeouts caused by a single call colliding with itself withing an operation with this concurrency.

Throttling
Throttling can be a useful tool for regulating the number of calls or sessions at any given time.  Since allowing multiple concurrency is often required even though the operation may be long, the realistic possibility of resource overload can be avoided by simply throttling the number of calls or sessions.

<behaviors>

 <serviceBehaviors>

   <behavior name="throttleBehavior">     

       <serviceThrottling

         maxConcurrentCalls="20"

         maxConcurrentInstances="200"

         maxConcurrentSessions="10"/>

    </behavior>

  </serviceBehaviors>

</behaviors>

This can be set based on realistic usage of the given service.  Sometimes, it may be better to have traffic waiting in a queue compared to having all clients fighting over resources.

Streaming
Streamed Message Transfer allows the service to stream back large result sets to the client without creating the entire object in memory prior to transport. This again could be a helping hand in an environment when server resources are being hogged and blocked by large amounts of data and traffic.

Discovery
New to .NET 4.0, discovery allows for services to be dynamically located by a client without any knowledge of the host address.  It basically allows services to broadcast their location and clients to search for them.  The obvious usage is for deployment to an unknown environment without the need for settings to be changed by non-technical users.  It can go much deeper than that.  This allows a client to search for an available service at each connection.  The dynamism here is again quite promising.  This means that you could configure fail-safe services and have clients dynamically connecting to the first available.

WCF Routing
New to .NET 4.0, routing is the ability to configure a generic soap service to be the 'gatekeeper' to the actual service being called.  For instance, a routing service can be used to roll your own load-balancing on a local install. The routing service can also be configured to allow service-based routing, content-based routing (e.g. filter message based on data and route to correct service), fail-over routing, and priority routing.  This is incredibly powerful and seems like WCF has given all the tools to build your service layer to be as scalable and dynamic as needed.

Default endpoints
New to .NET 4. While not the recommended idea, default endpoints are a nice way to ensure that all clients have the ability to interact with your services. Currently, if you try to host a service without any configured endpoints, the ServiceHost instance will throw an exception informing you of the need to configure at least one endpoint. With .NET 4, this is no longer the case because the runtime automatically adds one or more “default endpoints” for you, basically making the service usable without any configuration.

Exposing to Json
This one just struck me as cool.  You can allow your WCF service to respond in JSON or MessageContracts with some simple switching and decoration.  By decorating a service as follows:

 [ServiceContract]

    public interface ITestService

    {

        [OperationContract]

        [WebGet(ResponseFormat = WebMessageFormat.Json, UriTemplate = "/GetDataAsJson")]

        SomeData GetData();        

    }

and then adding a file named GetDataAsJson.svc with the following markup

<%@ ServiceHost Service="MultiService.TestService" 

                Factory="System.ServiceModel.Activation.WebServiceHostFactory" %>

The service will begin to dynamically respond with Json or Contract using the same implementation.

There is much more to discuss, but this is a short list of items that have stuck in the forefront of my mind.