DNN Community Blog

Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact community@dnnsoftware.com.


Services Framework, a little context

Over the past several days there have been a few blog posts introducing the new Services Framework.  These posts have generated several expressions of interest and several questions.  In this post I want to provide some context around why we built Services Framework, what it is today and where we are planning to take it tomorrow.

Fundamentally Services Framework allows developers to easily create a Web API that any "device" that speaks HTTP can call.  In this sense "device" can be almost anything such as a smart phone, curl script, XmlHttpRequest, or my personal favorite suggestion so far, an RFID scanner operating on a factory floor.  Almost anything that has an internet connection will do, and that means if you can write code for it, Services Framework will probably help you to integrate it with your DotNetNuke site.

People have been writing various .asmx, .ashx, and WCF based web services for a long time.  How is Services Framework better?  The main difference is that each time someone wrote their own web service, they had to authenticate, authorize and load DotNetNuke context  themselves.  The single biggest convenience of Services Framework is that these features are built in.

So far there are three different ways to authenticate in Services Framework.  Not surprisingly we support forms authentication just like the DotNetNuke web site.  We expect this will be used almost exclusively by XmlHttpRequests initiated from AJAX style web pages.  There are two authentication options to support devices operating from outside of a web page.  These are Basic and Digest authentication.  Basic Authentication like forms authentication passes username and password as open text and should only be used with SSL.  Digest Authentication hashes the credentials and is much safer to use on a regular HTTP connection.  In future we will likely expand the authentication options.  oAuth is like the next likely candidate.

Once a user is authenticated the next step is authorization.  In 6.2 we have focused most of our effort on authorizing via module permissions.  Each service call can be configured to require any standard or custom module permission.  We also support general purpose authorization that allows services to be made available to only Host users, any anonymous user, or by static role names.  A better approach to role based authorization is needed, but will not likely make it into the 6.2 release.  Look for those improvements in future releases.

Once the authentication and authorization have been taken care of and your web service code is actually executing, it will have access to context like the current user info, portal settings and module info when applicable.  A service can call any part of the DotNetNuke API.

There are many styles of web services out there.  We are not pushing toward any particular style.  We wanted a lightweight solution that supports simple RPC style services, along with full blown REST services and the many hybrid approaches to REST-like services.  We intentionally did not add any support for "heavyweight" services like SOAP or WS*.  Such support could be built on top of Services Framework, but we don’t expect to add it to the core.

We have chosen to build Services Framework on top of ASP.Net MVC 2.  This provides a lightweight framework for dealing with incoming service requests.  It supports a very flexible approach to defining URIs, and makes it easy to handle a variety of HTTP verbs.  The output of a service can be in pretty much any text format that is required.  The full power of ASP.Net MVC is available when building services.

ASP.Net MVC was built primarily to serve web pages to a browser.  To some extent it is an accident that the foundation of ASP.Net MVC provides a flexible way to build web services.  Recently Microsoft released a beta of the next generation of ASP.Net MVC which includes the new and exciting Web API.  The new Web API takes many of same ideas and flushes them out for the specific purpose of building web services.  Web API will not be released in time for 6.2, but we are excited about it, and seriously considering switching Services Framework to Web API in a future release.

In 6.2 the main focus of Services Framework has been building services to support jQuery/AJAX based module development.  Several of the new social features make use of Services Framework.  To help with jQuery and AJAX based modules the Services Framework includes a jQuery plugin with helpers to setup the headers required for executing in the context of a particular module.  Services Framework also includes an easy way to add and validate anti-forgery tokens in pages that load your module, helping to prevent CSRF style attacks on modules that use web services.

Services Framework has just begun it's life, and I expect it will evolve substantially over the next couple major releases of DotNetNuke.  Please help us grow the Services Framework by trying it out and letting us know what questions you have, what suggestions you have, and what successes you achieve using Services Framework.

Stay tuned for my next post on Services Framework in which I will walk through building a module from HTML, javascript, MVC services and only the tiniest bit of Web Forms code.


Comment Form

Only registered users may post comments.


September 2014 (11)
August 2014 (25)
July 2014 (17)
June 2014 (10)
May 2014 (6)
April 2014 (9)
March 2014 (3)
February 2014 (4)
January 2014 (8)
December 2013 (5)
November 2013 (2)
October 2013 (9)
September 2013 (10)
August 2013 (8)
July 2013 (4)
June 2013 (8)
May 2013 (13)
April 2013 (2)
March 2013 (7)
February 2013 (7)
January 2013 (10)
December 2012 (6)
November 2012 (20)
October 2012 (12)
September 2012 (27)
August 2012 (29)
July 2012 (22)
June 2012 (17)
May 2012 (23)
April 2012 (24)
March 2012 (27)
February 2012 (21)
January 2012 (12)
December 2011 (18)
November 2011 (20)
October 2011 (27)
September 2011 (17)
August 2011 (18)
July 2011 (45)
June 2011 (22)
May 2011 (23)
April 2011 (19)
March 2011 (36)
February 2011 (19)
January 2011 (22)
December 2010 (29)
November 2010 (37)
October 2010 (32)
September 2010 (43)
August 2010 (46)
July 2010 (37)
June 2010 (46)
May 2010 (29)
April 2010 (38)
March 2010 (27)
February 2010 (33)
January 2010 (34)
December 2009 (13)
November 2009 (20)
October 2009 (29)
September 2009 (18)
August 2009 (29)
July 2009 (19)
June 2009 (18)
May 2009 (23)
April 2009 (16)
March 2009 (13)
February 2009 (20)
January 2009 (25)
December 2008 (25)
November 2008 (29)
October 2008 (34)
September 2008 (33)
August 2008 (36)
July 2008 (31)
June 2008 (25)
May 2008 (26)
April 2008 (33)
March 2008 (31)
February 2008 (24)
January 2008 (18)
December 2007 (27)
November 2007 (51)
October 2007 (24)
September 2007 (32)
August 2007 (24)
July 2007 (20)
June 2007 (28)
May 2007 (27)
April 2007 (24)
March 2007 (47)
February 2007 (21)
January 2007 (41)
December 2006 (21)
November 2006 (16)
October 2006 (24)
September 2006 (36)
August 2006 (30)
July 2006 (31)
June 2006 (37)
May 2006 (13)
April 2006 (13)
March 2006 (18)
February 2006 (20)
January 2006 (13)
December 2005 (6)
November 2005 (15)
October 2005 (15)
September 2005 (16)
August 2005 (7)
April 2005 (1)
March 2004 (4)
February 2004 (6)
January 2004 (1)
November 2003 (4)
October 2003 (22)
September 2003 (22)
August 2003 (15)
July 2003 (14)

Copyright 2014 by DNN Corp | Terms of Use | Privacy | Design by Parker Moore Design