I have built a data abstraction layer which allows me through the use of configuartion files to decide whether the data source is sql server, odbc or oleDb or xml. I use parameterized xslt transforms as my xml equivalent of stored procedure. It is all working very well and could be easily extended to retrieve data and transform it different sources such as web services, message queues etc. I was discussing on this on IM and made the statement that of course adding asynchronous data sources would require no change to my presentation code. Everything is separated into layers so the presentation layer has no clue about which data source or transformation technique is being used.
Once I started thinking about it I realised that really I am starting to build a service orientated architecture. My applications are consumers of services provided by other "applications". Here I use the world "application" losely as I could be refering to a sql server database or a hotel book system running else where in the world. I said initially that if I started accessing a data source asynchronously I would not have to change my presentation code, but this only true if I can use a form of intelligent caching. We tend to build applications thinking that all our calls are synchronous. You press a button and a response appears on the screen. When we first started using Soap and building web services we all built synchronous services, esentially Remote Procedure Calls using Soap. For many reasons we realised that may be that wasn't the best idea and we should maybe use a subscribe and publish architecture. However, in order to make this easier for developers you need to be able to build a "runtime" which hides from the developer most of the work that would be required in order to implement such subscribe, publish and consume systems. These systems tend to be constructed as message busess where a message is passed along a pipleline and information is added to the message on one side and removed on the other side.
This is all well and good in terms of building the plumbing and assuming that it is all built professionally it will solve a lot of problems in terms of building service orientated architectures. However, what about my client, traditionally and especially the the vb programmers and the web application designers have assumed that an event is raised you make your call and you make your remote procedure call and you get back your response and it is displayed to the user. Users don't like seeing hour glasses or please wait 5 minutes for the response. All our systems tend to be designed and archticted to assume synchnous behaviour. This problem is eloquently described by Ingo Rammer in the Flowchart lie.
However, again this is dealing with how we architect a system in terms of the plumbing etc. What about the client where are the tools for building consumers of asynchronous messages.
- One way is to use caching and refresh the cache asynchonously. Only bring across enough information that the application can operate as though it was working with a synchronous source.
- Fire and forget....or is that fire and hope.
- Display the hour glass and wait
"Indigo" provides the plumbing but where are the metaphors and built in tool support for building asynchronous applications. It is just not the way most people think or operate. Don't say use the building blocks as that assumes too much prior knowledge from the average programmer.