We had an interesting discussion on the course a couple of weeks ago that I thought was worth summarising here. One of the key functional requirements of the case study that we run through is that the system should be able to distribute data to a subset of users on the corporate LAN. Now there are 101 different ways to solve this problem, with one of the simplest being to allow the users to access the data via an internal web application. Since only a subset of the users within the organisation should be able to see the data, any solution would need some sort of authentication and authorisation on the data.
Given the buzz around Web 2.0, AJAX and RIA in recent times, one of the groups decided that it would be nice to allow the data to be accessed via a Silverlight application. They'd already thought about building an ASP.NET application but liked the possibilities offered by Silverlight (e.g. the ability to slice and dice the data interactively). Another driving factor for their decision was that the Silverlight client could be delivered "for free" in that it would take just as long as building an ASP.NET application. "For free" is a pretty bold claim, especially considering that they were effectively adding an extra architectural layer into their software system. I drew up the following summary of their design to illustrate the added complexity.
While I don't disagree that Silverlight applications aren't hard to build, the vital question they hadn't addressed was where the data was going to come from. As always, there are options; from accessing the database directly through to exposing some data services in a middle-tier. The group had already chosen Windows Communication Foundation (WCF) as the mechanism for exposing the data, but this led to yet further questions.
- What operations do you need to expose?
- Which technology binding do you use?
- How do you ensure that people can't plug in their own client and consume the services?
In the context of the case study, the third question is important. The data should only be accessible by a certain group of people and we really don't want to expose a WCF service that anybody with Visual Studio could consume. This led to discussion about the use of SSL to secure the service, but SSL only secures the transport layer to stop data being looked at in transit. In this case, some thought needs to be given to authentication/authorisation of the service itself.
Coming back to "it won't take longer than building an ASP.NET application" then. In this situation, the benefits brought by the additional Silverlight layer need to be considered alongside the additional complexity that's also been introduced. More moving parts means more work designing, developing, testing and deploying. Despite what it might say on the box, nothing is ever free and you need to evaluate the pros and cons of adding additional layers into a design, particularly if they result in communication between containers.