Smart Client Architecture Guide Update

The Smart Client Architecture Guide is nearing completion. It's been an interesting journey; writing stuff down always focuses the mind.

One of the problems with writing an architecture guide is the need to try and give concrete advice without getting too involved in the implementation details, and at the same time being sensitive the very many different environments and scenarios where a smart client application could be used. We’ve had to shy away from the “this is the best way to do x” and go for a “you should consider doing x, these are issues, and these are the options you have available” kind of approach. This could be very unsatisfying for some but I hope it strikes the right balance between giving useful advice without being too restrictive.

Unfortunately, we’ve had to drop the chapter on smart client patterns. We realized that to do this justice would require a lot more time than we had so we’ll have to published this separately at a later date. I am trying to work out which architectural patterns make the most sense and how best to implement them. There are a lot of smart client relevant design patterns out there already which are well documented, such as Model-View-Controller, etc. I am more interested in the higher level patterns which make it easier to do stuff like data caching, working offline, and asynchronously interacting with remote services.

Comments

• Anonymous
  May 24, 2004
  Hi David,
  
  My question regards using the Executor in a Windows Service on the client machines to leverage its capability across multiple client applications.
  
  I read online (somewhere) that one user had difficulty passing his payload from the Windows Services realm to the Client Application address space.
  
  I remember there being some security issues that prevent regular desktop apps from passing data to/from Windows services.
  
  Do you have a definitive answer to this general question?
  
  Thanks,
  John Askew
  
  jaskew@carlton-bates.com
  

• Anonymous
  May 28, 2004
  Interesting scenario...
  
  If you host the executor in a separate service, you would have to implement a queue that is shared between the service and the client application and you would also have to pass data back from the service to the client application once the service request has been executed. I guess you would also have to have some mechanism to tag each request so you could identify the originating client application.
  
  To pass the response to the client you would use some for of inter-process communication (like Remoting) to marshal the data across to the client. I would imagine that the client application would register with the service when it first runs so that the service could direct any responses to it. The service would have to provide a connection point for the client application to register with.
  
  I am not aware of any security restrictions with this scenario. A lot of the Remoting samples have a service hosted object and allow the client to connect to it and allow for bi-directional communication. You would of course have to be careful that only authorized clients can post service requests to the queue and that only authorized clients and can register for and receive responses.
  

• Anonymous
  June 01, 2009
  PingBack from http://patiochairsite.info/story.php?id=366

• Anonymous
  June 02, 2009
  PingBack from http://patiochairsite.info/story.php?id=13534