This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: Occasionally Connected Service Oriented Smart Clients
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
I'm reminded again of OCC here at the MVP Summit with the lack of connectivity. I can't even maintain a cellular connection two flights up to Robert's room never mind create business logic to depend on it. Connectivity is very elusive here as in much of the the USA and world. Many developers assume wireless will be everywhere enabling applications to communicate to centrally located servers regardless of where the user is. Any developer that has actually tried deploying connected applications knows that this is really just a dream of an alternate universe that simply frustrates users with reality. Users want their applications to just work and their data to be available even if the network isn’t. Custom applications require data and application updates to be constantly verified. Users shouldn't’t have to press a button or manually switch from local to remote modes.
Too often in the past, Microsoft has not understood this and many developers don't either. Many technologies like ASP.NET suffer from requiring full time connectivity to servers, besides the fact that browser clients are often a bad choice when the deployment problems for Smart Clients have been solved. Thin clients were a great solution in the mid to late 90's with the massive deployment problems of MTS/COM+/COM/Windows DNA. They are not any more unless the ubiquity reach is needed for the solution. Microsoft has started to pay attention to making the Smart Client truly smarter with the Offline Application Block and the good stuff in CAB. Not every application needs offline access but I encourage .NET developers to really look at the scenarios out there. There is very little support for the remote offices and mobile/field workers that have been created as a result of the modern distributed enterprise. We're still trying to apply centralized architectures to a distributed enterprise. Client-Server and Web-centric systems often fall short here. Essentially business assets have been locked up that could be freed if business processes were distributed and “mobilized“ allowing edge workers and data to aggregate data from the edge to the center and back out, continuing to have access to their business data and applications while being disconnected.
In considering offline access, I see two major approaches; the “simple” way and the “not so simple or full OCC Smart Client.” In the simple way, essentially offline access can involve simply serializing data to and from XML files on the client or smart device using the WriteXML method of a DataSet or a DataTable in 2.0 Framework. Other options such as Isolated Storage exist. This can be combined with Caching as needed all the way up to the Caching App Block. In the full OCC client, it presumes a full local database on each of the smart clients with either transparent replication or even better synchronization. The vast power and deployment flexibility of both SQL Express and SQL Mobile make this a much easier option than the MSDE days. Many smart client developers use Merge Replication or RDA Replication. Both of these are problematic as they are not Service Oriented at all and introduce tight coupling. Services are supposed to guard their data sources and not allow clients to directly access the data sources. Services typically aggregate data in the business logic layer for presentation and if the databases are directly accessed, the amount of business logic that must be replicated to the offline client is greatly increased. Database replication tightly binds the client architecture to the server architecture. Replication tables from the client to the server can bypass business logic.
What can you do? Keep your synchronization engine loosely coupled through the use of Services that can be deployed via ASMX/WSE or now Indigo Web Services. One approach is the one that we took at Adesso. I think with the options afforded by Indigo, developers should consider this route in keeping loose coupling in their synchronization logic. For instance, a WCF queue could be used coupled with a WCF transport. The OCC Smart Client then morphs into an “Occasionally Connected Service Oriented Smart Client.” This is not buzzwords or just a mobile scenario. This is a real architectural option for distributing business processes and data out to the edge where many of your company's workers are today.
Previous Topic
