Miguel A. Castro's Blog

# Tuesday, July 27, 2010

Note: Using a Console app for hosting should be done for development only !

Now that the disclaimer is out of the way, I currently doing some development work for a customer and I had the need to know every time any of my services receives a call.  Since I do my development using a console application for service hosting, it was easy enough to write out to the console from each service operation.  Of course, putting code in every method was possible but not only would it be time consuming, to turn it off later would be a pain.  The answer needed to be something that gets hit on every operation.  Since WCF is essentially one giant inversion of control container, I knew there was a point I could tap into before any operation call.

Enter behaviors !

This turned out to be a multi-step process but once it’s in my library of WCF stuff, I can reuse it and it actually turned out to be quite cool.  I’ll explain each step and the reasons for the step.

Step 1 – Write a custom Parameter Inspector

The first class you need to write is one that implements the IParameterInspector which is in the System.ServiceModel.Dispatcher namespace.  This class will later be installed in such a way that it gets hit on every operation call.  The operation name is one of the arguments you have access to, as well as all the operation arguments which I don’t need in this case.

The methods in this implementation are BeforeCall and AfterCall, and it is the BeforeCall that I’m interested in.  The code I’ll place in this method very simply outputs something out to the console using Console.Writeline.

Unfortunately the name of the service is not passed into this method so I need to get that into this class using a custom constructor; you’ll see how I’ll get it to the class later.

Here’s the code for my ConsoleReportInspector class:

 

public class ConsoleReportInspector : IParameterInspector
{
    public ConsoleReportInspector(string serviceName)
    {
        _ServiceName = serviceName;
    }

    string _ServiceName = string.Empty;

    void IParameterInspector.AfterCall(string operationName, object[] outputs, object returnValue, object correlationState)
    {
    }

    object IParameterInspector.BeforeCall(string operationName, object[] inputs)
    {
        Console.WriteLine(string.Format("{0} - '{1}.{2}' operation called.", DateTime.Now.ToLongTimeString(), _ServiceName, operationName));

        return null;
    }
}


 

Step 2 – Install the class using an Operation Behavior

In order to install the parameter inspector, I’ll need to write a custom operation behavior class.  This is a class that implements the IOperationBehavior interface.  You need to remove the throw to NotImplementedException from all the methods; and the method of concern here is ApplyDispatchBehavior.

The name of the service being called is accessible through the Parent property of the dispatchOperation argument.  I need to instantiate my ConsoleReportInspector class and send the service name into the constructor I added earlier.  Afterward, I just need to add my parameter inspector class to the list of parameter inspectors accessible in this behavior.

I also inherited this class from the System.Attribute class so I can use it as an operation behavior attribute on individual operations if I wanted.  This is just for flexibility since I plan on hooking this into a service so it affects all operations.

Here’s the code for my ConsoleReportOperationBehaviorAttribute class:

 

[AttributeUsage(AttributeTargets.Method)]
public class ConsoleReportOperationBehaviorAttribute : Attribute, IOperationBehavior
{
    void IOperationBehavior.AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
    {
    }

    void IOperationBehavior.ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
    {
    }

    void IOperationBehavior.ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
    {
        string serviceName = dispatchOperation.Parent.Type.Name;
        dispatchOperation.ParameterInspectors.Add(new ConsoleReportInspector(serviceName));
    }

    void IOperationBehavior.Validate(OperationDescription operationDescription)
    {
    }
}


As-is, I can simply decorate a service operation with [ConsoleReportOperationBehavior] and if hosted on a console application, you’ll see output to the console when the decorated operation is called.

 

Step 3 – Install the operation behavior on all operations using a Service Behavior

Next I need to write a service behavior.  This is a behavior that gets installed when the service loads (the host is opened).  The job of this behavior is to install my operation behavior on all the service operations.  A service behavior is a class that implement the IServiceBehavior interface.  Like before, I’ll remove the exception calls and once again the method I’m interested in is ApplyDispatchBehavior.

I’m going to iterate through all the endpoints of this service, which are accessible through the serviceDescription argument, and for each endpoint I will iterate through the operations of the contract of each endpoint.  To each operation I will add an instance of my ConsoleReportOperationBehaviorAttribute class.

This class too I will inherit from Attribute so I can use it to decorate a service in the case that I wanted to take this approach at some time. 

