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.