I am working to help some of physicists who run KucingFisika, to design their future multimedia e-learning site with Silverlight. After looking around for design practices, I found that Microsoft .NET RIA Services is good as our base line. This is now available and you can download from here and later explore it like I do. In this post, I would like to encourage you to see that we can add additional scenarios, making RIA Services really applicable in low bandwidth condition like us in Asia – adding offline feature. From marketing point of view:
Microsoft .NET RIA Services simplifies the traditional n-tier application pattern by bringing together the ASP.NET and Silverlight platforms. RIA Services provides a pattern to write application logic that runs on the mid-tier and controls access to data for queries, changes and custom operations. It also provides end-to-end support for common tasks such as data validation, authentication and roles by integrating with Silverlight components on the client and ASP.NET on the mid-tier.
From technical point of view (you can read more from its PDF documentation). It is a framework that provides patterns for writing LOB application logic and validation (by design). LOB applications use data that needs to flow across tiers. It may be created and used through basic CRUD operations or it may be accessed through domain-specific custom operations in encapsulated form such as an approval operation. In an internet application, there is a trust boundary between the client and the mid-tier server. Hence, it is important to have a stylized way to express what resources are available to the client tier and what operations are permitted. In addition to defining the resources and operations, a developer needs to validate the data as it is created or updated. The validation needs to run on the presentation tier for giving immediate feedback to the user and on the mid-tier for ensuring that the rules defined for the application are enforced. Thus, there may be common validation across the tiers as well as tier-specific validations that need to be integrated with the resources and operations.
Lets look at the anatomy of a common Web application compared to RIA. With a RIA, most of the presentation logic moves to the client to improve the UX and to make effective use of local state. The result is additional work for the developer: defining a full-fledged services layer, new types and contracts to share etc. and continually evolving them as the app evolves on either end. A RIA isn't just a client app, but an "Internet" app that includes a server component. This is where RIA Service guidance will give you values – end-to-end pattern for this additional work. But remember, there is no perfect design/pattern, we can always improve it based on our requirements.
The first part of RIA Services pattern is to write a DomainService class. This represents your application domain, your application logic, or business logic, a set of operations – CRUD based or custom domain-specific, DAL specific, authorization and validation. A DomainService is optimized to be stateless - to respond to query requests and to change set processing requests.
The second part of the pattern is what we generate - the client-side data model - in a DomainContext class. This class represents the view of what the client can see. It contains lists of objects, one for each type exposed to the client, and it contains a set of load methods that roughly correspond to the queries exposed on the service. These load methods can be used to load objects into the corresponding lists. The individual objects and lists track changes and raise change notifications. The DomainContext can extract all the changes, create a change set and submit it to the service for processing and committing. A DomainContext is optimized for taking advantage of the stateful environment and to be a well-behaved citizen in a binding-centric presentation technology such as Silverlight or WPF.
Nikhil Kothari describe .NET RIA Services vision as RAD for RIA, which is I totally agreed and have the same sense.But there is one requirement here in Asia that we must consider – low bandwidth condition. This will rise new scenario - offline-enabled RIA application, means that we need to add local storage scenario for the DomainContext. The design challenges of all the offline-enabled applications are:
How to isolate client data layer
What is actually the data layer in RIA? It that the API that server exposes to AJAX? Gears provides a good vision on Server Data Layer and Local Data Layer, controlled by a Data Switch. Gears propose JavaScript DB API with SQLite to enable local data storage. It is a good project to start with SQL Compact Edition, however, but an ActiveXObject should be created for SQL Compact Edition/SQL Express/ESENT. Anyone interested here?
Offline strategy – what features need offline scenario
This is the harder part for me, as closely related to our application scenarios. Let say, I want to design Physics e-learning application that contains RIA/Silverlight based simulation, Farseer Physics Engine for example. Some numerical calculation should be done at client side and its results should be store locally in order to feed parameters for responsive and dynamic GUI animation. You might think that you would always want to use the local store since it is faster. However, there are many practical reasons why you may want or need to access the data on server instead. For instance:
- Data may be so transient in nature that it makes no sense to cache it. I will use Project Velocity for cache anyway.
- Some Simulation's data makes sense only while online.
- The App may choose to store only the most frequently accessed data.
- Numerical computational and/or disk space requirements make it unfeasible to recreate the feature offline.
Typically, the optimal solution is to use the local store as much as possible, since it's usually faster than a remote connection. However, the more work an application does locally, the more code you need to write to implement the feature locally and to synchronize the corresponding data. There is a cost/benefit tradeoff to consider, and some features may not be worthwhile to support locally.
In fact, .NET RIA Service provide ready to extend set of capability that I like. But, a lot of work should be done to make it work like I want. That is my problem though :).
Application Modality
What is modality – feature to switch from online to offline states or vice versa. Modal applications usually indicated through some change in the user interface. The user is made aware of the state and participates in switching states in some manner. Modeless applications attempt to transition seamlessly between online and offline states, without significant UI changes. The user does not need to participate in switching states, which the application does automatically.
In a modal application, when the application is online it communicates with the server. When it's offline, it uses the local store. Data must be synchronized when the app switches between modes. The advantage of making a modal application is that it's “relatively simple” to implement and therefore a reasonable way to bootstrap the application to function offline. But some disadvantages are: The user must decide and remember to switch modes. Since the local store is not always up-to-date, it can't be used to improve the application's responsiveness when connected to the server.
Data Synchronization
What is the sync strategy for this kind of application? No matter which connection and modality strategy we use, the data in the local database will get out of sync with the server data. For example, local data and server data get out of sync when:
- The user makes changes while offline
- Data is shared and can be changed by external parties
- Data comes from an external source
There are many approaches to synchronization and none are perfect for all situations. We have Microsoft Sync Framework and Astroria Offline as candidates for reusable framework here (where I am still arguing). The most important thing for engineer to decide is manual or background synchronization. In manual sync user decides when to synchronize. It can be implemented simply by uploading all the old local data to the server, and then downloading a fresh copy from the server before going offline. In background sync, the application continuously synchronizes the data between the local data store and the server. This can be implemented by pinging the server every once in a while or better yet, letting the server push or stream data to the client. With Silverlight supports on WCF, this should be easy to implement.
Well, the next step for me is to gather our detail requirements and see how current frameworks can help. I am still hacking the MSF, Astoria Offline, RIA Services, and Velocity. For sure, I will share with you if I found interesting things.
Have nice weekend without insomnia!.
Cheers – RAM