Squid Micro-Blogging Library for .NET 3.5
A few years ago I designed a system that would greatly ease data syndication, data aggregation, and reporting. The first two components of the system were repackaged and release early last year under the incredibly horrible name "Data Feed Framework". The idea behind the system was two fold. The first concept was that you write a SQL statement and you immediately get a fully functional RSS feed with absolutely no more work required. Here's an example of a DFF SQL statement that creates an RSS feed of SQL Server jobs:
select Id=0, Title=name, Description=description from msdb.dbo.sysjobs where enabled = 1
The second part of DFF was it's ASP.NET control named InfoBlock that would accept an RSS or ATOM feed and display it in a mini-reader window. The two parts of DFF combine to create the following:
Given the following SQL statement (or more likely a stored procedure)...
select top 10 Id=pc.ContactID, Title=pc.FirstName + ' ' + pc.LastName + ': $' + convert(varchar(20), convert(numeric(10,2), sum(LineTotal))), Description='', LinkTemplate = '/ShowContactInformation/' from Sales.SalesOrderDetail sod inner join Sales.SalesOrderHeader soh on soh.SalesOrderID = sod.SalesOrderID inner join Person.Contact pc on pc.ContactID = soh.SalesPersonID group by pc.FirstName, pc.LastName, pc.ContactID order by sum(LineTotal) desc
...we have an automatically updating RSS feed and when that RSS feed is given to an InfoBlock, you get the following:
InfoBlocks could be placed all over a web site or intranet to give quick and easy access to continually updating information. The InfoBlock control would also register the feed with modern web browsers that had integrated RSS support. Furthermore, since it was styled properly in CSS, there's no reason for it to be a block at all. It could be a horizontal list, a DOM-based window, or even a ticker as CSS and modern AJAX techniques allow.
DFF relied on RSS.NET for syndication feed creation and both RSS.NET and Atom.NET for aggregation. It also used LLBLGen Pro a bit to access the data from SQL Server. As I've promised with all my projects, they will update as new technologies are publicly released. Therefore, DFF has been completely updated for .NET 3.5 technologies including LINQ and WCF.
I've also decided to continue down my slippery slope of a change in product naming philosophy. Whereas before I would follow the Microsoft marketing philosophy of "add more words to the title until it's so long to say that you require an acronym" to the more Linux or O'Reilly approaches of "choose a random weird sounding word and leave it be" and "pick a weird animal", respectively. I've also been moving more towards the idea of picking a cool name and leaving it as is. This is in contrast to Microsoft's idea of picking an awesome name and then changing it to an impossibly long name right before release (i.e. Sparkle, Acrylic, and Atlas) Therefore, I decided to rename DFF to Squid. I think this rivals my Dojr.NET and Prominax (to be released-- someday) projects as having the weirdest and most random name I've ever come up with. I think it may have something to do with SQL and uhhhh.. something about a GUID. Donno.
Squid follows the same everything as DFF, however the dependencies on RSS.NET and ATOM.NET were completely removed. This was possible due to the awesome syndication support in WCF 3.5. Also, all reliance on LLBLGen Pro was removed. LLBLGen Pro (see my training video here) is an awesome system and is the only enterprise-class O/R mapping solution in existence. NHibernate should not be considered enterprise-class and it's usability is almost through the floor. Free in terms of up-front costs, does not mean free in terms of usability (something Linux geeks don't seem to get). However, given that LINQ is built into .NET 3.5, I decided that all my shared and open-source projects should be using LINQ, not LLBLGen Pro. The new LLBLGen Pro uses LINQ and when it's released, should absolutely be used as the primary solution for enterprise-class O/R mapping.
Let me explain a bit about the new syndication feature in WCF 3.5 and how it's used in Squid. Creating a syndication feed in WCF is required a WCF endpoint just like everything else in WCF. This endpoint will be part of a service and will have an address, binding, and contract. Nothing fancy yet as the sweetness is in the details. Here's part of the contract Squid uses for it's feed service (don't be jealous of the VS2008 theme -- see Scott Hanselman's post on VS2008 themes):
namespace Squid.Service { [ServiceContract(Namespace = "http://www.netfxharmonics.com/services/squid/2008/03/")] public interface ISquidService { [OperationContract] [WebGet(UriTemplate = "GetFeedByTitle/")] Rss20FeedFormatter GetFeedByTitle(String title); //+ More code here } }
Notice the WebGet attribute. This is applied to signify that this will be part of a HTTP GET request. This relates to the fact that we are using a new WCF 3.5 binding called the WebHttpBinding. This is the same binding used by JSON and POX services. There are actually a few new attributes, each of which provides it's own treasure chest (see later in this post when I mention a free chapter on the topic). The WebGet attribute has an awesome property on it called UriTemplate that allows you to match parameters in the request URI to parameters in the WCF operation contract. That's beyond cool.
The service implementation is extremely straight forward. All you have to do is create a SyndicationFeed object, populate it with SyndicationItem objects and return it in the constructor of the Rss20FeedFormatter. Here's a non-Squid example:
SyndicationFeed feed = new SyndicationFeed(); feed.Title = new TextSyndicationContent("My Title"); feed.Description = new TextSyndicationContent("My Desc"); List<SyndicationItem> items = new List<SyndicationItem>(); items.Add(new SyndicationItem() { Title = new TextSyndicationContent("My Entry"), Summary = new TextSyndicationContent("My Summary"), PublishDate = new DateTimeOffset(DateTime.Now) }); feed.Items = items; //+ return new Rss20FeedFormatter(feed);
You may want to make note that you can create an RSS or ATOM feed directly from an SyndicationFeed instance using the SaveAsRss20 and SaveAsAtom10 methods.
As with any WCF service, you need a place to host it and you need to configure it. To create a service, I simply throw down a FeedService.svc file with the following page directive (I'm really not trying to have the ugliest color scheme in the world-- it's just an added bonus):
<%@ ServiceHost Service="Squid.Service.SquidService" %>
The configuration is also fairly straight forward, all we have is our previously mentioned ending with an address(blank to use FeedService.svc directly), binding (WebHttpBinding), and contract(Squid.Service.ISquidService). However, you also need to remember to add the WebHttp behavior or else nothing will work for you.
<system.serviceModel> <behaviors> <endpointBehaviors> <behavior name="FeedEndpointBehavior"> <webHttp/> </behavior> </endpointBehaviors> </behaviors> <services> <service name="Squid.Service.SquidService"> <endpoint address="" binding="webHttpBinding" contract="Squid.Service.ISquidService" behaviorConfiguration="FeedEndpointBehavior"/> </service> </services> </system.serviceModel>
That's seriously all there is to it: write your contract, write your implementation, create a host, and set configuration. In other words, creating a syndication feed in WCF is no different than creating a WsHttpBinding or NetTcpBinding service. However, what about reading an RSS or ATOM feed? This is even simpler.
To read a feed all you have to do is create an XML reader with the data source of the feed and pass that off to the static Load method of the SyndicationFeed class. This will return an instance of SyndicationFeed which you may iterate or, as I'm doing in Squid, transform with LINQ. I actually liked how my server-control used an internal repeater instance and therefore wanted to continue to use it. So, I kept my ITemplate object (RssListTemplate) the same and used the following LINQ to transform a SyndicationFeed to what my ITemplate what already using:
Object bindingSource = from entry in feed.Items select new SimpleFeedEntry { DateTime = entry.PublishDate.DateTime, Link = entry.Links.First().Uri.AbsoluteUri, Text = entry.Content != null ? entry.Content.ToString() : entry.Summary.Text, Title = entry.Title.Text };
Thus, with .NET 3.5 I was able to remove RSS.NET and ATOM.NET completely from the project. LINQ also, of course helped me with my database access and therefore remove my dependency on my LLBLGen Pro generated DAL:
using (DataContext db = new DataContext(Configuration.DatabaseConnectionString)) { var collection = from p in db.FeedCreations where p.FeedCreationTitle == title select p; //+ More code here }
Thus, you can use Squid in your existing .NET 3.5 system with little impact to anything. Squid is what I use in my Minima blog engine to provide the boxes of information in the sidebar. I'm able to modify the data in the Snippet table in the Squid database to modify the content and order in my sidebar. Of course I can also easily bring in RSS/ATOM content from the web with this as well.
You can get more information on the new web support in WCF 3.5 by reading the chapter "Programmable Web" (free chapter) in the book Essential WCF for .NET 3.5 (click to buy). This is an amazing book that I highly recommend to all WCF users.