There have been a lot of people on the forums asking how to "write a web viewer", and to be honest I haven't answered because it's an extremely broad question, and the answer would be equally broad and not too useful.  Also, the answer is very much dependent on your specific requirements, so I could be leading you in the wrong direction.

I guess the reason the question is broad is because people have no idea where to start.  We had ideas on how to start when we wrote ours, but it was uncharted territory and we had to feel our way through it just like anyone else, so perhaps I'll just write something up explaining how ours works and some of the considerations and pitfalls of writing one from scratch.

Our web viewer essentially consists of a duplex WCF service and a silverlight client.  When a user first opens a study from the ImageServer's study list, a request is made to the service to start a "viewer application" with the specified study loaded into it.  From that point on, the service is in control: it pushes out messages/updates via a callback channel, and the client simply reflects the changes based on what the service tells it.  The client isn't much more than a glorified JPEG viewer with a toolbar and a context menu, really.  Everything is done on the server, right down to the content of the toolbar and menus and the enabled state of the items in them.

Many of you are familiar with CC's Presentation Model approach to UI.  The web viewer follows this paradigm, except that all the GUI controls exist on another machine, and the app runs on a server.  Even the mouse movements are processed by the application server and almost everything is done via "Property Changed" updates sent back to the client.  For more info, watch our video here.

Did we do it this way because it's the best way to do it ... well, yes :)  Is it the only way to do it?  No, but it is probably the easiest.

At first, we considered all our options, but when we came up with the design idea for the duplex service, WCF and Silverlight became a no-brainer.  The built in support for duplex communication (on both ends) made the development much easier.  WCF is just too powerful and flexible to NOT use it, really.  Add in the ability to make incredibly slick UIs in Silverlight, and it was even harder to justify using anything else, especially since CC is a .NET app, using .NET based technologies just makes life so much easier.

Quickly, some of the other things we considered:

Simple HTTP-based web service (SOAP or simple XML-exchange):

• Would be easier to consume from non-.NET technologies
• Might have to do manual (de)serialization of messages, unless it were a simple SOAP service
• Would have to "fake" duplex communication (e.g. by polling)
  
• We would be writing something from scratch that WCF provides for free
• Maintenance headache
• Performance problems

Custom tcp-based service:

• Can do duplex communication, but most technologies wouldn't be able to communicate with it from within the browser
• Would likely provide good performance
• Extremely low-level socket stuff - bleck!

Flash client:

• Also requires a browser plugin
• Only simple web service support, certainly not duplex and consumption of WCF service would be limited to SOAP-based bindings

• Only simple web service support, certainly not duplex and consumption of WCF service would be limited to SOAP-based bindings
• Could (maybe) use AJAX Control Toolkit to build the UI, but it's not as rich as Silverlight

• Because you're window/levelling on the client, you pretty much have to stream the DICOM pixel data (from ImageServer, say) to the client and render it there
• You're basically rewriting code that already exists in CC ... pretty much just writing a new viewer
• You probably won't be able to reuse any CC code, like the DICOM toolkit or the viewer's rendering capabilities, unless you wrapped it all in COM and wrote your viewer as an ActiveX control, which would pretty much limit you to using Internet Explorer
  
• You can't even use Silverlight because it doesn't support rendering anything other than typical image types, like JPEG/PNG
• You're basically asking for a world of hurt on this one!
• If it worked, it would provide better performance because you're only getting each image one time instead of a new JPEG each time you change something

What are the benefits of our approach?

• Duplex approach means updates can come from the server at any time; the client does not have to "ask"
• No polling provides a smoother user experience; it "feels" like a regular UI app, less choppy

Anyway, I hope this helps people to better understand what's involved if you're going to take it on.  Or, you could just wait until ours is released and use that! :)

Cheers,

Stewart