Answer:

It is true that most of our documentation describes building applications using a centralized database, but one of the strengths of our product is the ability to provide disconnected support.  When working while disconnected, there are two different strategies.  The first (and simplest strategy) allows objects in the persistence cache to be stored and loaded into and from files in the file system.  These files can be encrypted if desired.  You can see an example of this strategy in our tutorials. 

This strategy works fine in many situations, but in other situations where the application is more complex and the database is quite large, we recommend the use of a local database such as SQL Server Express.  We do have customers who started out providing disconnected support to their customers through the simple local file mechanism, and then moved to a distributed database design.

 A distributed database design requires support for a number of features.  One of these features is good support for concurrency conflict resolution.  We provide excellent support in this area, and I would encourage you to look at our tutorial on this subject.    We do not yet have a service broker that allows SQL Express clients to communicate with a main SQL Server, but we'd be happy to talk to you about this requirement.  There is nothing in our architecture that prohibits the use of such a broker, and, in fact, it is a crucial component of our long-term plan to provide ever better support for disconnected use.