Agenda/Intro:
•Why use WCF with DotNetNuke?
•Quick Look at WCF
•Demos / code examples
–Monitoring your web site
–Offline management of your content
•Questions
Why use WCF with DotNetNuke
Why would I want to use WCF with DotNetNuke? Well, for the same reason you would have used Web Services in the past, to expose Data and/or Functionality to applications or web sites outside your application boundaries.
You could certainly use traditional Web Services to do the same thing, but WCF will bring some additional things to the table.
Web Services (asmx) can only be hosted within IIS, and in most cases that is sufficient. However, WCF is a full blown messaging and communications solution that provides you with many options for hosting your service. It also provides control over how messages (data) are sent to and from the service, better control over serialization of message data and a cleaner programming interface to construct your service, operation and data contracts, enforcing better programming through ‘contract first’ development techniques.
The nice thing is that WCF allows you to write your service code very much as a standard class and then configure your service’s transport, message and security options in the .config file. That makes it easy to test your service, then decide how to ‘deploy’ it. You can change how your service is hosted, what transport is used, how messages will be sent, add additional ways for applications to talk to your service by make changes to the .config file and not your code.
This configuration extends to security as well, so you can write your service once, then deploy it to different environments and configure the service’s security for each environment as appropriate.
WCF makes it easier to build REST interfaces to your service, and that will allow any client running on any platform to access your service. You can provide multiple interfaces, SOAP and REST for example, so that if a client application is a .net application, it can use the SOAP interface to generate a client-side proxy and take advantage of a strongly typed service connection. However if the client is a mobile device, or application written in another language, that client can use the REST interface and take full advantage of your service.
By separating your service into ‘contracts’ and separating your service code from your configuration, you will end up with a service that is easier to code, easier to test and easier to deploy.
Plus, it’s new and it’s cool :)
… so why would you NOT want to use WCF!!
Next: A Quick look at WCF