Prism - Occasionally Connected?
Monday, June 9th, 2008.Prism, AKA Composite Application Guidance + Composite Application Library, is rolling towards a release. I’ve been talking with Glenn Block quite a bit about Prism, and am even on the advisory board (what were they thinking?).
One of the topics not covered by Prism is occasional connectivity, and I would like to say a word or two about that. First of all, if you’re building a standalone client (one that doesn’t communicate with anything), then there’s a good chance that Prism isn’t for you, although you could be composing other standalone client modules. So, if your client isn’t communicating with anything, well, then this post probably won’t interest you that much. Let’s start with…
Physics
Networks fail. Period.
This means that your client machine will not always be connected to other servers.
Also, servers fail - critical Windows patches and just regular power outages.
Ergo, your “smart” client will be occasionally connected, whether you planned for it or not.
And please don’t take this post as a “dumping on Prism” post - it isn’t intended that way. Rather, it is about how you should think about designing modules in Prism, and why.
Modules and Connectivity
Consider the case where we have two modules being composed in a single client. Each module communicates with a different server. Let’s call these modules Ma and Mb, and the servers Sa and Sb respectively. Now, let’s discuss what occurs given that the modules weren’t designed with occasional connectivity in mind.
User clicks something in Mb which requires communication.
Mb tries to call Sb, say, over HTTP, using a regular web service invocation.
The calling thread, in this case, the one used for user interaction, is blocked waiting for a response from Sb.
Sometime in this call, Sb fails, connectivity goes down, whatever.
30 seconds after the call, the HTTP connection times out.
If something important were happening in Ma at the same time, the user couldn’t even see it, let alone do anything about it since the user interaction thread is stuck. This is a serious concern for the financial services domain, but in many others as well.
You mean there’s more?
I can go on, but I think that that’s enough to paint the picture that if you are building a smart client, there are a lot more things to think about than just learning Prism. That’s my main concern after witnessing what happened around the CAB. Given the learning curve around these frameworks many developers don’t seek to deepen their understanding beyond just becoming proficient with them. This isn’t just centered on the developers, evangelists in Microsoft tend to paint the picture this way:
Once you understand X (CAB, Prism, BizTalk, whatever), all your problems are solved.
That’s not to say there aren’t good things in those technologies, but that’s just it, they’re just tools. Silver hammers and “laser” guided saws do not a master carpenter make. There’s actually a pretty good chance the regular guy will saw their arm off.
Help
I do hope more “instruction manuals” will be coming out of Microsoft on these topics. That’s not to say there aren’t any. Specifically on the topic of occasional connectivity, there is Chapter 4 of the Smart Client Architecture & Design Guide. Unfortunately, it doesn’t say anything about how that connects with the MVC/MVP being used client side (the bits affected by Prism). Chapter 6 of the same guide deals with the client-side threading, but doesn’t address issues like:
- Which model object instance are views bound to.
- Do other threads have access to that object at the same time.
- Which controller/presenter is responsible for giving that object to the view.
- Do they need to clone it.
- How deep should the clone be.
- How do various controllers/presenters (which may be showing the same object in different views at the same time) communicate changes to their various independent clones.
I haven’t yet documented all the patterns that answer these questions, but until I do (or Microsoft does), let me offer these few resources which I’ve put out over the years:
- Occasionally Connected Systems Architecture: The Client
- Occasionally Connected Systems Architecture: Concurrency
- Threading issues when smart clients reconnect
- [Podcast] Occasionally Connected Smart Clients and ADO.NET Sync Services
There’s also some more links under the Smart Client link of my “First time here?” page.
Also, please join me in asking Microsoft for an update to these guides - comments below or your own blog posts would be great.
|
If you liked this article, you might also like articles in these categories:
If you've got a minute, you might enjoy taking a look at some of my best articles.I've gone through the hundreds of articles I've written over the past 4 years and put together a list of the best ones as ranked by my 2000+ readers. You won't be disappointed. If you'd like to get new articles sent to you when they're published, it's easy and free.Subscribe right here. Something on your mind? Got a question? I'd be thrilled to hear it. Leave a comment below or email me, whatever works for you. Your comment... |






