One very common theme I hear these days from customers is "How can I not only notify people of an item to work on but let them react immediately to that notification?" The typical scenario is approval of some business process for example a purchase order.
The Old Way
So what would the components of such an architecture be?
- a mechanism to send out the notification
- a way on the device to interact with the notification
- a way to send a response to the notification
- a backend that could process the response
In the PC world the architecture consisted of
- Enterprise Application sends an email which would notify the user
- An embedded link in the email allowed the user to interact with the notification
- The Enterprise Application client allowed the user to response and processing that response
It has become so common that most Enterprise Application will send out an email with a link back to the application to click on. That was great when people used laptops and desktops for managing their email. Today that is no longer true.
Mobile Proposal
So now what happens is a manager or executive gets an email with the link on their Windows Mobile phone. They now have to either boot their laptop or find a computer. Then they log back into email and assuming the application will work on the computer they click the link. For more complex work that will still remain the norm, however, when your only options are to approve or reject the work item that is a lot of work. How can a solution be supplied that allows approval or rejection of a work item using a phone?
The problem with this model for mobile devices is that the user might receive the email on a device that cannot interact with the Enterprise Application. Or even if it could it might not be able to do so right then due to a lack of network connectivity.
In an occasionally connected work the architecture might consist of
- Enterprise Application sends an email which would notify the user
- A client on the device intercepts the email and saves the data from the notification
- The user can use a device client to look at the notification and respond to the notification
- A response email is created and sent back and processed by the server
Data Transport
The first issue is how to send out notifications. Currently, an email is generated by the Enterprise Application to notify the user. This email while human friendly is not really geared towards comsumption by a process.
Enter .Net 3.5 and Compact Framework teams which have developed Windows Communication Foundation (WCF). WCF is a unified framework for building distributed applications. WCF allows for multiple transport mechanisms. This includes an email data transport (see Roman Batoukov blog entry on Lunch Launcher).
It does not take a genius to see that a change in the content of the email could be done to make the email, process friendly i.e. XML content. One problem to consider is what to display if the user gets the email on their laptop or PC. XML is not exactly user friendly.
Device UI
Next you need a client on the device to intercept the email. This is handled by WCF. To further integrate in with the device a Today or Home plug-in can be created to display the number of notifications and type. In addition the plug-in would serve as the launch pad for responding to the notifications.
Response
The response is where it gets tricky. Right now there is not an easy way of truly trusting the device or who is using the device. In addition, the device might not be connected which leaves out using a web service that the user can log into to validate them. However a web service call could be sent as an email. The trick is to sign the contents of the email with a signature of the user.
The Solution
In the coming weeks I will blog about how to build the components to create the solution. You can then adapt this to build your own solutions.
Comments