This evening I decided that I would venture outside and go and see a movie. Having not judged the distance to the cinema very well I arrived a good twenty minutes early, which meant that I could watch the first part of an asp.net video podcast. The show was talking about reusing the asp.net services via atlas. It shows how you can wrap the services in a webservice that can be called asychronously by an atlas enabled page. Interestingly, this is the same process you go through if you want to reuse these services in an occasionally connect application.
So I guess the question is why these asp.net services aren’t exposed by default? The short answer is probably that there wasnt demand for it. That said, it would be an interesting project for someone in the community to do – build a set of services that can be dropped onto a site in order to expose the asp.net services for that site. This of course would have to be accompanied with a client side class library that can be configured to reference the services by url. It should also be configured to cache information locally and make update calls asynchronously using the disconnected webservice agent.
The other question is why the asp.net services are relevant to a windows application:
Authentication/Roles – Absolutely, after all we need to know what functionality a user can access, assuming they are able to login. Of course, like a domain computer the app would need to be connected when a user first signs into the app. There after their credentials/roles can be cached.
Profile – Especially in light of WPF, where we can use styles to change the appearance of an application the users profile becomes important. Simple things, like where windows are docked and which toolbars are visible, can be included in the profile. Unlike settings which, unless you code your own settings provider, are saved locally, profiles can be centrally managed.