Currently you can:

• Create "fake" Domain with in-memory database on the client (fake, because this database will be actually never modified)

• Create server-side WCF/.NET Remoting service providing serialized DisconnectedState as response to any client request - let's call it data provider

• Create server-side WCF/.NET Remoting service applying OperationSets sent by the client to the server-side entities - let's call it operation processor.

So:

• When client needs some data, it queries data provider, gets a DisconnectedState and either uses it, or merges it with some existing one.

• To send the update, client takes OperationSet of DisconnectedState and sends it to the operation processor.

Advantages:

• Client-side entities are equipped with all the services we provide, such as local transactions, INotifyXxx, paired property sync, version & change tracking, etc.

• The same logic works on the client. Although you can use some different logic there - see Session.IsDisconnected and Session.DisconnectedState properties.

Disadvantages:

• Server-side serialization must be carefully tuned by filtering just allowed types - to ensure everything is secure. That's one of TODOs we have.

• DisconnectedState itself currently isn't WCF-serializable, and probably, it won't be (but let's see). So you can send it via WCF only as blob. On the other hand, if you need POCO-like representation, there are O2O & ADO.NET Data Services, but in these cases client-side entity representation will be different (= advantage listed above is lost).

Possible future improvements:

• A sample application demonstrating this approach in action.

• Special "remote://" protocol for client-side Domains allowing to connect them directly to server-side Domains. Less secure (client will be able to execute arbitrary queries, etc., so technically, it can flood the server), but more convenient (no need to develop any of server-side services). Since all data modifications will be processed by the same way, we have nearly the same level of security here.