REST WCF Feed Service with Dynamic Response

Much like the project in which we built a WCF dynamic response service allowing for JSON, XML or DataContract serialization, this project is based on dynamic response capabilities.  In this project, we will continue with the Album services created previously and extend them to dynamic response as a syndicated feed.  This RESTful service will dynamically respond with either ATOM or RSS syndication based on the request type.

I will accomplish this using two different examples of response, one with a return type of System.ServiceModel.Channels.Message and another with a return type of SyndicationFeedFormatter.  First, we need to syndicate a feed based on our data repository.  I am including the ability to filter our feed based on genre and artist so we can access virtual sub-feeds with a uri.

private SyndicationFeed CreateAlbumFeed(String genre = "all", String artist = "all")

{

    SyndicationFeed feed = new SyndicationFeed

    {

        Title = SyndicationContent.CreatePlaintextContent("The album listing"),

        Description = SyndicationContent.CreatePlaintextContent("Dynamic feed response from single WCF"),

        LastUpdatedTime = DateTime.Now,

        Items = from a in DataRepository.Albums()

                where ((genre.ToLower().CompareTo("all") == 0)||(a.Genre == genre)) &&

                ((artist.ToLower().CompareTo("all") == 0) || (a.Artist == artist))

                select new SyndicationItem

                {

                    LastUpdatedTime = DateTime.Now,

                    Title = SyndicationContent.CreatePlaintextContent(a.Artist+": "+a.Name),

                    Content = SyndicationContent.CreateXmlContent(a)

                }

    };

    return feed;

}

This function will do nothing more than create a syndication feed from our album listing based on a couple of parameters.  Next, we need to add interface options for retrieving the feed.

 [OperationContract]

 [WebGet(UriTemplate = "/Feeds/Albums"), 

         Description("Returns an Atom or RSS feed of albums")]

 System.ServiceModel.Channels.Message GetAlbumFeed();

 [OperationContract]

 [WebGet(UriTemplate = "/Feeds/Genre/{genre}"), 

         Description("Returns an Atom or RSS feed of albums by genre")]

 SyndicationFeedFormatter GetGenreFeed(String genre);

 [OperationContract]

 [WebGet(UriTemplate = "/Feeds/Artist/{artist}"), 

         Description("Returns an Atom or RSS feed of albums by artist")]

 SyndicationFeedFormatter GetArtistFeed(String artist);

The return type of System.ServiceModel.Channels.Message is very generic and allows for you to simply build the response of a web request.  While generic and flexible, it does limit you by not allowing parameters on the REST uri.  In order to allow a SyndicationFeedFormatter return type, we must ensure that the service can serialize it as a result.  This is achieved by making it a known type for the service by decorating the interface as follows.

[ServiceKnownType(typeof(Atom10FeedFormatter))]

[ServiceKnownType(typeof(Rss20FeedFormatter))]

At this point, it comes down to dynamically formatting your response.  We do this by implicitly checking the Content-Type value of the request header in the body of our service methods.  Here is one example:

public SyndicationFeedFormatter GetGenreFeed(String genre)

{

    SyndicationFeed feed = CreateAlbumFeed(genre: genre);

    if (WebOperationContext.Current.IncomingRequest.Headers.Get("Content-Type") != null)

    {

        if (WebOperationContext.Current.IncomingRequest.Headers.Get("Content-Type").ToLower().Contains("application/atom"))

            return new Atom10FeedFormatter(feed);

        else

            return new Rss20FeedFormatter(feed);

    }

    return new Rss20FeedFormatter(feed);

}

This dictates how the feed will be formatted upon return from the function.  You can check the output using fiddler to see the message itself, as well as configure the content type for dynamism.

 Now we are able to browse to our URI and see a feed for all albums, albums by artist and albums by genre. 

The added ability to select the method in which the client consumes your feed is valuable to ensure all consumers are included.  Download the project here

Combo RESTful WCF with Windows Service Hosting and Dynamic Response Format

