re: The Emissary Design Pattern and RIAs (Rich Internet Applications)

manuelsimoni — Mon, 11 Aug 2008 14:09:48 GMT

Hi, any chance for a PDF version of that presentation? Thanks a lot, Manuel.

re: The Emissary Design Pattern and RIAs (Rich Internet Applications)

Oran — Wed, 13 Aug 2008 08:45:35 GMT

I enjoyed reading your powerpoint. I've been thinking similar thoughts for a while now, and it is good to see someone else's detailed thinking on the subject.

The sound byte summary for my thinking is "sync down, actions up" or more precisely, "synchronize reference data to clients, send user actions to the service as messages." User actions, once they are authenticated, authorized, and executed by the service, usually turn into new reference data that is then synchronized out to all interested parties. As you note, the same model can also be used between services, often in both directions.

This style requires that you be explicit about who owns and controls the data. If you don't have clear data ownership rules, you will need hacks like merge conflict resolution to bail you out of your lack of foresight. The Sync Framework, ADO.NET, and SQL Server folks are more than happy to be enablers of this style with a big grab bag of such hacks. People typically get into this mess because of the belief that "sync down, sync up" is good enough.

I think the biggest (and most subtle) hurdle to implementing "sync down, actions up" is preserving user-centric authentication for user actions that occur on offline-able clients. Many implementations take shortcuts, including relying on sync to transfer the client-computed _result_ of user actions, and downgrading from user-centric to client-centric authentication and authorization. More sophisticated hacks try to validate user actions by reverse-engineering the actions from the resulting data sent from the client. Security shortcuts that would never fly in an online web client are the norm in offline-able clients. People are moving emissaries inside the trust sphere because it's easier that way.

There isn't a good RIA message queuing solution that securely flows user identity along with service calls. Solving this problem correctly requires queueing up user actions as signed messages that prove that this user identity performed this action, in a way that can be validated by the service once the queued message eventually arrives. This enables online web clients and offline-able clients to use the same exact user-centric authorization code, with the same degree of confidence.

Another issue offline-able clients may need to deal with is treating local updates to data as speculative until the actions that correspond to those updates have been approved by the service. The service reserves the right to veto any client action. This veto needs to eventually compensate for ("undo", possibly via sync) any related speculative data changes on the client. Allowing the user to take further actions based on speculative local data is a trade-off to be made on a case-by-case basis, keeping in mind the impact of a service veto early in the chain of offline actions.

If the client and the service share the same business logic code, then the client can have a high degree of confidence that its speculative local updates are identical to the data that will eventually be synced back down from the service, assuming the corresponding action is approved. But just in case the client got it wrong, the system will eventually self-heal through synchronization of reference data.

I would love to know your thoughts on this. Sometimes I wonder if I'm unnecessarily complicating things since I don't hear many people talking about solutions like this.

TechED Chronicle: Imparare dai problemi altrui...

di .NET e di altre Amenit — Thu, 13 Nov 2008 02:31:48 GMT

TechED Chronicle: Imparare dai problemi altrui...

New and Notable 265

Sam Gentile's Blog (if (DeveloperTask == Communication && OS == Windows) — Wed, 04 Feb 2009 00:08:36 GMT

A quick one while I am on vacation. .NET 3.5 SP1 Mr. Hanselman has come out with the mother of all .NET 3.5 SP1 posts with Hidden Gems - Not the same old 3.5 SP1 post , which includes coverage of all the areas including my WCF changes . Announcing Entity