Here’s the code for my ConsoleReportServiceBehaviorAttribute class:

 

[AttributeUsage(AttributeTargets.Class)]
public class ConsoleReportServiceBehaviorAttribute : Attribute, IServiceBehavior
{
    void IServiceBehavior.AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters)
    {
    }

    void IServiceBehavior.ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
        foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints)
            foreach (OperationDescription operation in endpoint.Contract.Operations)
                operation.Behaviors.Add(new ConsoleReportOperationBehaviorAttribute());
    }

    void IServiceBehavior.Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
    }
}

 

Step 4 – Apply the service behavior to any service I want programmatically at the host

Whatever approach you take to hosting, all you need to do is access each instance of ServiceHost and add the service behavior to the list of behaviors in the host.  I have my own techniques for hosting which include some custom declarative stuff to allow me to turn hosting on and off at will through config.  I also like to separate the accumulation of my ServiceHost instances from the actual application that will do the hosting.  This way I can move it to a Windows Service when I’m ready to go to production.

Here’s the code that installs the behavior:

 

 

ConsoleReportServiceBehaviorAttribute behavior = serviceHost.Host.Description.Behaviors.Find<ConsoleReportServiceBehaviorAttribute>();
if (behavior == null)
    host.Description.Behaviors.Add(new ConsoleReportServiceBehaviorAttribute());

 

The host variable is an instance of ServiceHost.  I perform the code above in between a config check so I can toggle it off at will.

The end result is quite cool since when turned on, every call to any of your services will be shown on the console.

 

Until next time…

Tuesday, July 27, 2010 10:57:11 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [1] - - Follow me on Twitter
Dev Stuff | WCF
# Monday, May 24, 2010

WCF 4.0 incorporates the features previously only obtainable via the REST Starter kit for .NET 3.5.  Among the features included is the ability to cache REST requests using a similar technique to caching ASP.NET pages.

The 4.0 version of the System.ServiceModel.Web assembly includes an attribute called AspNetCacheProfile which takes a string as an argument.  The attribute is to be used on a service contract operation as follows:

[OperationContract]
[WebGet(UriTemplate = "/{name}/getGreeting.xml",
        BodyStyle = WebMessageBodyStyle.Bare,
        RequestFormat = WebMessageFormat.Xml,
        ResponseFormat = WebMessageFormat.Xml)]
[AspNetCacheProfile("CacheFor10Seconds")]
string GetGreetingXml(string name);

 

The string points to a cache profile to be defined in the config section as follows:


    
        
            
        
    

 

As you can see, this is pretty much identical to setting up cache profiles for ASPX pages.  The effect is pretty much what you would expect, the caching of a REST request.  This can be proven and tested by implementing the above contract as such:

public string GetGreetingXml(string name)
{
    return string.Format("Hello {0}.  The time is {1}", name, DateTime.Now.ToLongTimeString());
}

 

Now you can refresh the request and you’ll see the same time for 10 seconds before it changes; once again, the same effect as in caching an ASPX page.

So what did I learn the hard way you ask?  Well, common sense dictates that the request go through ASP.NET in order to use its caching capability.  This not only means that you have to host in IIS or WAS, but also that you need to turn on ASP.NET compatibility mode.  This shifts the processing of the REST request over to an HTTP handler that also sets an HTTP Context for you, something not normally done with conventional IIS hosting for REST services.  To turn this on, you must enable it in the section under the section using the aspNetCompatibilityEnabled attribute.  Not only that, but you have to “allow” it on the service using the AspNetCompatibilityRequirements attribute.

This part was not a surprise for me since I was already familiar with this technique and the added scope your service receives because it.  I’m referring to the entire HTTP Context including session, application, cache, etc.  Keep in mind that this is not for everything and should be used in very specific scenarios as it ties the service to the hosting style quite tightly.

What drove me crazy is something I’m surprised I did not notice in the past and that is the fact that your REST requests will not work while using the Visual Studio development server.  Meaning you need to create an application in IIS and run it that way.  No big deal but it drove me a little crazy since the meta data exposure worked fine, and so did the new HTML Help pages (another new feature in WCF 4.0 For REST).  But the second I tried to request one of my URLs, it bombed out.  Once I set up my application under IIS, everything was fine.