The Goal
I have been working through the plausibility of multipurpose WCF services that are hosted in a windows hosting environment.  As part of my research, I wanted to prove that you could host a single service as a standard service to be consumed by a client proxy and scale it out from there to webHTTP and RESTful behavior.  The biggest goal I had was to make the service dynamically reply in the same format in which it was consumed without having a drawn out implementation to handle the messaging.

The Project
After some reading and messing around I have completed the following project which does exactly what I had hoped.  This single WCF implementation will allow for a straight service call, a RESTful call and respond dynamically with xml or json to the REST query based on the content type value of the request header.  All while being hosted in a windows service that can be dynamically deployed.  I came up with a very simple project that allows for interaction with a listing of albums.  The example is simple, but the devil of this was not in the actual data elements, so I flagged the scalability of that as irrelevant to the goal of illustrating the mechanism.

The Services
I created a basic WCF service to perform CRUD on my album repository. You will notice the service decorations on the interface indicating both an operation contract and a WebInvoke/WebGet behavior and template.

[ServiceContract(Name = "AlbumContract", 

     Namespace = "RESTCombo.Services", 

     SessionMode = SessionMode.Allowed)]

public interface IAlbumSvc:IMetadataExchange

{

    [OperationContract]

    [WebGet(UriTemplate = "/Albums/{id}"), 

        Description("Returns the album with the passed ID")]

    Album GetAlbum(String id);

    [OperationContract]

    [WebGet(UriTemplate = "/Albums"), 

        Description("Returns the entire list of albums")]

    List<Album> GetAlbums();

    [OperationContract]

    [WebInvoke(Method = "POST", UriTemplate = "/Albums"), 

         Description("Adds a new album to list of albums")]

    void AddAlbum(Album album);

    [OperationContract]

    [WebInvoke(Method = "PUT", UriTemplate = "/Albums"), 

         Description("Updates an existing album")]

    void UpdateAlbum(Album album);

    [OperationContract]

    [WebInvoke(Method = "DELETE", UriTemplate = "/Albums/{id}"), 

         Description("Removes an album from list of albums")]

    void DeleteAlbum(String id);

}

The WebGet and WebInoke decoration allows the services to respond as a RESTful WCF service based on the URI template.  The service implementation should be decorated as follows:

[ServiceBehavior(Name = "RESTCombo.Services.AlbumSvc", 

    ConcurrencyMode = ConcurrencyMode.Single, 

    InstanceContextMode = InstanceContextMode.Single,

    IncludeExceptionDetailInFaults = true)]    

