How to Move Your Line of Business Apps to Phone + Cloud

Rob Tiffany has put together a series of blog posts describing how to move data to your Phone applications from the cloud. Issues for your apps include slow service connections. For device apps to be successful, they must pre-fetch the data they need and cache it offline so a user can keep working when the network is not around.  This is not typical SOA, calling Web Services on-demand to help drive your application.

And you’d like to be able to connect to data in Windows Azure or on your on-premises database, store it on the Phone so you can have a disconnected story too. And you want to do this efficiently.

If you’ve looked at the Networking in Silverlight for Windows Phone 7 documentation on MSDN, you might have noticed that a number of things are missing, such as WCF RIA Services, WCF Data Services (OData), Duplex Communication over HTTP, Sockets, UDP Multicast Client, NTLM Auth, RSS/ATOM Feeds, Custom Bindings, JSON Serialization.

So what is left? How does that work?

And what are the steps, trick, and tips? Here’s the view:

Step 1. Build a WCF REST + JSON Service

Rob’s article describes what is on the Phone, in particular SOAP and REST + Basic Authentication. And he makes the case of JSON as a preferred data format for the wire. Next he shows how to build out a sample Web Service and how to add the attributes so your data is serialized. He writes the class that holds the data in a way that can be used on both Windows Phone and on your server.

He defines the contracts for a public interface for the Web Service that will generate JSON on the server. And he provides code to get all or a part of the list of data from the Web Service. He finishes off the service with the configuration files that set up the server to provide data using REST.

See Building a WCF REST + JSON Service.

By the way, this solution works whether you are hosted on Windows Server or Windows Azure.

Step 2. Move Your Web Service to Windows Azure

Using Visual Studio 2010, the Azure Development Fabric and SQL Server, Rob shows show you how to move this code to the cloud. He takes you through each step, with screenshots. He shows you how to startup your project, how to rewrite the default services contract and web.config file to work with WCF REST and JSON. He explains how to give the Windows Phone 7 caller a web-friendly Uri to call.

And then to test and debug the Azure-based Web Service. And you’ll see the data returning the data objects in wireless-friendly JSON format.

See Moving your WCF REST + JSON Service to Windows Azure.

Step 3. Consume You Web Service on the Phone

Rob begins by leveraging the Web Service code to create a Phone app that cpnsumes the Web Service. Next he shows how to build your Phone application in Visual Studio that will access the Web Service in Azure all on your development computer.

He illustrates how your Phone application will make an asynchronous call to the Web Service, and how to store the data on the Phone. He uses a Database class to connect to an ObservableCollection and the DataContractJsonSerializer used to de-serialize JSON-encoded Customer objects that are downloading over the air.

And finally, he shows how to access the table of your in-memory database.

See Consuming an Azure WCF REST + JSON Service.

Step 4. Working with the In-Memory Database

In this post, Rob shows how to query this new in-memory database using LINQ and I’ll show you how to save the data in your local tables to Isolated Storage so you can keep using your apps even when the network has disappeared.

He walks you through each of the steps to do CRUD (create, retrieve, update, and delete) your data using a listbox and buttons on the Phone. And then how shows how to store and retrieve the data from IsolatedStorage.

See Working with an In-Memory Database.

Enjoy.

Bruce D. KyleISV Architect Evangelist | Microsoft Corporation

Comments

• Anonymous
  November 10, 2010
  All good tips, but the problem here is the distribution model. Most customers doesn't want to expose their data to a public Marketplace as a lot of LOB is intranet apps or internal to that company. How is the future in that respect?

• Anonymous
  November 10, 2010
  The post provides you a way to let a Phone app see data. That data can certainly be LOB data on premises or in the Cloud. So if you want to make that data available to uses of Phone, you'll need to find a way to identity and secure the user, just as you would for any remote thick client. The articles mention that you can send identity as part of the payload in requesting information from the Web Service. That identity can be a log in or a federated identity. You can then take the Identity information and use Windows Identity Foundation to get the parts that you need, then authorize access to information based on identity and role. He doesn't show how to do all that in his article. So the identity can be provided by your organization's Active Directory (or even federated). The sign in would need to happen on Phone. And your Web Service can decide what to offer as data. There's a few postings here that can point you in the right direction. As soon as I find a good source on best practices for security data on Phone and for sign in screens, I'll post it too.

• Anonymous
  November 10, 2010
  Hi Bruce, I second Brian's comment - there doesn't seem to be any effective solution for deployment of enterprise solutions on WP7. I do understand your comment that you could just publish it to everyone and make the security layer determine visibility of data - but thats hardly a palletable option for most organizations. Most orgs don't want the public even knowing what internal apps they are using (and would not be an acceptable security risk to allow the app to even be installed) - and certainly they don't want external parties (like MS cert) performing any testing/acceptance on their applications prior to deployment. (so it needs to be independant of marketplace altogether). I think you guys really need to look at how this can be done in future - the WP7 dev platform is fantastic and I really think it could be very successful for the ent market.  (and can certainly see enterprises looking elsewhere to platforms like iPhone and Android while this isn't an option). Niall