I have to give credit where it’s due and thank Jon Flanders.  I found the answer in his book Restful .NET from O’Reilly press.

Until next time…

Monday, May 24, 2010 4:50:14 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] - - Follow me on Twitter
Dev Stuff | WCF
# Tuesday, May 18, 2010

WCFFirestarterNYC

Stop starting new projects with ASMX Web Services or .NET Remoting!  OK, now that we have your attention, let’s get serious.  These two

technologies are so 2002!  You need to start learning Windows Communication Foundation (WCF) if you haven't already.  This is the platform for connected applications on the Windows platform going forward, and you know what?  It's easier to use than you may think.

Even if you've been tinkering with writing basic services in WCF for a while but haven't dived into anything more advanced, you should come in for the NYC WCF Firestarter.

Join us for a full day of nothing but WCF sessions.  Ranging from an introductory so you can hit the ground running, and with best practices, continuing with topics involving the most important features of WCF, and ending with some cutting edge material on REST & Microsoft's new service bus and Azure technology in .NET 4.0.

We’ve got a great line up of speakers!  Presenting at the NYC WCF Firestarter will be Miguel Castro, Don Demsak, and myself (Peter Laudati).

Microsoft NYC Office - 1290 Ave of the Americas - 6th Floor
Microsoft NYC Office - 1290 Ave of the Americas - 6th Floor

Event Details

Event Date: Saturday June 19th, 2010

Event Location:

Microsoft NYC Offices
1290 Ave of the Americas 6th Floor
New York, NY 10104

REGISTER HERE!

Event Agenda

Doors open 8:30am. Sessions run from 9:00am – 5:00pm. Lunch will be served.

  • Session 1: Keynote – Intro to SOA & WCF
  • Session 2: Most Common WCF Usage Scenarios
  • LUNCH
  • Session 3: REST Programming with WCF
  • Session 4: WCF Made Easy – Data & RIA Services
  • Session 5: What’s New With WCF 4.0
Session Details

Intro to SOA & WCF

Jump right in to understanding what service orientation is and how WCF is the preferred technology for this architecture.  You'll see how services get written in WCF from scratch and using best practices from the beginning.

Most Common WCF Usage Configurations

WCF has many characteristics, each with several options.  There are however some optimal settings for the most common scenarios.  In this session you'll learn the whys and hows for configuring WCF services to work optimally in the areas of instantiation, concurrency, transactions, security, and bindings.

REST Programming With WCF

With .NET 3.5 came the addition of the System.Service.Web assembly and the addition of REST capabilities to WCF.  REST is an HTTP-based messaging protocol that is common in web applications today and even more common in non-.NET services that expose API (think Twitter & Google).  In this session, you'll learn how to expose your services using REST and also how to consume non-.NET REST APIs using WCF.

WCF Made Easy - Data & RIA Services

You have seen all the various ways you can leverage WCF, but what if all you want to do is expose your data via HTTP?  In that case, you can simplify your development, by using WCF Data Services or WCF RIA Services.  In this session we will learn how to easily expose your data using Entity Framework in a RESTful fashion using WCF Data Services, how to consume WCF Data Services, and then dive into WCF RIA Services.

What's New With WCF 4.0

No Day-Of-WCF would be complete without letting you know what's new with .NET 4.0 and Visual Studio 2010.  This session will give you a heads up on several new and powerful features introduced in WCF 4.0.  Among these are "Configuration-less Hosting", "Discovery", "Routing", and an intro to the new Azure Service Bus.

Swag & Prizes

We hope you come to attend the NYC WCF Firestarter for the unique content, providing a FREE opportunity to advance your skills by learning a new technology. However, like many events, we’ll have some fun stuff to giveaway at the end.  If you stick around, you will have the chance TO BE THE LUCKY WINNER OF A MICROSOFT ZUNE!  YOU MUST BE PRESENT TO WIN.

Tuesday, May 18, 2010 4:25:36 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] - - Follow me on Twitter
Speaking Events | WCF
Search
Me & My Flair

Read all about me here.
Download my Resume here.

Check out where I am here.
 
Click on logos above for profiles.
Archive
<September 2010>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789
Statistics
Total Posts: 25
This Year: 25
This Month: 2
This Week: 0
Comments: 28