[AspNetCompatibilityRequirements(

    RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]

public class AlbumSvc : IAlbumSvc

I'm going to skip posting the implementation of the services themselves as they are actually irrelevant to the discussion.  The entire project is attached at the end of the post if you would like to review the code.

The Configuration
While most of the configuration is fairly straight-forward, there are a couple of items worth pointing out.  Notice the multiple bindings for the single service.  Each must respond on its own port.  You can have as many bindings as needed up to one per protocol.  The webHttp endpoint behavior is vital to this mechanism.  helpEnabled allows users to use the '/help' switch at the end of a query to get a service overview page as shown here.

defaultOutgoingResponseFormat is our selection for the default response to a webHttp request. automaticFormatSelectionEnabled allows the response to dynamically detect the request format and respond in kind.

<?xml version="1.0"?>

<configuration>

  <startup>

    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>

  </startup>

  <system.serviceModel>

    <services>

      <service name="RESTCombo.Services.AlbumSvc">

        <host>

          <baseAddresses>

            <add baseAddress="http://localhost:8080/AlbumSvc/" />

            <add baseAddress="net.tcp://localhost:2122" />

          </baseAddresses>

        </host>

        <endpoint  binding="webHttpBinding" contract="RESTCombo.Services.IAlbumSvc"

                  bindingConfiguration="RESTBindingConfiguration" 

                   behaviorConfiguration="RESTEndpointBehavior"/>      

        <endpoint address="net.tcp://localhost:2122/AlbumSvc/" binding="netTcpBinding"

                  contract="RESTCombo.Services.IAlbumSvc"/>

      </service>

    </services>    

    <bindings>

     <webHttpBinding>

        <binding name="RESTBindingConfiguration">

          <security mode="None" />          

        </binding>

      </webHttpBinding>      

      <netTcpBinding>

        <binding name="DefaultBinding">

          <security mode="None"/>

        </binding>        

      </netTcpBinding>

    </bindings>

    <behaviors>      

      <endpointBehaviors>

        <behavior name="RESTEndpointBehavior">           

          <webHttp helpEnabled="true" defaultOutgoingResponseFormat="Xml"

                   automaticFormatSelectionEnabled="true"/>

        </behavior>

      </endpointBehaviors>

      <serviceBehaviors>                        

        <behavior name="DefaultBehavior">

          <serviceMetadata httpGetEnabled="true" />

          <serviceDebug includeExceptionDetailInFaults="false"/>

        </behavior>       

      </serviceBehaviors>

    </behaviors>  

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" 

                               aspNetCompatibilityEnabled="true" />

  </system.serviceModel>

</configuration>

The Testing
We will just fast-forward through the hosting setup and service implementation.  Now that services are configured, built and running, we can perform the response testing and see how it all comes together.  When browsing to the webHttp base address and invoking the services via RESTful queries, I receive the following responses for the list and single respectively.

Then, to prove the JSON / XML switch, I used a fiddler software to create and review requests and responses.  First, I constructed an XML request and trapped the response.

Then, I constructed a JSON request and trapped the response.

As you can see, the service is responding to me in the request format.  For the client proxy implementation, review the source code attached at the end of the post.  The big victory here is the open and scalable approach to an SOA.  By doing dynamic communication in this manner, we are enabling a service to be consumed in the way that an integrator can best leverage.  This allows us to have a single implementation of intelligence and functionality while allowing any integrating software to choose the manner in which it interacts.  This is very powerful and very scalable and should allow your services to be consumer agnostic and focus strictly on intelligence.  For further review, download the entire project here.

Dynamic Types Using C#

I ran across a scenario the other day for creating a function to perform similar work on similar classes without having to be tightly coupled to any concrete type.  I found a few viable options and will be doing some examples of each to work through the exercise completely.  The first I want to talk through is the use of the dynamic keyword.

In short, using dynamic tells the compiler to ignore types at compile time and instead determine dispatch based on the actual type at run time.  Static binding of types does the exact opposite and performs a dispatch based on the concrete type.  Since code always illustrates these academic discussions more clearly, I created a simple project.  I have two examples of dynamic typing built into this single example.  I created some classes to illustrate a few types that are completely unrelated to each other. I also created a single class that was an example of type inheritance.

public class Account

{

    public String Name { get; set; }

    public Double Balance { get; set; }

    public Int16 AccountType { get; set; }

    public Account()

    {

        Name = "Account";

        Balance = 100.00;

    }

}

public class Customer

{

    public String Name { get; set; }

    public Double Balance { get; set; }

    public String CustomerType { get; set; }

    public Customer()

    {

        Name = "Customer";

        Balance = 900.00;

    }

}

public class Employee

{

    public String Name { get; set; }

    public Double Balance { get; set; }

    public String Department { get; set; }

    public Employee()

    {

        Name = "Employee";

        Balance = 500.00;

    }

}

public class Payable : Account

{

    public Payable()

    {

        Name = "Payable";

        Balance = -100;

    }

}

As you can see, the classes are completely independent of each other, but they have similar members.  Using the dynamic keyword, we can create a function that deals with these types at runtime and interacts with expected members at that time.

static void WriteDynamicObject( dynamic thing)

{

    Console.WriteLine("Name: "+ thing.Name + ", Balance: " + thing.Balance.ToString());

}

As long as the types I pass to this function have publicly accessible members named Name and Balance, this code will work with a complete disregard for compilation of any known type.  Next, to illustrate using the dynamic keyword for instructing the runtime to resolve the type regardless of declaration, I created overloaded functions that take a concrete type at each level of inheritance.

static void WriteConcrete(Account thing)

{

    Console.WriteLine("I am an Account Thing");

}

static void WriteConcrete(Payable thing)

{

    Console.WriteLine("I am a Payable Thing");

}

Finally, a simple console application that illustrates how these items work and are either statically or dynamically resolved.  The difference between the 'Concrete' functions is shown by the dynamic keyword telling the runtime to resolve this class at run time regardless of it's declaration.  Also, notice the last item is not even a class at all, but rather a dynamic type declared simply to be passed to this helper function.

static void Main(string[] args)

{

    // call writedynamicobject function for all concrete classes

    Account a = new Account();

    WriteDynamicObject(a);

    Employee e = new Employee();

    WriteDynamicObject(e);

    Customer c = new Customer();

    WriteDynamicObject(c);

    //call function for a concrete class, but resolve type at runtime

    Account p = new Payable();

    WriteConcrete(p);

    WriteConcrete((dynamic)p);

    // dynamically create values and pass as a dynamic type.

    WriteDynamicObject(new {Name="TotallyDynamicNonClass", Balance=250});

}

The output of this project illustrates how the runtime deals with each of these scenarios.

If you are like me, the first thought you have on using the dynamic typing pattern is along the lines of, "Couldn't you just use an interface or inheritance to accomplish the same thing?"  The answer is yes, assuming you are able to know those types at compile time.  But, there are also times where you can't know the definitions at compile time.  You can't compile the internet, but you can interface with it.  I would be remiss if I didn't get into the downsides of this practice as well.  This can open you up to having a program that is hard to maintain, difficult to debug and unit test and many similar issues. But, guns don't kill people, people with guns do.  Dynamic typing doesn't make code difficult to manage, a programmer does those things with his or her architecture.  This is not a magic bullet and should be used with great caution. The reason for using it is that some problems are inherently dynamic (e.g. web requests).  While you may use reflection for this sort of problem today, you may find dynamic typing a more expressive approach to the same problem.  Simply being dynamic in itself is a compelling argument. Reflection introduces a tightly coupled dependency on a static mechanism.  Dynamic methodologies are intent-based and trust the receiver to act upon the passed intent which creates a scalability unachievable by other means.  The source files are available for download here. 

Object Design Principles - Part 5

Dependency Inversion Principle

The DIP states that high level classes should not depend on low level classes.  Both should depend on abstractions.  Details should depend on abstractions.  Abstractions should not depend on details.  The DIP is about reversing the direction of dependencies from higher level components to lower level components such that lower level components are dependent upon only the interfaces owned by the higher level components.  This is a method for moving to a more loosely coupled architecture.  Basically, you have to depend on a standard interface used by objects and not depend on their details.  This one might be best illustrated by example. 

In the following example, the BadCar class is tightly coupled to the actual implementation of the BadMotor function.  This means that these two objects are married, and changes to one directly impact the other.

public class BadMotor

{

    public Boolean Start()

    {

        Console.Write("Starting");

        return true;

    }

}

//tightly coupled to details.

public class BadCar

{

    public BadMotor Motor {get;set;}

    public Boolean Start(BadMotor badMotor)

    {

        Motor = badMotor;

        return Motor.Start();

    }

}

While this does function, it creates a dependency relationship between two objects at their implementation level.   This creates hardships for maintenance and scalability long term.   The proper way to build this relationship would be to invert dependencies onto interfaces to ensure no object has knowledge or visibility into implementation of any other object. Consider the following examples:

public interface IEngine

{

    bool Start();

}

public interface IGreenEngine : IEngine

{

    bool IsCharged ();

}

public class FourCylEngine : IEngine

{

    public bool Start()

    {

        Console.WriteLine("4Cyl Starting");

        return true;

    }

}

public class V8Engine : IEngine

{

    public bool Start()

    {

        Console.WriteLine("V8 Starting");

        return true;

    }

}

public class HybridEngine : IGreenEngine

{

    public bool Start()

    {

        if (IsCharged())

            Console.WriteLine("Hybrid Starting");

        return true;

    }

    public bool  IsCharged()

    {

        Console.WriteLine("Hybrid is charged");

        return true;

    }

}

public class Car

{

    public Car(IEngine engine)

    {

        Engine = engine;

    }

    public IEngine Engine{get ; set ; }

    public Boolean Start()

    {

        return Engine.Start();

    }

}

I built this interface dependency and inheritance to ensure that objects are loosely coupled and only share an interface.   This allows for actual base implementations to come and go and even be recognized dynamically without causing lower level objects to update their implementation.   Here is an example of hot swapping and scaling with the previously defined objects and interfaces.

class Program

{

    static void Main(string[] args)

    {

        //  Cars are only dependant upon an Engine interface

        Car BigThing = new Car(new V8Engine());

        BigThing.Start();

        //  Cars are only dependant upon an Engine interface

        Car SmallThing = new Car(new FourCylEngine());

        SmallThing.Start();

        // Since we have an interface dependency, it is easy to hot swap.

        BigThing.Engine = new HybridEngine();

        BigThing.Start();

    }

}

The output is as follows:

As you can see, this allows for maintainability and long-term scalability by ensuring that the objects stay out of each other's business. By adhering to the spirit of this principle as well as the previous SOLID principles, you can keep your code base healthy and easy to maintain when the requirement changes come.

Object Design Principles - Part 4

Interface Segregation Principle (ISP)

The ISP says that an interface should not become too 'fat' but be split into smaller and more specific interfaces so that only methods that pertain to a client need to be implemented.  You should focus on designing abstractions that have a very small, focused and sleek design.  Basically, no client should be forced to implement methods or properties it does not need to use.  We should always start at the most granular level and extend interfaces as needed.  You can create new interfaces that are extensions, or groupings, of other interfaces to form classes and objects desired.  Rather than forcing everyone to consume the entirety of a polluted interface, you are allowing them to implement an array of more focused interfaces.  I like analogies for getting my hands around design principles.  I think of this one much like eating at a restaurant.  If you sit down and order a burger, how do you react if you are given soup; then a burger, fries, and a coke; then an ice cream sundae?  And you are expected to pay for all of it.  Apparently, the only way to get a burger is to implement the IThreeCourseMeal interface.  If it doesn't make sense in life, it doesn't make sense in design. 

During application design we should pay close attention to how we abstract modules that contain several sub-modules. Granularity is always the side on which to err when doing interface design.  It is much easier to couple interfaces than to decouple a polluted interface (just as it would be very difficult to 'un-salt' your food.)  As I look through existing interfaces, it seems that this principal is easily and repeatedly violated, probably without intent.  In reviewing for this piece, I saw that months ago I created an interface that flagrantly violated this principle as a quick means to an end.  I plan to decouple it as part of this mental exercise.

Using the restaurant analogy above, I created some interfaces that, while silly, illustrate the principle.  First, I would go for the most granular interface that could logically be shared for all iterations of this type.  I landed on a menu item:

public interface IMenuItem

{

    String Item { get; set; }

    String Price { get; set; }

}

Then, I started creating logical abstractions of a menu item into various aspects of a meal:

public interface IEntree : IMenuItem

{

    String CookingInstructions { get; set; }

}

public interface ISide : IMenuItem

{

    Boolean IsVeggie { get; set; }

}

public interface IDrink : IMenuItem

{

    Int16 CupSize{ get; set; }

}

public interface IAppetizer : IMenuItem

{

    //...

}

public interface IDessert : IMenuItem

{

    //...

}

Next, I moved onto large interfaces that would have enough real world implementations to justify a single abstraction:

public interface IValueMeal : IEntree, ISide, IDrink

{

    //...

}

public interface IThreeCourseMeal : IAppetizer, IEntree, ISide, IDrink, IDessert

{

    //...

}

The advantage is that I can always come in at the implementation level and create my own dynamic abstraction.  Notice which properties' objects are created when I choose to implement the interface:

public class MyCustomMeal : IEntree, IDrink

{

    #region IEntree Members

    public string CookingInstructions

    {

        get

        {

            throw new NotImplementedException();

        }

        set

        {

            throw new NotImplementedException();

        }

    }

    #endregion

    #region IMenuItem Members

    public string Item

    {

        get

        {

            throw new NotImplementedException();

        }

        set

        {

            throw new NotImplementedException();

        }

    }

    public string Price

    {

        get

        {

            throw new NotImplementedException();

        }

        set

        {

            throw new NotImplementedException();

        }

    }

    #endregion

    #region IDrink Members

    public short CupSize

    {

        get

        {

            throw new NotImplementedException();

        }

        set

        {

            throw new NotImplementedException();

        }

    }

    #endregion

}

Hopefully, you can see how this principle allows for much scalability and dynamism of types without the inherent bloat from linear bulge.  This is a great principle to keep in focus during design.

Object Design Principles - Part 1

Singular Focus and Coupling

This will be the first installment of a multiple part posting on object design principles.  These are vital to keep in mind as we go through creation of large product platforms with many interaction services and objects that must be maintained and enhanced over time.

Object Responsibility

In my mind, the most vital question you can ask yourself at the outset of an object design is, "What is this object's core responsibility?"  Your entire design should flow from that very basic question. You should consistently look for the most granular object definition possible and work back from that.  It's really easy to get blinded by the vastness of the entire project and the complete set of user stories and completely misjudge where to segregate your logic.  Once you have defined the core responsibility and focus of an object, you can immediately start creating an inheritance path as well as supplemental interfaces to bring your object into full functionality.  This is the most vital step in ensuring a scalable and easily maintainable system long term.  Consider the following basic user requirement:  "I need to be able to view images and apply enhancements to them."  The first thing that comes to my mind is that although the user requirement is to always view images, every image view session will not ultimately result in an image enhancement session.  So, I immediately break into two objects, a viewer and an editor : viewer.  At its core, the viewer object should do nothing more than accept image data and render in a viewable state. The viewer should have no concept of any data or state outside of the image itself.  It should interact via an interface with a standardized image format so that it doesn't need to have any system context. 

The system also should have no specific knowledge of the viewer (more on that when we talk about coupling).  Then, the editor class should start by extending the known viewer class.  It should not extend any operation that pertains to the loading and displaying of the base image.  That aspect of responsibility should be a black box to the editor.  The editor should contain an interface for advertising its list of manipulations as well as a standardized message based interface for executing them.  This object is not responsible for a menu or toolbar system, it is simply an image manipulator requiring system input to launch an execution of its internally known action.  It also would not have any context for displaying an image history listing.  It would maintain a list of events, based on its internally known list of manipulations and allow an outside source to interact with that list via a standardized message or interface.

Loosely Coupled Objects

The main point of the granularity of the design listed above is to ensure a loosely coupled framework.  These controls and objects should all be interacted with via their interface over standardized messages.  If each object is singularly purposed and has a black box for its implementation, the only exposure and ultimate point for breakdown is the interface itself.  The loosely coupled system (or systems) interacts with itself based on standard messages or interfaces. The granularity, once released to production, allows for a dynamically upgradeable system with hot swap components.  In this scenario, we could easily swap out our image viewer or image editor in any given system with a very limited impact on the system as a whole. The change would be contained in a singularly purposed object that is loosely coupled with its housing system.  We would be able to quickly respond to a requirement for viewing a new image format without having to make changes to our image editor control.  Additionally, this transforms every control, service or object in every system into a plausible enterprise level base class by never assuming product knowledge or any aspect of external state.

By thoroughly investigating singular focus and coupling as part of every design, we can work toward a much more stable and dynamic system in the future.